> On 12/28/12 8:45 AM, Theo Zourzouvillys wrote: > > On Tue, Dec 18, 2012 at 4:24 PM, Paul Kyzivat <[email protected]> > wrote: > >> I don't think so. But maybe others will find a justification for > doing so. > > > > I don't think it is valid - although it's totally underspecified. > > > > user=phone implies the user portion is a tel URI, and > > tel:anonymous.invalid;phone-context=+1 isn't legitimate - so i can > see > > why a parser would fail it, as even if it was matching a > > local-phone-number only hex digits would be allowed. > > Yeah, that makes some sense. > > 3261 is indeed underspecified about this. What it says is: > > The user URI parameter exists to > distinguish telephone numbers from user names that happen to > look like telephone numbers. If the user string contains a > telephone number formatted as a telephone-subscriber, the > user > parameter value "phone" SHOULD be present. > > It doesn't ever say the flip of that: "If the user parameter value > "phone" is present, the user string (SHOULD/MUST?) be formatted as a > telephone-subscriber". > > If that is not so, then the parameter doesn't have a lot of value.
I agree that RFC 3261 is underspecified. RFC 2543 was a little more clear. "If the host is an Internet telephony gateway, the user field MAY also encode a telephone number using the notation of telephone-subscriber (Fig. 4). The telephone number is a special case of a user name and cannot be distinguished by a BNF. Thus, a URL parameter, user, is added to distinguish telephone numbers from user names. The phone identifier is to be used when connecting to a telephony gateway. Even without this parameter, recipients of SIP URLs MAY interpret the pre-@ part as a phone number if local restrictions on the name space for user name allow it." _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
