[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] 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 1.2.7.1 should be after 1.2.7.2
– 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. =Drummond |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]