Re: Comments on RFC2806bis

> Commas are no problem, and coding is
> no problem.  It would be a deployment
> and interoperability inconvenience resulting
> from some devices supporting rfc2806,
> others only supporting rfc2806bis.

You haven't identified what these "inconveniences" would be. I think 
there's general agreement that allowing random character string in 
context is a potentially large interoperability problem, so we have to 
pick our poison.


> Agreed.  Just as an FYI, rfc2806 section
> 2.5.11 mentions to reject the request 
> if any parameters were unknown.  For 
> example if cic was present and you do 
> not know what cic means, the message
> MUST be rejected.

We want to arrive at a more nuanced version, I think. Thus, the 
distinction between the two parameter types.


> 
> The rfc2806bis definition of phone-context 
> replaced the private-prefix with domainname.
> Both have effectively the same meaning within 
> telephone-subscriber; however domainname
> reduces the character-set of what can be 
> considered a valid value within phone-context.  

As noted, any other random strings are likely to collide and thus create 
interoperability issues.

> 
> rfc2806bis also imposes a domainname 
> format upon rfc2806's private-prefix.
> 
> The rfc2806bis example of
> phone-context=cs.columbia.edu
> isn't valid in rfc2806
> because it started with a 'c'.
> 
> I agree that the new phone-context 
> definition is better since it forces 
> structure for potential use with DNS, and it 
> provides an explicit solution to avoid 
> accidental duplicate private-prefix names.
> 
> We can reformat our rfc2806 usage of 
> private prefixes to accommodate the 
> rfc2806bis format.

Glad to hear that. There having been no other notes on this topic, can 
we declare it closed?