[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]