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

From: [email-masked]
Date: Thu, 2 Mar 2000 10:32:28 -0500

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

This document specifies a particular application of the Megaco/H.248
Protocol [3] for control of Internet telephones: the Megaco IP Phone
Media Gateway.  The telephone itself is a Media Gateway (MG), controlled
by the Megaco/H.248 Protocol, with application control intelligence
located in the Media Gateway Controller (MGC).  In order to achieve a
high degree of interoperability and design efficiency in such end-user
devices, a consistent architectural approach, a particular organization
of terminations and packages, and a protocol profile are described.  The
approach makes use of existing protocol features and user interface
related packages, and is thus a straight-forward application of the
Megaco/H.248 Protocol.

This document represents the current view from the TIA working group on
VoIP telephone specification [1], TIA TR-41.3.4, with the intent of
using this as part of its 'whole device' specification as an optional
method of device control.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-megaco-ipphone-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-ietf-megaco-ipphone-02.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Drage, Keith" <[email-masked]>
Date: Fri, 3 Mar 2000 09:43:29 +0000

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 ([email-masked])
> 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.
>

> ---------------------------------------------------------------
> Keith Drage ([email-masked])
> 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.
>
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 3 Mar 2000 08:05:04 -0500

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:[email-masked]]
> Sent: Friday, March 03, 2000 4:43 AM
> To: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt
>
>

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 3 Mar 2000 09:18:32 -0500

One of the key issues is what the Working Group wishes to do with the IP
Phone document.  I'd say the choices are these, but I'm being a little
arbitrary here:

  (1) The document is Standards Track and is an official Megaco output.  In
that case, I think it should conform entirely to the spirit of the main
protocol document (i.e. I'll concede Mike and Keith's points).  I will point
out that the main protocol document does NOT require an MG to support a
specific encoding.
  (2) The document is Informational and is an official Megaco output.  In
that case, I think it should conform to the position as stated by Brian.  We
have the right to select from options, but not to modify the actual protocol
we have produced.
  (3) The document is not an official Megaco output.  In that case, the TIA
has the right to publish what they want, subject to IESG  approval.  Of
course, the IESG may refer it to us for comment.

> From: Mike Buckley [SMTP:[email-masked]]
> Sent: Friday, March 03, 2000 8:35 AM
> To:   [email-masked]
> I agree wholeheartedly with Keith Drage's comment:
>
> 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)
> To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO
> Content-Type: Generic-Text
> Content-Length: 5599
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 3 Mar 2000 09:24:25 -0500

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

> From: [email-masked] [mailto:[email-masked]]
> To: Rosen, Brian; [email-masked]
> Cc: [email-masked]
> 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
> This is not the way to resolve the text v. binary issue and
> it is not the way to built
> Agreements should be honoured by both sides in the spirit as
> well as the letter.
>
> Mike Buckley
>
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 3 Mar 2000 09:28:19 -0500

I personally don't think we need go quite as far as Tom does in 1, but I'm
willing
to compromise.

I'd think informational is appropriate for this document.  I'd think that
any package/profile
would be best left as informational, at least for some time.  At some point
in the future,
we could consider doing a standards track set of additional packages.  I'm
not sure that
there will ever be a need to do a standards track profile - I really expect
most profiles
to be defined outside of either IETF or ITU.

Brian

        -----Original Message-----
From:   Mike Buckley [SMTP:[email-masked]]
Sent:   Friday, March 03, 2000 8:35 AM
To:     [email-masked]
Subject:        Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt

>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

        Brian

> From: Drage, Keith [ mailto:[email-masked]
<mailto:[email-masked]> ]
> > http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt
<http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt>

---

From: Peter Blatherwick <[email-masked]>
Date: Fri, 3 Mar 2000 19:38:54 -0500

Keith, Mike, others,

It is very definitely NOT our intent to create friction between ITU and IETF
in our extremely admirable co-operative effort on the H.248/Megaco protocol.
It is also not our intent to set any constraints or precedents on how other
applications of the protocol work, whether these applications are defined in
IETF, ITU or elsewhere.  This is in no way an attempt to side-step agreed
process.

