> It was my take that Mr(Ms) +11234567890 ... Note that I closed the initial portion of my message body with "=JeffH". But also note that it take clues/hints/traditions/conventions outside of the rules of the set of email RFCs to identify what might be the nominally socially correct "name" (note "names" are not always "identifiers") to use to refer to me. And you'll get different answers from different entities. (some would perhaps suggest "obnoxious" or something similar). ;)
Anyway, from my perspective, either is fine for the purposes of this discussion. Also note that I copied my message to "[EMAIL PROTECTED]", which by the way, will indeed "reach" me via email, even though the "local-part" is indeed a valid +1 PSTN number, but not one I "control", beyond it's association (in this context) with kingsmountain.com. Hm, I may need to enable SIP-based comms for it.... Paul Kyzivat wrote in reply to Adam Roach:: > > But there are a lot of people who seem to think > it is fine to take any user part that looks vaguely line a phone number > and treat it as such. > > It was my take that Mr(Ms) +11234567890 specifically feels that way. Actually, no, that is not what I was attempting to say. Rather, what I was attempting to say is that.. It is nominally not correct (for some definition of correct) to take a "user" part (aka "local-part" in RFC2822 parlance), from the "[EMAIL PROTECTED]" sub-construct of the "SIP URI" construct defined in RFC4474, and interpret its real-world attributes, or attibutes it might have in another protocol context, outside of the current protocol context (i.e. SIP), unless hints/extraContext/whatever are also present in the latter protocol context -- regardless of the syntactic construction of said "user" part. I also agree with a converse of the above.. It is nominally "a leap-of-faith" to take a "user" part (aka "local-part" in RFC2822 parlance), from the "[EMAIL PROTECTED]" sub-construct of the "SIP URI" construct defined in RFC4474, and interpret its real-world attributes, or attibutes it might have in another protocol context, outside of the current protocol context (i.e. SIP) -- regardless of the syntactic construction of said "user" part -- unless, hints/extraContext/whatever are also present in the latter protocol context. Paul Kyzivat went on to say: > > My understanding is still that even > > "sip:[EMAIL PROTECTED];user=phone" and > "sip:[EMAIL PROTECTED];user=phone" > > are *different* and should be > announced as such. Certainly the routing rules are different for > reaching the two of them, and that can be significant. There was sentiment in the room here @Philly/IETF-71 yesterday morning, that the "user" part of those two above identifiers SHOULD be treated by UAC/UA/UE as the "same", and that various present SIP RFCs at least imply such (I don't know myself, need to research it), though it is not currently consistently implemented that way. > IMO if you want an address that can be displayed simply as a phone > number, then you should use a TEL for it. Sure, for header fields such as To and Request-URI, but the issue here is what to assert in the From header field such that one can sign it (and other SIP msg components) and have some sort of linkage back to a trust anchor. =JeffH aka [EMAIL PROTECTED] ps: I didn't send my original message from my actual @messaging.sprintpcs.com email address for two reasons.. 1. I didn't want that email address and phone number published on the web in email archives. 2. I didn't want to receive the SIP mailing list as SMS messages on my PDA/phone (scary). --- end _______________________________________________ Sip mailing list https://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
