Re: Fallback flow for /site-meta for top level domains

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:foo@example.com 
, 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/

Received on Thursday, 4 December 2008 03:35:48 UTC