Re: draft-duerst-iri-07.txt: 2 week mailing list last call

At 12:07 19/05/04 +0900, Martin Duerst wrote:
>Coming back to your original point, I have reworded
>
>    For comparison, such conversions MUST only be done on the fly,
>    while retaining the original IRI.
>
>to
>
>    In order to conserve the original IRIs, such conversions SHOULD
>    only be done on the fly, while retaining the IRIs.

Martin,

I think that's better, but I still think it is making normative statements 
about implementation technique, which was the point of my original 
comment.  (And I think the normative point you do want to make really 
should be a MUST!)

For example, I think this this might say what you want without dictating 
implementation:
[[
If the IRI is to be passed to another application, or used further in some 
other way, its original form MUST be preserved;  the conversion described 
here should be performed only for the purpose of local comparison.
]]

#g
--

At 12:07 19/05/04 +0900, Martin Duerst wrote:
>At 14:02 04/05/12 +0100, Graham Klyne wrote:
>
>>At 18:05 12/05/04 +0900, Martin Duerst wrote:
>>>Hello Graham,
>>>
>>>I have marked this as issue 5.2resolve-32.
>>>
>>>At 12:02 04/05/10 +0100, Graham Klyne wrote:
>>>
>>>>Section 5.2:
>>>>
>>>>The MUST in the second paragraph seems to be straying inappropriately 
>>>>into application design territory.
>>>
>>>Sorry, but I don't think so. If different applications resolve
>>>in different ways, that would be a very bad idea.
>>
>>I agree that would not be good.  I think the "MUST" in the first 
>>paragraph addresses this.  I was referring to the "MUST" in the second 
>>paragraph:
>>[[
>>For comparison, such conversions MUST only
>>be done on the fly, while retaining the original IRI.
>>]]
>
>Okay, sorry for the confusion. So we are looking at the following text:
>
>    If this kind of equivalence is to be tested, the percent-encoding of
>    both IRIs to be compared has to be aligned, for example by converting
>    both IRIs to URIs (see Section 3.1) and making sure that the case of
>    the hexadecimal characters in the percent-encode is always the same
>    (preferably upper case). For comparison, such conversions MUST only
>    be done on the fly, while retaining the original IRI.
>
>I have noticed that this again assumes that there are no escaping issues
>with URIs, which is not true. I have therefore changed it to:
>
>    If this kind of equivalence is to be tested, the percent-encoding of
>    both IRIs to be compared has to be aligned, for example by converting
>    both IRIs to URIs (see Section 3.1), *eliminating escape
>    differences in the resulting URIs,* and making sure that the case of
>    the hexadecimal characters in the percent-encode is always the same
>    (preferably upper case). For comparison, such conversions MUST only
>    be done on the fly, while retaining the original IRI.
>
>
>Coming back to your original point, I have reworded
>
>    For comparison, such conversions MUST only be done on the fly,
>    while retaining the original IRI.
>
>to
>
>    In order to conserve the original IRIs, such conversions SHOULD
>    only be done on the fly, while retaining the IRIs.
>
>The main goal here is to make clear to implementers that they shouldn't
>just convert everything to URIs and stay there, because then the whole
>point of IRIs would be lost. So to some extent, you may call this 
>"straying into application design territory", but to some extent, it's just a
>consequence of actually using IRIs. I have changed the MUST to a SHOULD,
>because I think that's more appropriate.
>
>Regards,     Martin.

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Wednesday, 19 May 2004 05:52:50 UTC