Re: Comments on RFC2806bis

At 3:55 pm -0400 22/5/02, Henning Schulzrinne wrote:
>>The name change would cause grief for BroadSoft because we have 
>>products deployed within networks which send, receive, and
>>use phone-context.  An attempt to rename or introduce a short-form 
>>of the parameter would complicate interoperability.
>
>Sounds like a definitive answer. It stays "phone-context".

This saves each of my guys at least 30 seconds quality time, so fair enough.

I am, however, surprised if Brett means that a comma-separated list form
will cause grief. Anyone dealing with tel: URIs will almost certainly have
to deal with other parameters (mandatory or otherwise :).


>  it is.
>>
>>Also rfc2806 allowed a much greater non-escaped character-set for 
>>the phone-context value.  Reducing this character-set within 
>>rfc2806bis will
>>potentially also cause some grief.
>
>The previous definition was not interoperable, so I'm not inclined 
>to change this. This is not a character-set issue but defining in a 
>meaningful way what phone-context means and minimizing the damage 
>caused by local phone URIs that escape their intended scope. I 
>believe there was group consensus on that, but as usual in the IETF, 
>this is subject to re-discussion at any point :-)
>
I also will be VERY unhappy if the old Reverse Hungarian is retained.
I understand 2806bis phone-context to a pure sub-set of the 2806 list
of hex ranges. It's also clear in intent, exactly as Henning says.

Testing therefore should not be a problem - your installed base is
capable of handling this "narrowed" set adequately.

Brett - are your machine generating private context values, or the 
local-prefix Morse code allowed in 2806?
I'm Puzzled.

all the best,
    Lawrence
-- 
[email protected]: +44 1794 833666::<my opinions>: