-----Original Message-----
From: mikebuckley@attmail.com [mailto:mikebuckley@attmail.com]
Sent: Friday, March 03, 2000 8:35 AM
To: Rosen, Brian; ITU-SG16@mailbag.cps.intel.com
Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt
Surely it also dishonours the agreement between the ITU-T
and IETF groups,
as they participated in agreeing the words that go in
H.248/MEGACO, but do
not apparently participate in discussing the profile that then gets
subsequently published by IETF.
This attempt to sidestep the agreement with the ITU can only
create bad faith
between the two organizations. The Megaco wording was
arrived at after lengthy
discussions and compromise on both sides. The consequences
of unilaterally
trying to pursue one line will ony result in the ITU going
off in an incompatible
direction. Is this what the market wants - an IETF package
specifying text
encoding and an ITU Annex specifying binary?
This is not the way to resolve the text v. binary issue and
it is not the way to built
good relations between the two Standards bodies.
Agreements should be honoured by both sides in the spirit as
well as the letter.
____________________ Begin Original Message
___________________________
Date: Fri Mar 3 08:05:04 -0500 2000
From: internet!FORE.COM!brosen (Rosen, Brian)
Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt
To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO
Content-Type: Generic-Text
Content-Length: 5599
There are two threads in this message I wish to comment on.
1. The issue of text encoding. Text/Binary Encoding is defined
in the protocol as optional. A profile could make a choice.
It is acceptable to me that such a choice be made in this profile.
2. Subsets of the protocol. I have been vociferous in positing
that profiles cannot subset the protocol. If the protocol
defines something as optional, then the profile can declare
what options shall be implemented. Where there is not an option,
profiles should not make something optional. If it does, it's
a new protocol. Call it that, and we can decide if we want
to standardize a new protocol. I personally do not believe that
an IPPhone needs to subset the Megaco protocol.
-----Original Message-----
From: Drage, Keith [mailto:Keith.Drage@SIEMENSCOMMS.CO.UK]
Sent: Friday, March 03, 2000 4:43 AM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt
I note that this proposed profile contains the text:
"Megaco IP Phone MGs MUST support text encoding of the protocol, as
specified in the Megaco/H.248 Protocol document [3]."
While I DO NOT want to reopen the encoding debate, it seems
inappropriate to
me that MEGACO should create a profile that further restricts it own
product. I understood the summary of the text versus binary
debate was that
the decision on encoding would be made by market forces, and was NOT
application dependent. If there is an application dependency, then
guidelines to that dependency should surely be given in the
main MEGACO
protocol document.
Surely it also dishonours the agreement between the ITU-T and
IETF groups,
as they participated in agreeing the words that go in
H.248/MEGACO, but do
not apparently participate in discussing the profile that then gets
subsequently published by IETF.
I would have therefore thought that if TIA wish to restrict
the encoding
choice, then it is up to TIA to publish the profile, rather
than the IETF.
Looking further, I notice that the document also defines
constraints on the
usage of Events, etc. Reading the main MEGACO protocol document, I
understand that variations on termination characteristics should be
implemented by specification of a package. Should these restrictions
therefore be defined by a new package?
I guess we need some general discussion on what is possible
in profiles, as
opposed to packages, and whether MEGACO should define
profiles that are
still nominally called MEGACO, but do not exhibit all the
requirements of
the main document. Rephrasing in a slightly different way,
which are the
options, and which of these options that are selected based
on the type of
application (and therefore suitable for specification in
profiles for a
particular application), and which are implementation options
(and selected
because an implementor wishes to make his product different
and presumably
better/cheaper/fit the available memory than another market
entrant).
Rephrasing the question a different way, with the
restrictions imposed by
this "profile", can the result still be MEGACO/H.248, or
has it really
invented a new protocol?
Let me stress again, I do not want to see any responses that
it is done this
way because text is better than binary, or more efficient.
The answer to
that is irrelevant to the point I am trying to make.
Keith Drage
---------------------------------------------------------------
Keith Drage (keith.drage@siemenscomms.co.uk)
Siemens Communications Limited,
Technology Drive, Beeston, Nottingham NG9 1LA, UK
Tel: +44 115 943 4991 Fax: +44 115 943 4992
---------------------------------------------------------------
Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal
responsibility for the
contents of this message. Any views or opinions presented
are solely
those of the author and do not necessarily represent those
of Siemens
Communications Limited unless otherwise specifically stated.
A New Internet-Draft is available from the on-line
Internet-Drafts directories.
This draft is a work item of the Media Gateway Control
Working Group of the IETF.
Title : Megaco IP Phone Media Gateway
Application Profile
Author(s) : R. Bell, P. Blatherwick, P. Holland
Filename : draft-ietf-megaco-ipphone-02.txt
Pages : 13
Date : 01-Mar-00
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt
---------------------------------------------------------------
Keith Drage (keith.drage@siemenscomms.co.uk)
Siemens Communications Limited,
Technology Drive, Beeston, Nottingham NG9 1LA, UK
Tel: +44 115 943 4991 Fax: +44 115 943 4992
---------------------------------------------------------------
Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal
responsibility for the
contents of this message. Any views or opinions presented
are solely those
of the author and do not necessarily represent those of Siemens
Communications Limited unless otherwise specifically stated.
Rosen, Brian