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

["Drummond Reed" <drummond.reed@cordance.net>]

Wil, more great analysis. See ***[=Drummond] inline. I assigned each
non-closed issue an ED06 issue # for tomorrow's telecon. See the telecon
agenda coming out next. The others I marked [CLOSED] (though I still have
action items to incorporate them in the spec).

> -----Original Message-----
> From: Tan, William [mailto:William.Tan@neustar.biz]
> Sent: Wednesday, October 24, 2007 11:33 AM
> To: Drummond Reed
> Cc: 'XRI TC'
> Subject: Re: [xri] Feedback on section 12 of WD11-ED06
> 
> 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.


***[=Drummond] Agreed. I like your new wording. I'll add it. [CLOSED]



> >> 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.


***[=Drummond] Will do. [CLOSED]


> >> 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. lternatively, 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" /> ?


***[=Drummond] I see your point. The only problem might be that lots of XRDs
have empty elements in the wild today, and like you, I'm not sure what the
interpretation is -- I don't think it was the same as match="null".

I'm assigning this ED06 issue #4 for tomorrow's call.



> >> 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.


***[=Drummond] You make a pretty persuasive case. I'm marking this as ED06
issue #5 for tomorrow's call.


> >> 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."


***[=Drummond] Agreed. I'll make that change. [CLOSED]

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

***[=Drummond] It's too late for me to go check the XRI Syntax 2.0 spec now,
and I'm not even sure we did specify anything about that. But we'll have a
chance to get it right in 3.0. What do you recommend we do?


> >> 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?


***[=Drummond] The reason I'm comfortable with it is that the rules are very
clear: the same XRI sent to the same *logical* authority (as represented by
the same ProviderID) MUST return the same XRD. So if that authority chooses
to use the append attribute with a value of append="qxri" in their authority
resolution service endpoint URI, then that authority better be running an
authority server that knows to ignore the parts of the QXRI that would cause
it to give different responses. That's not rocket science.

However you HAVE convinced me that we need to add a warning to this effect
in the spec at a minimum.

I'm marking this as ED06 issue #6 for tomorrow's call.

Talk to you in the morning.

=Drummond