OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xri] Feedback on section 8 and onwards to XRI WD11-ed06

Gabe: Great comments. See [=Drummond] inline for my notes about the disposition of each comment in ED07.


From: Gabe Wachob [mailto:gabe.wachob@amsoft.net]
Sent: Friday, October 19, 2007 5:50 PM
Subject: [xri] Feedback on section 8 and onwards to XRI WD11-ed06


All comments are based on Line Numbers from the pdf version of ED06.


There was one major issue and a handful of smaller issues:


Line 1055 – Maybe add the word “Service” to the title of Section 8.1 – its not entirely clear that’s the thing you are talking about – its called “Authority Resolution Service” elsewhere


[=Drummond] Done.


Line 1094-95- This is an odd requirement the “Next Authority URI MUST be constructed” – sounds funny – its not really a protocol requirement, is it? It’s just one way to implement the spec (that pseudocode), right? Or is it?


[=Drummond] That whole list (lines 1078-1100) are all requirements of the protocol, so yes, it’s a requirement of the protocol that this URI construction algorithm be followed. However I changed the text to say:


1.   For each iteration of the authority resolution process, an HTTP(S) URI called the Next Authority URI MUST be constructed according to the algorithm specified in section 9.1.10.

[=Drummond] Is that better?



In the diagram Figure 6: the “Yes” line from “Recoverable” to “Next Highest priority URI” – does this line really go to the “Next Highest..” box, or should it go to the top of the diagram (“Construct next authority URI”) (I could be wrong here)


[=Drummond] The reason it goes to the “Next highest priority URI” box is that if the error is recoverable, you need to first choose the next highest priority URI before you go through the Next Authority URI construction step.


Line 1175-1181 – Does this section define a new conformance target – a “community authority”?  How does a community authority differ from any other authority? Is this different than an authority server?


[=Drummond] No, it’s just that, an authority server (or set of them for redundancy). To clarify this, I changed the text to:


This is referred to as the community root authority, and it represents the authority server(s) that answer resolution queries at this root.


Line 1414 – s/NOT REQUIRED to/MAY choose not to/ - that’s much clearer


[=Drummond] Done.


Line 1618-1619 – This summary is a little confusing – these parameters never all appear together – they aren’t “orthogonal” in that sense – in fact, QXRI and path string always overlap, right?


[=Drummond] Good catch. They do. I eliminated this list in favor of Table 9, which already has all this information.


Line 1631 – Table 9 – is confusing because QXRI and path string aren’t really parameters like the others, right? Table 9 feels like two separate tables smushed together.


[=Drummond] Again, good catch. I removed Path String from this table because it’s already defined as part of the QXRI in section 8.1.


Line 1652-1659 (item 7 and item 8) – Examples of the +/%20 and ; escaping and comparison rules would be extremely helpful – also is there language that says these parameters should be unescaped before they are compared per rules in other parts of the spec?


[=Drummond] In order to add the example, I broke off the encoding rules for HXRI query parameters into a separate section (now 11.4) and added an example. It still leaves one question about encoding of + characters – I’ll bring that up in a separate email.


Line 1752 (figure7) – there seem to be some branch labels missing (YES and NO, etc)


[=Drummond] Fixed.


Line 1771 (item 4) – this seems all backwards – if https is false, then you DON’T require a valid HTTPS URL in the xrd:redirect, right?


[=Drummond] My mistake – that is supposed to say “HTTP URI”, not “HTTPS URI”. In other words, if https=false, the only requirement is tha the URI be either an HTTP or HTTPS URI. I reworded it to:


If the value of the resolution media type parameter https is false, or the parameter is absent or empty, the value of the selected xrd:Redirect element MUST be EITHER a valid HTTP URI or a valid HTTPS URI.


Line 1821, 1829, etc (section 11.3) – the phrase “applies iteratively” is a little confusing – you mean “applies everywhere, no matter if you’ve followed Ref’s already (i.e. any level of iteration)”, right?


[=Drummond] Yes. I changed the word to “recursively” to match the rest of the spec.


