Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt
I agree wholeheartedly with Keith Drage's comment:
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.
Mike Buckley
____________________ 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.
Brian
-----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 GatewayApplication 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.
participants (1)
-
Mike Buckley