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

I'd prefer to not have to define that http://example.com/ would fall  
back to http://www.example.com/ in an OpenID discovery spec as it  
doesn't feel like the right place to do it.  I'd also then hate to see  
a related spec such as OAuth discovery define this fall back in  
another manner.

--David

On Dec 3, 2008, at 11:59 PM, Eran Hammer-Lahav wrote:

>
> > -----Original Message-----
> > From: Mark Nottingham [mailto:mnot@mnot.net]
> > Sent: Wednesday, December 03, 2008 7:35 PM
>
> > So, I see roughly three ways forward here;
> >
> > 1) We can explore expanding the scope of site-meta to be more like
> > 'domain-meta'.
>
> There is nothing in /site-meta (other than the somewhat vague name)  
> that prevent applications from specifying "domain" related links in  
> there. The only requirement is that they use appropriate 'rel'  
> values that will not cause confusion or "ignorant" user-agents to  
> fail. As long as the link record in the file is formatted correctly,  
> consuming applications can do with it as they like. Again, that is  
> as long as their way of using it doesn't break the common use cases  
> specified in the spec.
>
> > 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/
>
> Assuming /site-meta supports a mechanism for listing a template- 
> based link relationship. That template with the appropriate 'rel'  
> will allow mapping a resource URI to its descriptor URI. Based on  
> the template language used, the vocabulary associated with the  
> template or 'rel' and any other application specific rules used, the  
> user-agent can construct the descriptor URI.
>
> How much of this is going to make it into the generic /site-meta  
> spec is very much up in the air at the moment. But either way, as  
> long as /site-meta does not prevent such an application, we can  
> specify this behavior directly in the XRD 1.0 spec, which hopefully  
> OpenID 2.x will adopt. And XRD is not going to care if the URI  
> scheme is mailto, http, or im. It will provide a mechanism to find  
> the desired map for that URI scheme with the appropriate vocabulary.
>
> This open question for this discussion on this list is really how  
> much of this should be supported by the generic /site-meta spec. I  
> would really like to hear from people without a stake in the OpenID/ 
> identity space. If there are no other use cases at the moment, it  
> will be hard for me to keep pushing for this in the /site-meta  
> proposal. But I am very much still committed to the overall  
> solution. OpenID is not going to reference /site-meta. It is going  
> to reference XRD 1.0, so it doesn't matter how this functionality  
> got into XRD 1.0 (via normative references to /site-meta or  
> specified locally).
>
> > 3) You can decide that site-meta isn't for you, and come up with  
> your
> > own thing.
>
> I would really like to avoid it. If /site-meta cannot accommodate  
> the use cases that got me involved in it to begin with, I do not see  
> much reason for me to be involved in it or have my name on it. But I  
> don't think we are at this point, and in fact, the current draft  
> without any changes already allows for this use case. It is more the  
> next text proposal that is lacking in that regard.
>
> > 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 am not sure what you mean by 'allowing discrimination between  
> hostnames and schemes'. Can you explain? The URI mapping use case  
> pretty much requires a scheme filter if the vocabulary is to include  
> anything other than 'uri'.
>
> I understand your reservation about the fallback scenario and my  
> position on this is that it is very much an OpenID specific issue  
> (not even an XRD issue) of how to normalize a user identifier (URL,  
> XRI, or email). Generic discovery should never make such assumptions  
> (that www.example.com is equivalent to example.com). I raised the  
> issue because it came up and wanted people to discuss it and see if  
> there are other existing solutions to the problem.
>
> EHL
>