Re: some questions about RFC3986

Anne van Kesteren wrote:
> On Thu, 02 Nov 2006 22:54:53 +0100, Mike Brown <> wrote:
> >> I'm trying to understand how section 4.4 of
> >> applies to XMLHttpRequest. Specifically, I'm having trouble with the
> >> following things:
> >>
> >> * What does the "should" entail (no conformance critera, RFC2119, etc.);
> >> * Definition of classes of products;
> >> * "retrieval action" seems undefined.
> >
> > RFC 3986 / STD 66 is just saying that there is a class of URI refs that
> > are considered "same-document" refs, and applications that make use of
> > representations of documents containing such refs should take that into
> > consideration.
> Thanks for your reply, but I don't see how this answers my questions.

Well, you're looking for answers where there are none. The standard says what
it says. It doesn't address XMLHttpRequest specifically, but doesn't need to;
there's nothing special about it.

Like many IETF standards-track documents, STD 66 canonifies a number of
existing, sensible approaches to / implementations of its topic -- general,
syntactic URI construction and processing -- and it attempts to resolve
conflicts and ambiguities without invalidating the use of anything that
"works". You might be under the impression that such resolution involves
establishing strict parameters for conformance, and it does, but it focuses on 
the syntactic level, by design. Dereference mechanisms are out of scope;
it's not meant to govern All Things URI.

However, I'd wager that if it'd be leaving the reader hanging if it brought up
the topic of same-document references without explaining *that* (if not *why*)
it might sometimes be important to acknowledge them. So, it says that
acknowledging same-document references in this way is an option, and that URI
processors that would benefit from it "should" do so, although I think we'd
agree that it could've said this a little more plainly. It intentionally does
not go down the road of saying there's One Way to handle them, rather it
merely says a dereferencer would be remiss if it didn't consider the possible
ramifications of failing to recognize a reference as pointing to the same

Re: "should", a quick Google search for 2119 rfc2396bis (rfc2396bis was the
name of STD 66/RFC 3986 when it was in development) reveals that the use of
"should" was chosen over "recommended", but tying the "should" to RFC 2119 was
deliberately avoided:

> > [...] You should not expect that a new representation (a new, separate  
> > byte string) would be sought to fulfill that dereference, though it  
> > wouldn't be breaking any rules to do so.
> So you're saying the should requirement on user agents can be safely  
> ignored (by user agents)? I suppose it can, given that there's no RFC2119  
> reference... It would solve the problem at least.

I would assume that it's not a requirement if it's a "should", regardless
of whether there's an RFC 2119 reference.

> > What are you encountering in the behavior of XHR that's causing you  
> > concern?
> Well, imagine a same-document reference request from the XMLHttpRequest  
> object. Would you get back some cached document, the current DOM or a new  
> instance of the document freshly loaded from the server?

Yes. :) Any of the above are possibilities. But...

A same-document reference is a URI *reference* occurring *in the same
document* that it refers to. 

XHR's API is such that it processes URIs (specifically, HTTP URLs) in
isolation. It does not analyze documents or dereference URI references within
a document. So, I would never expect an XHR object to recognize a URI as being
a same-document reference. However, it doesn't follow that I would necessarily
get a 'freshly loaded' copy... any use of HTTP is going to incur a risk of
getting cached representations.

If you're looking at a document and you've decided it's got a same-document
reference in it, and you have a need to dereference it (e.g., follow a "#foo"
link), then what the standard is saying is that you should make use of what
you've already got, rather than asking the XHR object or anything else to get
you the referenced document.

Received on Tuesday, 7 November 2006 16:58:14 UTC