Line 2289-2291  This rule about removing the forward slash is odd and creates odd-looking scenarios in the example table. What’s the reason?


[=Drummond] The reasoning was that this rule avoids all the leading slash ambiguity. In other words, if you defined that the leading slash had to be part of the <xrd:Path> element, then what would be the meaning of an empty path element, i.e., <xrd:Path></xrd:Path>? Since RFC 3986 states that with HTTP(S) URIs, an authority string without a trailing forward slash and an authority string with a trailing forward slash are considered equivalent. Therefore we said an empty <xrd:Path> element should mean there are no characters FOLLOWING the trailing slash on the authority string.


That said, I’m certainly willing to reverse this if we think that it would be more intuitive to require the <xrd:Path> element to always include the leading slash.


The one concern I have is XRDS documents already in the wild. If we require a leading slash in the <xrd:Path> element, those that don’t have it will break. I don’t think it’s an option to say it’s optional to have the leading slash, because then it becomes ambiguous how to match multiple leading slashes.


Line 2454 – The use of the word “optional” in the phrase “final optional step” begs the question of “whose choice is it, if its optional”? I’d use different language to indicate that service endpoint URI construction happens if either of the following are true: (and then the list)


[=Drummond] Fixed.


Line 2458 – Seems like should be after – the forward reference is awkward


[=Drummond] Fixed.


Line 2460 – s/for/on behalf of/


[=Drummond] Fixed.


Line 2528-2548 – There’s something not lining up – does there need to be a CanonicalEquivID in the example?


[=Drummond] No. This is just an EquivID example. Each XRD has an EquivID that points to the CanonicalID of the other.


Line 2600 – missing “of” between “direct child” and “the value”


[=Drummond] Fixed.


Line 2600 and line 2604 – do you define “direct child”?  Probably need to


[=Drummond] I added the following:


In the first XRD in the resolution chain, the value of the xrd:XRD/xrd:CanonicalID element MUST be a direct child authority of the value of the xrd:XRD/xrd:ProviderID element. i.e., the former MUST consist of the latter plus one additional XRI subsegment as defined in [XRISyntax].


Line 2761, 2790, 2854 – these examples need explanations


[=Drummond] Done.


Line 2773 – s|http://example.user|http://example.com/user|


[=Drummond] Good catch. Fixed.


Line 2871 – here’s the major problem – screwing around with the SAML enclosed element signature profile is a recipe for implementation disaster – I think most of the libraries out there do the saml signature stuff and that’s it – modifying the way signatures are done seems to me like a potential disaster. One solution might be to move the Status element inside the SAML element that is removed by the enclosed signature transform (I forget the details). But the way it is now is that we’ll have to rewrite saml libraries to remove the Status element – blech. I’m worried about implementation of SAML digsig stuff in lots of languages in the first place (like Ruby, Python, etc)


[=Drummond] See my separate post to the list about this.


Line 3009 – This warning doesn’t seem to match the requirement on line 1482 – that line requires that the Query line be matched with the subsegment that was resolved for SAML trusted resolution. Maybe its not 100% in conflict, but its possible to interpret those requirements as being in conflict depending on how the phrase “MUST match the subsegment whose resolution resulted in the current XRD”


[=Drummond] Very good catch. I fixed this with the following language:


IMPORTANT: The effect of these rules is that the application calling an XRI resolver MAY receive back an XRD document, or an XRDS document containing XRD document(s), in which the value of the <xrd:Query> element does not match the resolution request, but in which the value of an <xrd:LocalID> element does match the resolution request. This is acceptable for the generic and HTTPS trusted resolution protocols but not the SAML trusted resolution protocol, where the value of the <xrd:Query> element MUST match the resolution request as specified in section 10.2.4.


I didn’t review the appendixes.


[=Drummond] I hope everyone else is!


Thanks again for the tight review. I will follow this reply with three separate messages (so we can have separate discussion threads) on:


#1) The what-to-recommend-RE-+-encoding issue.


#2) The leading-slash-in-Path-element issue.


#3) The Status-element-and-SAML-signature issue.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]