I agree with narrowing of options, but market reality means the MGC's in most cases must support both. That's what I was referring to.

At 01:21 PM 3/3/00 -0500, Rosen, Brian wrote:

Matt

The protocol states MGCs SHOULD support both. That is not a requirement.

The purpose of a profile is to narrow down the breadth that the protocol specifies so that you can plug an MG into an MGC and you KNOW that they will play. This is generally NOT the case with a random MG plugging into a random MGC - there are lots and lots of things that would make them not compatible, and still both be conformant to the protocol.

For each and every option possible in the protocol, a well defined profile should specify a minimum requirement. A conformant device should be able to go above the minimum. This means in every profile, a choice will be made on encoding. If this is not done, then a customer cannot tell by comparing the profile of an MG whether it will be compatible with his MGC. He should absolutely be able to do this.

In this case, if an MGC advertises that it conforms to the IPPhone profile, but does not support text encoding, it is not out of compliance with either the protocol or the profile. If you try to plug a binary-only IPPhone into such a system, it won't work. That is, in my opinion, unacceptable.

I will even go so far as to say that the minimum is also the preferred - even if the device can do more, the point of a profile is to specify a set of option choices that will allow 100% compatibility. If you have a device that REQUIRES some profile x PLUS some feature y, then it would be better to define a new profile as being an extension of x to include y.

Brian

...

-----Original Message----- From: Matt Holdrege [mailto:holdrege@lucent.com] Sent: Friday, March 03, 2000 12:56 PM To: Rosen, Brian Cc: ITU-SG16@mailbag.cps.INTEL.COM Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt

If MGC's must support both text and binary, what does it hurt to allow IP phones to do either?