I have been pestering various people off list, and have decided to see whether someone else understands and can explain this in a way I can follow. The following is somewhat longer than I like. Sorry.
The pair of questions is: When should the user part of a SIP URI be considered an E.164 number? And what assertion is being made by such consideration? Taking them backwards, as far as I can tell from reading the RFCs and the I-Ds, the assertion that is supposed to hold is that if a SIP URI can be properly understood to have an E.164 number in it's user part, and if it legitimately has that number, then the party the SIP URI represents can also be reached by calling the E.164 number on the PSTN. There are some interesting ambiguities left even with that definition, but we can live with it. So, when does the user part have an E.164 number, so that it is reasonable to ask if the assertion holds? As far as I can tell, there are three cases: Case 1 - No ;user=phone option In the absence of a ;user=phone option, the user part of the SIP URI should be considered an opaque string. It should not be considered an E.164 number, even if it is formatted as a telephone subscriber number. I can legitimately use [EMAIL PROTECTED] as a SIP URI. And if the whitehouse.com deliberate confusion is still active, they could use [EMAIL PROTECTED] as a SIP URI. It is reported that some SIP devices will display the phone number without the domain for such URIs. That is a UI error, not a protocol error. The protocol can not make the UI do the right thing. Case 2 - ;user=phone option present, no ;phone-context= option I believe this is an assertion that the user part of the SIP URI is an E.164 number, and that if one is doing validation E.164 validation is appropriate. The whole question of the meaning of the domain, and whether we are better off with tel: URIs applies to this form of SIP URI. While it is possible (any character string is possible) to have a SIP URI with ;user=phone and no ;phone-context and not have the user part formatted as a telephone-subscriber number, such a mismatch looks to me to be a violation of RFC 3261. The only reasonable handling is that if one is trying to perform E.164 validation, such validation will fail on such a SIP URI. Case 3 - ;user=phone and ;phone-context= options present The RFCs seem to say explicitly that the user part of the SIP URI can not be considered an E.164 number, and that one can not even expect to concatenate the phone context and the user part to get an E.164 number. So there can be no E.164 validation because there is no E.164 number. Some folks seem to have suggested that one should observe the format of the user part of the SIP URI in order to decide if an E.164 number is intended. I sincerely hope that is note the case. Yours, Joel M. Halpern _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