Our intent is to define a particular application of the protocol, primarily
targeted at creating cost-optimized embedded devices.  In this specific
case, as with other very small scale applications, a choice on both encoding
and transport absolutely must be made, to reduce memory footprint.  (We
would like to see other reductions as well, but let's talk about that
separately.)  We chose text encoding since it seems to us more easily and
compactly implementable for this particular application.  The transport
selection (ALF) was decided for similar pragmatic reasons.  This does not
necessarily reflect on any other application.  It may well be that we are
wrong on these choices, but a decision has to be made to move forward.

As Brian has already noted, these are both options in the protocol at the MG
side.  Note also that the profile does not restrict use of binary encoding
as well as text, just that the text encoding must be implemented.  The same
logic applies to transport.

The point that we must decide where to settle definition of this and other
applications/profiles is well taken, and I agree its at the core of the
debate.  However, I personally believe it is important to settle some
specific applications of the protocol soon, leading towards interoperability
testing and validation, which are natural parts of the IETF side of the
joint process.  Then again, I'm no process guru...

I hope that helps, and apologize for not making it more clear up front.

Peter Blatherwick

---

From: "Drage, Keith" <[email-masked]>
Date: Mon, 6 Mar 2000 11:01:03 +0000

The section of text encoding versus binary encoding is an option within MG.
At the implementation level, the MG can implement one, or the other, or
both.

My issue is whether IETF should provide a selection of this option within a
profile, given its agreements with ITU-T. I would be considerably happier
with allowing this if the main MEGACO/H.248 document said MUST (or in ITU-T
SHALL) instead of SHOULD, for the related MGC requirement. If the IETF puts
a selection of this option at the MG in the profile, then the IETF is
effectively saying for the MGC: "the MGC MUST support text encoding and the
MGC SHOULD support binary encoding". My understanding of the discussion of
the encoding issue when previously discussed in both ITU-T and IETF was that
the status was unresolvable in the standards world and would be left to
market forces to make the decision.

I also see no need why a MG profile should constrain the option for this
particular application. If one encoding is so much more complex that the
other (as some people on the list appear to think), and so much more hungry
of hardware resources such as memory, then this one choice will prove to be
considerably more expensive that the other and the market will decide by not
buying the expensive one.

In general for profiles, I have no problem with IETF creating a valid
profile for a specific application. I think including the encoding issue
within an IETF published profile is the tricky problem. In the draft, there
are other statements, where the protocol is subsetted, which are not valid
for a profile. I would therefore repeat my request that MEGACO should
clearly identify in its discussions what are valid options that can be
profiled, as well as the issue of who is allowed to create profiles. These
selectable options must be clearly based on the text that exists in the main
MEGACO/H.248 document.

Keith Drage

        ---------------------------------------------------------------
Keith Drage ([email-masked])
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.

-----Original Message-----
From: Peter Blatherwick [mailto:[email-masked]]
Sent: Saturday, March 04, 2000 12:39 AM
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt

Keith, Mike, others,

Peter Blatherwick

        -----Original Message-----
From:   Mike Buckley [SMTP:[email-masked]]
Sent:   Friday, March 03, 2000 8:35 AM
To:     [email-masked]
Subject:        Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt

        Mike Buckley

        Brian

---

From: "Drage, Keith" <[email-masked]>
Date: Mon, 6 Mar 2000 11:11:45 +0000

Chip Sharp wrote:

>
> I assume that I can depend on everyone to stand up and defend
> text encoding
> if Study Group 11 mandates binary encoding for BICC's use of
> H.248 in the
> interest of harmony?
> ;-)
>

I understood (from standing on the sidelines) that BICC's usage would be
defined by appropriate package rather than a profile. It is not appropriate
for package documentation to specify an encoding mechanism. I admit that the
formal discussion of this has not yet occurred and will not occur until the
next ITU-T BICC discussion at the earliest.

Given my superficial understanding of various network operator positions, I
suspect it would also be difficult to come to a consensus decision on
selecting one option or the other, and trying to make such a decision will
mean missing the delivery dates.

