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