Suggestion on email parsing

[Peter Davis]

I wanted to bring to your attention a suggestion i raised on the XRDS-
Simple mailing list last night [1] which proposes a DNS-based approach
to email to URI transformation. this is, incidentally, based on the
same design pattern used in fixed and mobile telephony networks for
telephone address to SIP URI transforms (aka ENUM - RFC3761 [3][4]).

The basics involve publishing a DNS resource record (NAPTR, which
supported in most all DNS stacks today) which advertises a regular
expression into which one inserts the email address, the output
becomes a URI from which an XRDS could be obtained. An example for
the use cases being discussed here:

$ORIGIN example.biz.
;; order pref f
service regexp or replacement
IN NAPTR 100 10 "U" "RFC28222U+xrds "!^([^@]+)@(.*)$!https://foo.example.biz/fetchxrds?
\1!" ""

so if the input string is pet...@example.biz, the output becomes

https://foo.example.biz/fetchxrds?peterd

having the publisher of the identifier (email addr) control the
location of the endpoint for XRDS retrieval seems like a huge benefit
(rather than fixed, well-known URIs) for flexibility, yet retaining
interoperability.

This same pattern was spec'd out back in 2005 in SAML2 for IDP
provider discovery [2], in which this is covered in some detail.

thoughts?

=peterd

[1] http://groups.google.com/group/xrds-simple/browse_thread/thread/54cc3aebb40d315c/a1c937438664dbb9
[2] http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
[3] http://www.ietf.org/rfc/rfc3761.txt
[4] http://en.wikipedia.org/wiki/ENUM

[Will Norris]

I missed that current discussion thread until you mentioned it (all
read up now), but we generally do stay abreast of XRDS-Simple
developments. We had talked about alternate discovery mechanisms
early on, particular for the same reasons being discussed on the other
thread -- large email providers not wanting to add the XRDS stuff on
every request. However, we would then be breaking the XRDS-Simple
protocol which we didn't feel comfortable doing. We do fully intend
to say lock-step with the next version of XRDS-Simple, so any
additional discovery methods would need to be added there.

-will

[Peter Davis]

Understood. just to put some context around my recommendation...

I co-chair the XRI TC, from which much of this has been derived, and
we (the TC) are presently exploring these issues, and considering
community feedback for incorporation into future revisions of the
specs (which also includes XRDS schema updates to accommodate the XRDS-
Simple needs).

I guess in part i am seeking feedback on this potential contribution
into the TC... would it help your needs or not (assuming it is adopted
by XRI, XDRS-Simple, Oauth, openID, etc...

=peterd