H.225 Annex G

Fri Mar 3 08:39:00 EST 2000

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.
> >
> >
>