I-D ACTION:draft-ietf-megaco-ipphone-02.txt

Rosen, Brian brosen at FORE.COM
Fri Mar 3 09:24:25 EST 2000


If this document is stand-alone, not a part of the Megaco
document, then it should stand on its merits.  The IETF
is free, as is the ITU, and any other organization, to define
any profile it desires, with any set of options resolved any
way it wants.  The market will decide if such profiles are
worthy.  The agreement specifically did NOT include subsequent
profiles, packages or other transports, and there are already
planned annexes to H.248 which will not have IETF standard status.

Please note that while I personally do prefer this profile
specifying text, I would make the same argument if someone wanted
to define a trunk gateway protocol as binary only.  I might try
to get that profile defined the other way, but I'd defend the
right of the organization to define it binary only if it so chose.

In this specific case, you clearly have an issue with code size.
If the protocol specifies that both encodings will be implemented,
that blows up the code, I would think, unacceptably.  If you specify
either, you create incompatible systems.  Of course, that is the
entire problem with the compromise.

Brian

Brian



> -----Original Message-----
> From: mikebuckley at attmail.com [mailto:mikebuckley at attmail.com]
> Sent: Friday, March 03, 2000 8:35 AM
> To: Rosen, Brian; ITU-SG16 at mailbag.cps.intel.com
> Cc: MEGACO at STANDARDS.NORTELNETWORKS.COM
> Subject: 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 at SIEMENSCOMMS.CO.UK]
> > Sent: Friday, March 03, 2000 4:43 AM
> > To: MEGACO at 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 at 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 at 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.
> > >
> > >
> >
>



More information about the sg16-avd mailing list