> -----Original Message----- > From: Fischer, Kai [mailto:[EMAIL PROTECTED] > Sent: Monday, April 07, 2008 1:25 AM > To: Dan Wing; [email protected] > Cc: Elwell, John > Subject: RE: [Sip] Migration from E.164 to email-style SIP URIs > > That's an interesting proposal. I didn't get if your intention is to > sign both headers (From header with E.164 and 'email-identity' header) > or only the email-based one.
For the purposes of my straw-man, you can assume (a) we have resolved all problems with signing E.164s in From, or you can assume (b) we have not resolved any problem with signing E.164 in From -- either way, my proposal still provides benefit: the called party can use the email- style address to establish end-to-end identity with the calling party, and can use that to establish an end-to-end SRTP session (using a mechanism similar to your draft or the Wing/Kaplan draft). > In case signing both, an identity binding between the E.164 > SIP URI and > the email based one is created, which results into the other problems > with RFC 4474 discussed in the two mail threads 'RFC 4474 and PSTN' / > 'RFC 4474 and SBC traversal'. > > In case signing only the 'email-identity' header, does this mean that > email-like SIP URIs are only provided in the new header field (because > they are signed) and not in the From header in the long term (after > migration ;-)). Once both endpoints know they can use email-style URIs, they could put the same information into the From and into the Email-Identity headers -- or sign the From and ignore the email-identity. -d > Kai > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > > Behalf Of Elwell, John > > > Sent: Friday, April 04, 2008 1:19 AM > > > To: [email protected] > > > Subject: [Sip] Migration from E.164 to email-style SIP URIs > > > > > > On this thread I would like to explore what can be done > in terms of > > > avoiding the issues concerned with RFC 4474 and E.164-based > > > SIP URIs by > > > migration towards the use of email-style URIs. > > > E.164-based URIs will still be needed, particularly for > interworking > > > with PSTN but also in those SIP environments where E.164 > numbers are > > > more easily handled (e.g., phones with number-based user > > interfaces). > > > But perhaps we can explore more the possibility of using > > the two forms > > > in parallel, e.g., E.164-based in PAI (e.g., as TEL URI) and > > > email-style in From. I know Dan has an interesting straw man on > > > this topic, which I will allow him to present himself. > > > > One idea that someone (Jonathan?) posted to SIP, about a week > > before the Philadelphia meeting, was to mix both e.164 and email > > style identifiers. In that email, it was suggested to use a > > separator between the two (a "*", as I recall). > > > > I have been thinking about using both E.164-style and email-style > > URIs in parallel, for two reasons: > > > > 1. provide a migration path from E.164-style URIs to email-style > > URIs > > 2. allow stronger identity to be asserted for email-style URIs > > > > > > Here is a straw-man idea: > > > > On an outgoing request containing an e164-style URI in the From: > > (or PAI, as you prefer), the domain additionally places the user's > > email-style URI into a new header (let's call it "email-identity"). > > It determines the mapping between a user's E.164 URI and email URI > > using a flat database (example: +14085551234 -> [EMAIL PROTECTED]). > > > > This new header is signed along with everything else we like to > > sign [choose RFC4474, draft-fischer-sip-e2e-sec-media-00.txt, or > > draft-wing-sip-identity-media-02.txt, as you prefer]. > > > > If the receiving domain understands email-identity, it validates > > the claimed identity, and it presents the email-style URI to the > > called party. Thus, the E.164 in the From: (or in the PAI) is > > essentially ignored. If the receiving domain does not understand > > email-identity, the receiving domain does not enjoy any benefits > > of the email-identity header and does not experience any harm from > > the email-identity header. > > > > This provides a backwards-compatible way to migrate to email-style > > URIs, and gives us strong identity with those email-style URIs. > > > > -d > > > > _______________________________________________ > > 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 > > _______________________________________________ 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
