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

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