RE: [xri] This whole mailto business...

["Drummond Reed" <drummond.reed@cordance.net>]

I'm generally comfortable with this -- I'd really like HRDD to be one of
those specs that is so clean and clear it lasts for years. However I should
at least point out that specifying the authority for an email address (RFC
2822 Section 3.4.1 calls it a "domain") seems very easy and clean (provided
that the mailto: includes only one email address -- I just found out RFC
2368 allows it to include more than one). 

So I think it's more a matter of deciding if the overall principle is that
HRDD as a spec will not say anything in particular about other URI schemes
besides http: (and https: - that's still outstanding). That seems like a
reasonable approach to take.

In that case I would suggest adding some text explicitly stating this scope
limitation (you already have something like this), e.g., something like:

	"Although HRDD MAY be used with URIs from any URI scheme, the
definition of how to map URIs from non-hierarchical URI schemes is beyond
the scope of this specification. A specification that defines such a mapping
SHOULD ensure it is unambiguous and SHOULD include adequate security
considerations."

=Drummond 


> -----Original Message-----
> From: George Fletcher [mailto:george.fletcher@corp.aol.com]
> Sent: Friday, January 16, 2009 9:48 AM
> To: Eran Hammer-Lahav
> Cc: xri@lists.oasis-open.org
> Subject: Re: [xri] This whole mailto business...
> 
> +1
> 
> If more use cases arise it might make sense to have one doc that shows
> how to map mailto URL's to HRDD but still keep it out of the HRDD spec.
> 
> Breno de Medeiros wrote:
> > I think this is a prudent approach. I am generally in favor of letting
> > any thorny authority issues for non-HTTP URIs to be dealt with by
> > applications.
> >
> > On Fri, Jan 16, 2009 at 9:31 AM, Eran Hammer-Lahav
> > <eran@hueniverse.com <mailto:eran@hueniverse.com>> wrote:
> >
> >     Dave Cridland brought up a good point on the APP list which is
> >     that mailto URIs don't have an authority section. For some reason,
> >     I was sure that the entire email address is the authority and is
> >     parsed based on RFC 3986 section 3.2. But this is incorrect.
> >     mailto URIs don't have an authority since they do not begin with
> >     mailto://.
> >
> >     This means that in order to support mailto URIs, HRDD must
> >     explicitly deal with mailto URIs and provide rules as to how to
> >     extract their authority. This is doable but no longer the clean
> >     and generic proposal it was meant to be.
> >
> >     This is all getting very complicated which leads me to make the
> >     following suggestion. At this point we have two (theorized) use
> cases:
> >
> >     1. Use emails to register to a site, allowing the site to perform
> >     discovery and find out where the user's address book it.
> >     2. Use email identifiers as an OpenID identifier.
> >
> >     Both can come up with their own way to go from the email address
> >     to an XRD document very easily, even using the methods defined by
> >     HRDD. So there is no *requirement* for us to address this (this
> >     was covered on the call last week) as XRI doesn't define mailto
> >     binding.
> >
> >     I'm inclined to remove references to mailto URIs from the HRDD
> >     specification, mostly because I am not inclined to directly
> >     address authority extraction from a mailto URI path. This doesn't
> >     solve the scope question of Site-Meta but it moves the problem
> >     from HRDD to a potential OpenID discovery spec.
> >
> >     What do you think?
> >
> >     EHL
> >
> >
> >
> >     --------------------------------------------------------------------
> -
> >     To unsubscribe from this mail list, you must leave the OASIS TC that
> >     generates this mail.  Follow this link to all your TCs in OASIS at:
> >     https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >
> >
> > --
> > --Breno
> >
> > +1 (650) 214-1007 desk
> > +1 (408) 212-0135 (Grand Central)
> > MTV-41-3 : 383-A
> > PST (GMT-8) / PDT(GMT-7)
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php