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: Feedback on section 8 and onwards to XRI WD11-ed06


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

 

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

 

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?

 

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)

 

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?

 

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

 

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?

 

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.

 

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?

 

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

 

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?

 

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?

 

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?

 

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)

 

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

 

Line 2460 – s/for/on behalf of/

 

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

 

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

 

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

 

Line 2761, 2790, 2854 – these examples need explanations

 

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

 

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)

 

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”

 

I didn’t review the appendixes..



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