Re: [Uri-review] draft-holsten-about-uri-scheme-02

["Martin J. Dürst" <[e-mail]>]

Hello everybody,

On 2009/09/24 3:19, Alfred � wrote:
> Hello again,
> eventually I found the time to follow up to the latest revision of
> your 'about' URI scheme draft, draft-holsten-about-uri-scheme-02,
> and to again compile a couple of comments.

> (3)  Section 4
>
> The text there is surprising, because you did not mention before
> the intent to define an IRI in this document.
>
> Is that complication really needed?
>
> The most important issue with such kind of I18N in identifiers
> IMO is the fact that *most* users are neither able to read and
> understand nor to type in the vast majority of Unicode characters;
> using a small common subset vastly improves international
> communication ability.
>
> Further, since 'about' URIs are intended for application-internal
> use, they should be considered as some kind of protocol element,
> thus not needing Internationalization considerations.

I think this is certainly a valid point. I also wouldn't expect too many 
non-ascii components in about: schemes. However, I think it's much 
easier to define internationalization clearly now than to clean up a 
potential mess later. Also, because it's essentially internal, it would 
be possible for e.g. a browser to use localized components with only a 
small overhead, so we shouldn't exclude this a-priori.


> |5.1.  about:blank
> |
> |  The "about:blank" URI is the only 'about' URI reserved by this
> |  specification.
>
>     Applications resolving this URI MUST return an empty resource, with
>     the media type "text/html" and the character encoding "UTF-8".
>
> Why the hell does an *empty* "text/html" need the encoding tag "UTF-8"?
> There's nothing to encode, and hence nothing to decode!
> Doing so might unnecessarily trigger an automatic conversion process
> with all of its overhead.  I suggest to recommend using the default
> encoding of the particular application instead.
>
> BTW: The proper term would be "encoded character set", or "charset",
>       for short, not "character encoding", isn't it?

I don't think the "trigger an automatic conversion process" is a big 
issue. Conversion of an empty document, if indeed needed for this case, 
should be very quick. Also please note that the document is created 
browser-internal, and therefore UTF-8 is way more natural these days 
than a legacy/local encoding, and may easily lead to less conversions, 
if any.

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[e-mail]