[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
Great feedback, Gabe. I’ll go
through these line-by-line in the spec tonight and then send a reply about the
disposition of each as soon as I’m done. I see Wil is also going to send more
feedback. Anyone else, PLEASE do send feedback ASAP, so we can get all these
items (nothing is too small!) into ED07. I have a call at 1PM PT on Wednesday
with Mary McRae at OASIS to go over final formatting and other logistical
requirements for the Committee Draft version, and I promised to get her ED07
tomorrow so she has a full day to look it over. =Drummond From: Gabe Wachob
[mailto:gabe.wachob@amsoft.net] 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]