W3C home > Mailing lists > Public > public-iri@w3.org > May 2004

Re: Editorial suggestions for draft-duerst-iri-07 [issue editorial-Lilley-27]

From: Martin Duerst <duerst@w3.org>
Date: Tue, 11 May 2004 21:59:51 +0900
Message-Id: <4.2.0.58.J.20040511202215.0284c030@localhost>
To: Chris Lilley <chris@w3.org>, public-iri@w3.org

At 03:08 04/05/11 +0200, Chris Lilley wrote:

>Hello public-iri,

Hello Chris,

Many thanks for your comments. Because they are all editorial,
I have kept them as a single issue.
[http://www.w3.org/International/iri-edit/#editorial-Lilley-27]
Up to now, I haven't usually 'issuefied' editorial stuff, but I'm
starting to do that to document what has happened in last call.


>These editorial comments relate to
>http://www.w3.org/International/iri-edit/draft-duerst-iri-07.txt
>
> From the new appendix A
>
> >  New schemes are not needed to distinguish URIs from true IRIs (i.e.
>    IRIs that contain non-ASCII characters). The benefit of being able to
>    detect the origin of percent-encodings is marginal, also because
>    UTF-8 can be detected with very high reliably. Deploying new schemes
>    is extremely hard. Not needing new schemes for IRIs makes deployment
>    of IRIs vastly easier. Making conversion scheme-dependent is highly
>    unadvisable. Using an uniform convention for conversion from IRIs to
>    URIs makes IRI implementation orthogonal from the introduction of
>    acual new schemes.
>
>I suggest some slight wording and spelling changes (editorial)
>
>   New schemes are not needed to distinguish URIs from true IRIs (i.e.
>   IRIs that contain non-ASCII characters). The benefit of being able
>   to detect the origin of percent-encodings is marginal, because UTF-8
>   can be detected with very high reliability. Deploying new schemes is
>   extremely hard, so not requiring new schemes for IRIs makes
>   deployment of IRIs vastly easier. Making conversion scheme-dependent
>   is highly inadvisable, and would be encouraged by such an approach.
>   Using an uniform convention for conversion from IRIs to URIs makes
>   IRI implementation orthogonal to the introduction of actual new
>   schemes.

Changed. I replaced "by such an approach" with "by separate schemes
for IRIs" to make things even clearer.


>It might also be added that the TAG recommends not adding new schemes
>that are almost exactly like HTTP; i:http: or httpi: would have
>exactly that problem.

Do you have a reference? I'd like to give the underlying argument
rather than just saying 'the TAG said'.


> >  UTF-8 avoids a double layering and overloading of the use of the "+"
>    character. UTF-8 is fully compatible with US-ASCII, and has
>    therefore been recommended by the IETF, and is being used widely,
>    while UTF-7 has never been used much and is now clearly being
>    discouraged.
>
>I suggest a small change
>
>    Using UTF-8 avoids a double layering and overloading of the use of
>    the "+" character. UTF-8 is fully compatible with US-ASCII, and has
>    therefore been recommended by the IETF, and is being used widely,
>    while UTF-7 has never been used much and is now clearly being
>    discouraged.
>
>You might also mention here that using UTF-8 here is existing practice

Do you mean in the context of URIs, or much more general?
The subsection starts out with "At an early stage, UTF-7 was considered",
and in that context, it wouldn't be true. The fact that many URI
schemes now use UTF-8 in one way or another is largely due to the decision
to use UTF-8 for IRIs, and to the general rise of UTF-8.


>and that requiring implementations to convert to the rarely used UTF-7
>is an additional implementation burden.

That's a good point. I added:
"Requiring implementations to convert from UTF-8
to UTF-7 and back would be an additional implementation burden."


>The arguments against using %u and against inline encoding
>declarations are well made.

Thanks!


>In 3.1  Mapping of IRIs to URIs, the renumbering of the sub steps in
>step two is clearer than in the previous draft.

Thanks. That was a private suggestion from Chris Haynes.


>Should non-realworld, non-resolving sample URIs such as
>http://big.site/PopularPage.html not be, for example,
>http://big.example/PopularPage.html ?

In that case probably http://big.example.com/PopularPage.html.
Done. [I made that example.com, even though all other examples
are example.org, but I guess in that case, that's justified.]


Regards,   Martin.

>--
>  Chris Lilley                    mailto:chris@w3.org
>  Chair, W3C SVG Working Group
>  Member, W3C Technical Architecture Group
Received on Tuesday, 11 May 2004 23:50:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 April 2012 19:51:53 GMT