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:m...@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:f...@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
