> -----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
