Re: [xri] Feedback on section 12 of WD11-ED06

["Tan, William" <William.Tan@neustar.biz>]

Drummond,

My comments to your replies are inline. Sections that are trimmed off 
means that I'm ok with them.

Drummond Reed wrote:
>> 12.1 Line 2211 - "For each xrd:Service element in the final XRD,
>> selection MUST follow the service endpoint selection logic defined in
>> section 12.2".
>> This seems like we are prescribing a single for loop, even though the
>> full process is described in 12.2. Perhaps something more like "Section
>> 12.2 describes the processing logic for selecting a set of SEPs from the
>> final XRD based on the QXRI and other resolution input parameters"?
>>     
>
> [=Drummond] I made this clearer by wording it as follows:
>
> 3.	For each the set of all service endpoints (xrd:Service elements) in
> the final XRD, selection MUST follow the service endpoint selection logic
> defined in section 12.2. The outcome of this process will be a selected set
> of zero or more service endpoints.
>
>   

Hmm.. this still reads like a single for loop to me. How about the 
following?

The set of all service endpoints (xrd:Service elements) in the final XRD 
MUST be processed according to the service endpoint selection logic 
defined in section 12.2. The outcome of this process will be a selected 
set of zero or more service endpoints.

If you don't agree with the above, I guess the original is fine. I just 
didn't want us to prescribe different logic from different sections of 
the spec.

>> 12.1 Line 2222 - I'm not sure if we should be defining Output Formats in
>> section 7. The output formats seem very specific to the proxy resolver.
>> IMHO the output of core resolution logic should be defined as an
>> abstract data type, rather than concrete format.
>>  For example, OpenXRI returns a data structure, not a DOM document, for
>> the resolveSEPToXRDS method.
>>     
>
> [=Drummond] No one has ever raised this issue before. The outputs of XRI
> resolution have always been defined to be an instance of one of the 3 media
> types we specify in the spec (application/xrds+xml, application/xrd+xml,
> text/uri-list), or, for a proxy resolver, an HTTP(S) redirect. I don't think
> it's a problem for a local resolver to return something else, but it seems
> like it's out of scope for the spec. Maybe in section 7 we should state
> something like that. What do you think?
>
> *****MORE DISCUSSION NEEDED?*****
>   

I agree that the ADT returned by a local API is definitely out of scope 
for this spec.
Actually, after reading section 7 a bit more, I think it's fine. Let's 
just keep it this way but clarify that the local resolver can return 
something else.


>> 12.3.4 - why do we need this special rule? Isn't it backwards
>> incompatible with WD10? This seems to conflict with the definition in
>> section 12.3.2 that when the match attribute is absent, use the content.
>> In this case the content is null, so it should just be equivalent to
>> match="null".
>>     
>
> To the contrary, adoption of this rule solved a big ambiguity in WD10,
> because it was unclear what happened with empty elements. There was a lot of
> discussion about this last spring, and this was the unanimous decision. The
> conclusion was that empty elements were a poor way to express that you
> wanted match="null" because that's a relatively rare condition -- it would
> be much better in for that specific case to explicitly require match="null".
>
> By contrast, having a particular selection element (e.g., MediaType) simply
> not be relevant to selection of a SEP is far more common. And it's more
> intuitive that, if a selection element doesn't matter, the XRD author should
> just be able to leave it out. Since we have a rule throughout the spec that
> the absence of an element or attribute and its presence with an empty value
> must mean the same thing, we defined both in this case to mean a DEFAULT
> match. It doesn't conflict with 12.3.2 because we explicitly defined this
> rule.
>
> *****MORE DISCUSSION NEEDED?*****
>   

If the intention of the XRD author is to math null, <X match="null" /> 
should be used. I agree with that.
If the intention of the XRD author is to do a DEFAULT match, <X 
match="default" /> should be used. Alternatively, if no other elements 
of the same SEL category is present, the element can be left out 
altogether as defined in "12.3.3 Absent Selection Element Matching 
Rule". What I don't want is yet another way of expressing the same thing 
and craft a special rule.

What's left is this case described by 12.3.4 that we don't really need 
to specify, because it just follows from the other definitions that one 
should match the content, which happens to be null.
I'm a bit confused now what the behavior was in WD10, I thought <X /> 
meant <X match="content" /> ?


