Some questions: Metadata Rels and Host-meta use case

Because of well-known use case needs, such as host-meta, which were
left out of the core spec, it is likely that applications will
implement meta-data type rels. For instance, consider a host-meta that
wants to delegate the OP endpoint to some other site, but additional
metadata to somewhere else:


<Link>
  <Rel>http://openid.net/op-metadata</Rel>
  <URI>https://foo.com</URI>
</Link>
<Link>
  <Rel>'described by'<Rel>
 # other stuff goes here
  <URI>http://bar.com</URI>
</Link>

Now, if the client is some greedy protocol like webfinger, that is
looking for all meta-data, it will match on everything that is labeled
meta-data-y, i.e., will look for 'described by' only. So it will not
learn the openid endpoint (it does not know the openid-specific
metadata pointer).

So, to fix webfinger, the site changes the host-meta to:

<Link>
  <Rel>http://openid.net/op-metadata</Rel>
  <Rel>'described by'<Rel>
  <URI>https://foo.com</URI>
</Link>
<Link>
  <Rel>'described by'<Rel>
 # other stuff goes here
  <URI>http://bar.com</URI>
</Link>

But this does not have the anticipated effect. The reason is that
non-greedy clients looking for specific metadata will only fetch the
first element with 'described by' per typical processing rules (since
the more specific metadata type is not listed). So that doesn't work
either.

So the site will have to edit the document to:

<Link>
  <Rel>http://openid.net/op-metadata</Rel>
  <URI>https://foo.com</URI>
</Link>
<Link>
  <Rel>'described by'<Rel>
 # other stuff goes here
  <URI>http://bar.com</URI>
  <URI>https://foo.com</URI>
</Link>

Moral of the story: It is not clear how processing rules and Rels that
have inclusion characteristics (i.e., all foo of relA are also of
relB) play together with processing priority rules.

-- 
--Breno

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