Re: Proposed resolution of HRRI/IRI discussion

Martin Duerst schrieb:
> At 07:58 07/11/06, Richard Tobin wrote:
>>>> And require normative changes to all the specs, which is what we
>>>> want to avoid.
>>> Why would allowing what was allowed by the Grammar in RFC 2732 require
>>> to change all the specs?
>> Because they don't allow them now.  All the specs exclude square
>> brackets from the list of characters %-encoded by the processor,
>> either by explicitly saying so, or by not listing them.
>>
>> If LEIRIs said that square brackets in the fragment get %-escaped
>> by the processor, and we changed the specs to refer to LEIRIs, that
>> would be a normative change.

That depends on the perspective ... (RFC 2732 Grammar vs. Prose)

And if you give precedence to the formal grammar change this is not a 
normative change because there has been a change form the RFC2732 
grammar to the RFC 3986 grammar again dissallowing the re-allowed square 
brackets in the fragment.

So, also not to include square brackets can be seen as a normative 
change depending on wheter you give precedence to the the grammar or the 
prose of RFC2732.

My feeling was that it is less drastic for people to escape (or accept) 
square brackets in the fragment than to dissallow existing "street" 
xpointers.

So please reconsider this, althogh you can see from my original posting 
(Martin, you intended to repost this here but I haven seen it yet) that 
I do respect both positions.

Konrad

> P.S.: Please note that on strict reading, the href attribute in XLink
> does not allow '[' and ']' for IPv6, because it only cites RFC 2732
> for explaining 

http://www.w3.org/TR/2001/REC-xlink-20010627/#N1022
 > XLink processing depends on [XML], [XML Names], [XML Base], and [IETF 
 > RFC 2396] (as updated by [IETF RFC 2732]).

Also http://www.w3.org/TR/xlink/#N3954

> why '[' and ']' are excluded, not when defining the
> correct target syntax after escaping. This has been fixed in XML V4
> by referencing RFC 3986.

Received on Tuesday, 6 November 2007 07:51:55 UTC