>> 12.3.6 - line 2269 and everywhere else - I propose that we don't allow
>> the match attribute to be empty. It seems to be more a programming error
>> to me if the match attribute is empty. By allowing this possibility, we
>> are giving more ways to express the same meaning to XRD publishers and
>> that might hurt interoperability and/or makes XRD harder to understand.
>>     
>
> [=Drummond] We just got finished adding the following rule to the Input
> section (line 866, section 7.1 of ED06):
>
> 	1. The presence of an input parameter or an XRD element with an
> empty value is treated as equivalent to the absence of that input parameter
> or XRD element.
>
> Although that rule doesn't specifically mention attributes, right now we
> treat empty attributes uniformly throughout the spec: it is the same as if
> the attribute was absent altogether. That rule is simple and uniform so I
> don't think it hurts interoperatiblity at all.
>
> The alternative would be to make a special exception for this attribute and
> define a special error condition. Do you think that's worth it?
>   

I would be in favor of uniformly treating ALL attributes with null 
string as an error as would any illegal value / typo. The reason is that 
I view it more as an inadvertent error. Also, from an XML processor's 
perspective (e.g. DOM), testing the presence of an attribute is possibly 
a different operation from testing the value of the attribute.

The real question is, do we expect people to actually put in <X match="" />?
My view has always been that if we don't have to create special rules, 
let's not do it. It makes for a tighter spec.

In contrast, I feel that it is acceptable to allow empty values in HXRI 
because: a) the absence of an input parameter doesn't give it a default 
value, it is simply equivalent to null ("")
b) HXRI's are more likely to pass through various components like web 
forms, address bars, embedded in emails, etc. So, it needs to be more 
resilient to user error.


>> 12.3.6 - line 2272 - "if an XRI, IRI, or URI does not include a local
>> part, a trailing forward slash MUST be assumed" - that MUST NOT be
>> assumed because for certain URI schemes, there simply isn't a local
>> part. We should simply defer to the XRI and IRI syntax.
>>     
>
> [=Drummond] I clarified that by changing the wording as follows.
>
> 	1.	The values of the Service Type parameter and the
> xrd:XRD/xrd:Service/xrd:Type element SHOULD be normalized according to the
> requirements of their identifier scheme prior to input. In particular, if an
> XRI, IRI, or URI uses hierarchical syntax and does not include a local part
> (a path and/or query component) after the authority component, a trailing
> forward slash after the authority component MUST NOT be considered
> significant in comparisions. In all other cases, a trailing forward slash
> MUST be considered significant in comparisions.
>
> The reason I don't think we can just "defer to the XRI and XRI syntax" on
> this trailing-slash-after-authority-component issue is that neither of thos
> specs weigh in on the question of whether a trailing forward slash after the
> authority component is significant in comparison. The OpenID folks have
> spent hours and hours on that ambiguity. We'll do everyone a favor by being
> explicit in our spec that if the identifier uses hierarchical syntax, a
> trailing slash after the authority component is NOT significant in
> comparison -- and in all other cases it is signficant in comparison.
>   

I'm not sure what perplexed OpenID folks so much, my guess is that after 
Gabe straightened it out for them, it was put to rest. The problem of 
specifying something here is that RFC3986 actually allowed specific 
schemes to defined their own comparison rules. Perhaps we can add a 
clause like "unless overriden by specific URI scheme normalization or 
comparison rules."

So, with XRI, are we really normalizing an empty path to "/"?


>> 12.7.6 line 2497 - By applying URI construction during authority
>> resolution, we are allowing components of the QXRI other than the
>> authority to be used as inputs to authority resolution, which I'm
>> nervous about.
>>     
>
> [=Drummond] Ah, there's a different way to think about this: that you're NOT
> allowing "components of the QXRI other than the authority to be used as
> inputs to authority resolution", but only that you're allowing the SEP
> author to dynamically compose the URI for their authority resolution service
> endpoint. That's different than changing what actually gets resolved: that
> input is always just the remaining authority subsegments.
>
> I hope this makes you more comfortable.
>   

Say we have this URI in the $res*auth service:
<URI append="qxri">http://resolve.example.com/</URI>

While performing authority resolution for two different QXRI's:
1. @example*a/a
2. @example*a/bar

The constructed URI's for $res*auth are respectively:
1. http://resolve.example.com/@example*a/a/*a
2. http://resolve.example.com/@example*a/bar/*a

The fact that they are different URIs means that the authority 
resolution server at resolve.example.com *may* return different 
responses. If we don't trust it to send back the same response for each, 
we can't cache it using the @example*a key (nor the CID).

I guess I'm only comfortable with append="authority" for authority 
resolution. The auth res server has no business in any other component.

What do you think?


=wil