Questions in case of multipul Types for one Service

[Johannes Ernst]

Your question is, I think, about the NetMesh implementation, so let  
me try and answer it.

My understanding of what we defined in Yadis is that:

<Service>
  <Type>A</Type>
  <Type>B</Type>
  <URI>U</URI>
</Service>

is semantically equivalent to

<Service>
  <Type>A</Type>
  <URI>U</URI>
</Service>
<Service>
  <Type>B</Type>
  <URI>U</URI>
</Service>

At least for Types A and B that are not too tightly dependent on each  
other. So far, anybody disagree with that?

You are right that there is no point in assigning different  
priorities to "non-substitutable" Service types. ("Non-substitutable"  
meaning here that I cannot use format negotiation instead of VCard  
queries, while "substitutable" would be LID GPG-based SSO vs. OpenID  
Sign-on)

But then, I don't think it is invalid or misleading either: a  
consumer of this file will simply look for the Service Types it  
understands, and of those the kinds it is looking for, and find 0 or  
1 matches, thereby ignoring priorities (with the exception of LID GPG- 
based SSO vs. OpenID SSO). So I don't think the file we produce is  
either wrong or misleading.

(But the real reason that you are seeing this is that our simple  
implementation behind it represents the set of Services at this URL  
in an array, ordered by priority, and when it dumps it out, it just  
assigns the array index as priority, without looking at  
substitutability, and without looking whether or not they could be  
"collapsed" into a single service statement).

If somebody makes a convincing argument why the latter is needed,  
we'll implement it ...


On Apr 14, 2006, at 16:04, OHTSUKA Ko-hei wrote:

> Question.
>
> On OpenID, extensional protocol shows in Yadis,
>
> <Service>
>   <Type>http://openid.net/signon/1.2</Type>
>   <Type>http://openid.net/extensions/sreg/1.0</Type>
>   <URI>http://www.myopenid.com/server</URI>
> </Service>
>
> But on LID, many Yadis example shows like
>
>   <xrd:Service priority="1">
>    <xrd:Type>http://lid.netmesh.org/minimum-lid/2.0b8</xrd:Type>
>    <xrd:URI>http://mylid.net/foo</xrd:URI>
>   </xrd:Service>
>   <xrd:Service priority="2">
>    <xrd:Type>http://lid.netmesh.org/sso/2.0b8</xrd:Type>
>    <xrd:URI>http://mylid.net/foo</xrd:URI>
>   </xrd:Service>
>   <xrd:Service priority="3">
>    <xrd:Type>http://lid.netmesh.org/sso/1.0</xrd:Type>
>    <xrd:URI>http://mylid.net/foo</xrd:URI>
>   </xrd:Service>
>   <xrd:Service priority="4">
>    <xrd:Type>http://lid.netmesh.org/relying-party/2.0b8</xrd:Type>
>    <xrd:URI>http://mylid.net/foo</xrd:URI>
>   </xrd:Service>
>   <xrd:Service priority="5">
>    <xrd:Type>http://lid.netmesh.org/traversal/2.0b8</xrd:Type>
>    <xrd:URI>http://mylid.net/foo</xrd:URI>
>   </xrd:Service>
>
> So, I have two question.
>
> 1. If there are no priority differences among every services,
>    upper xrds meaning may be same as
>
>   <xrd:Service>
>    <xrd:Type>http://lid.netmesh.org/minimum-lid/2.0b8</xrd:Type>
>    <xrd:Type>http://lid.netmesh.org/sso/2.0b8</xrd:Type>
>    <xrd:Type>http://lid.netmesh.org/sso/1.0</xrd:Type>
>    <xrd:Type>http://lid.netmesh.org/relying-party/2.0b8</xrd:Type>
>    <xrd:Type>http://lid.netmesh.org/traversal/2.0b8</xrd:Type>
>    <xrd:URI>http://mylid.net/foo</xrd:URI>
>   </xrd:Service>
>
>    Is this understanding right?
>
> 2. I have little knowledge about LID, so writing below is maybe
>    misunderstanding,
>    But I think LID's each protocols (sso,relying-party,traversal,
>    etc...) are used for different usecases, so adding different
>    priorities to them is nonsense.
>
>    Though seeing XRD files examples including LID, almost all
>    examlpes adding different priority to each LID protocol.
>
>    Are there any reason to do like this?

Johannes Ernst
NetMesh Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20060414/2fffc8b5/lid-0001.gif
-------------- next part --------------
  http://netmesh.info/jernst