Keith Drage

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 6 Mar 2000 23:21:46 -0500

I'd go the other way.  If a profile did NOT specify an encoding (or failed
to
specify a minimum for any other option the protocol offers, I'd say it was
deficient.

I'll agree that subsetting where the protocol does not define an option is
inappropriate.

I really think that requiring an MG to have both binary and text is
unworkable
for a really cost constrained design.  The current MGC text is not
satisfactory
to anyone, including me.  It was a compromise, and to this day, I question
it's
appropriateness.  Having been part of it, I'll live with it.  I don't want
to
see these kinds of compromises in profiles, regardless of how the encoding
choice comes out; profiles should result in precise interoperability for a
class of devices.  Any less is unworkable, IMO.

Brian

> Sent: Monday, March 06, 2000 6:01 AM
> Communications
>         >Surely it also dishonours the agreement between the
> ITU-T and IETF
> groups,
> arrived at after

---

From: "Drage, Keith" <[email-masked]>
Date: Thu, 9 Mar 2000 12:16:38 +0000

See below.

Keith Drage

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Tuesday, March 07, 2000 4:22 AM

Is this not tantamount to saying the protocol is deficient as well?

> I really think that requiring an MG to have both binary and text is

Noone is proposing that an MG should implement both. All I have suggested is
that an MG implementor should have the freedom to choose which they
implement. This is a consequence of the MGC decision to go for SHOULD rather
than MUST. My understanding of that decision is that it is up to the market
to decide, not a profile creator.

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 9 Mar 2000 07:35:21 -0500

> Is this not tantamount to saying the protocol is deficient as well?

No, the protocol allows options.  In this case, the option leads to
interoperability problems because the MGC is not obligated to support both.
Conformance to a profile should, IMO guarantee interoperability.  Therefore,
a profile must define at least a minimum for encoding.

> to decide, not a profile creator.
The consequence of SHOULD is that incompatibility is a real possibility.
A profile should eliminate this possibility.  A profile is a specification
of
a minimum.  Perhaps the authors could consider changing the wording to make
that
explicit. Any implementation could offer more than a profile specifies, and
still
be compatible.

Brian

---

From: Peter Blatherwick <[email-masked]>
Date: Thu, 9 Mar 2000 10:48:14 -0500

Keith, list:

I strongly agree with Brian and others here.  I believe what we specifying
by making minimum decisions on encoding and transport is absolutely required
to make the application viable, does not affect other applications, and is
exactly what profiles are intended to do.

I do not think the protocol is deficient.  Profiling is an extremely
valuable aspect of the protocol, especially when combined with the
flexibility and extensibility of packages.

Profiles allow us to make critical decisions on the optional parts for
specific applications, while not restricting how other applications work in
any way.  This both enables interoperability and reduces complexity for the
specific application.  And these decisions set the minimum requirement, not
exclusive requirement.  Such decisions are absolutely required for small
scale, focused applications, of which IP Phone MG is just one example.

As Brian suggests, we will clarify the wording in that area.

-- Peter Blatherwick

> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: 9 Mar, 2000 07:35

---

From: Jeff Ridley <[email-masked]>
Date: Mon, 13 Mar 2000 07:59:03 -0800

Peter and Brian,

I think I completely agree with the conclusions you both seem to have drawn.
Focused applications of the protocol, such as the IP phone are a logical
next step evolving the standardization efforts into specific implementation
definitions that lead to compatibilities between systems and end points.

As a systems vendor, I am anxious to see these definitions or profiles reach
the point where, by following the minimal definition of the profile, the
system can integrate support for different classes of endpoint with
compatibility. This means we need to make a minimal selection where options
exist and leave other choices for flexibility.  If we all implement at least
the minimum, our products inter-operate.  To me, this should be one of the
objectives of the profile.

Jeff Ridley, Sr. Prod. Manager
Shoreline Communications, Inc.

-----Original Message-----
From: Peter Blatherwick [mailto:[email-masked]]
Sent: Thursday, March 09, 2000 7:48 AM
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt

Keith, list: