RE: Comments on RFC2806bis

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

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.

> Anyone dealing with 
> tel: URIs will almost certainly have
> to deal with other parameters 
> (mandatory or otherwise :).

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.
 
> Brett - are your machine generating 
> private context values, or the 
> local-prefix Morse code allowed in 2806?
> I'm Puzzled.

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.  

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.