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:]
> Sent: Friday, January 16, 2009 9:48 AM
> To: Eran Hammer-Lahav
> Cc:
> 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
> > < <mailto:>> 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
