Re: How widely deployed are "non-strict parsers" in RFC 3986

FWIW Martin,

When me and my dinosaur mates get together for Mark-Up reunions we remember a time when
XML parsers came in validating and non-validating variants.  These variants caused a huge amount of syntactical mischief because they implied two or more sets of "House Rules" for what was ostensibly the same game.  The "two or more" criterion is highly significant because DTD's classify character entity behavior as Null or One or more.  That is why IBM Salesmen have traditionally traveled in packs :)

"Non-strict" and "Strict" parsers both can be very intolerant of documents which do not follow "House Rules".  There is a way around the politics - Roman Phone Books - and I will tell you about that if you are interested.

--Gannon
--------------------------------------------
On Mon, 9/26/16, Martin J.  Dürst <duerst@it.aoyama.ac.jp> wrote:

 Subject: How widely deployed are "non-strict parsers" in RFC 3986
 To: "'Roy T. Fielding'" <fielding@gbiv.com>, "uri@w3.org" <uri@w3.org>, "urn@ietf.org" <urn@ietf.org>
 Date: Monday, September 26, 2016, 2:50 AM
 
 This question came up on the URN
 mailing list, but is essentially an URI 
 question, so I'm copying the URI list and the co-author of
 the URI spec 
 that I think will know the answer.
 
 RFC 3986, in section 5.2.2 
 (https://tools.ietf.org/html/rfc3986#section-5.2.2),
 mentions the following:
 
        -- A non-strict parser may
 ignore a scheme in the reference
        -- if it is identical to the
 base URI's scheme.
        --
        if ((not strict) and
 (R.scheme == Base.scheme)) then
           undefine(R.scheme);
        endif;
 
 The term "non-strict" isn't found in any other place in RFC
 3986. The 
 question is how widely deployed such "non-strict" parsers
 are. E.g. are 
 these things that still existed in 2005 when RFC 3986 was
 published, but 
 are now essentially extinct, or e.g. did and do all browsers
 behave that 
 way.
 
 Many thanks for an enlightening answer.
 
 Regards,   Martin.

Received on Monday, 26 September 2016 21:57:02 UTC