On 04/12/2008, at 5:13 AM, Dirk Balfanz wrote:
Ok, I think the discussion has derailed a little bit.
The question at hand was whether we should have a fallback flow for
site-meta on naked domains.
The rationale behind this seemed to come largely (only?) from an
OpenID use case, where the user-supplied identifier mentions only
the naked domain "domain.com", but the site-meta document is served
off www.domain.com.
The reason only the naked domain is in the user-supplied identifier
could be because it was derived from an email address, or because
the user was lazy when typing their OpenID URL, or doesn't know the
difference and uses the naked/full domains interchangeably (did I
miss other reasons?).
The reason the site-meta document is served off www.domain.com
instead of domain.com is because the owner of that domain is not
technically savvy enough to understand the difference/move to a
provider that allows him to serve something off the naked domain, etc.
There was an objection that site-meta (which is served over http)
should not be authoritative for email: URI schemes, but I think that
was voted down :-)
There isn't any voting here.
The idea behind site-meta is to provide a generic way to talk about
site metadata in the simplest possible way, so that new "well-known
locations" can be avoided in the future. As such, it needs to be
simple and robust enough to work for a number of use cases, not just
the ones you're bringing to the table. From what I've seen, a lot of
people have been receptive to site-meta because of this.
So, I see roughly three ways forward here;
1) We can explore expanding the scope of site-meta to be more like
'domain-meta'.
2) In your specs, you can specify that when looking up the OpenID for mailto:[EMAIL PROTECTED]
, the place to get site-meta is http://example.com/, falling back to http://www.example.com/
3) You can decide that site-meta isn't for you, and come up with your
own thing.
I'm concerned about #1, because it will likely involve things like
allowing discrimination between hostnames and schemes in site-meta
itself, as well as defining fallback behaviour, which will sacrifice
the simplicity that so many people are finding attractive. IME these
things take a lot of time to get right, and AIUI you don't have a lot
of time.
I've suggested #2, and you responded with:
Seems to me that although the last objection is somewhat
speculative, if there are no other use cases for this than OpenID,
maybe the OpenID discovery spec is where the fallback flow belongs?
I think that's the right thing to do, and also the place to tie in the
e-mail address identifier, if that's what you want to do.
I hope we can avoid #3, but if it's the right thing to do, so be it.
Cheers,
--
Mark Nottingham http://www.mnot.net/
