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

On Wed, Dec 3, 2008 at 7:35 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
> 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/

This may not work so well if the resource-map cannot handle mailto
URIs. I am not sure where the resource-map is being standardized, if
it is just going to be a resource linked from site-meta or will be in
/site-meta. If only linked, (2) is a fine solution and we can have
this discussion in the definition of the resource-map format. If
directly part of site-meta than it is unlikely that (2) will address
all email-based discovery needs, though may be sufficient for OpenID.

>
> 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/
>
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

Received on Thursday, 4 December 2008 06:23:45 UTC