W3C home > Mailing lists > Public > public-iri@w3.org > August 2011

Re: opinions on tracker issues

From: Peter Saint-Andre <stpeter@stpeter.im>
Date: Tue, 30 Aug 2011 18:39:31 -0600
Message-ID: <4E5D82C3.2080702@stpeter.im>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
CC: Chris Weber <chris@lookout.net>, public-iri@w3.org
Hi Martin,

Sorry about that -- I wrote that email on the plane back from IETF 81
and I wasn't thinking too clearly. :)

Issue titles and URLs provided below, followed by my opinion (and in
some cases Martin's opinion).

On 8/12/11 9:11 AM, "Martin J. Dürst" wrote:
> Could we (ideally Peter) actually put the title of each issue, rather
> than just the number? Otherwise, it's really tough for anybody to follow
> it without Web access and constant flipping of applications (or a big
> screen).
> 
> Regards,    Martin.
> 
> On 2011/08/12 22:58, Chris Weber wrote:
>> I agree with each of your comments unless otherwise stated below.
>>
>> On 8/1/2011 1:31 PM, Peter Saint-Andre wrote:
>>> <hat type='individual'/>
>>>
>>> I had a chance to review the tracker issues on the trip back from IETF
>>> 81. Here are my opinions on most (but not all) of the open issues...
>>>

Title: "uniformly extended" seems incorrect
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/8
>>> #8 - Agreed on removing "uniformly".

Title: things are "defined by" documents; minor editorial
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/10
>>> #10 - Agreed on removing "defined by".

Title: dealing with "document character encoding"
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/11
>>> #11 - Belongs in the processing spec (a.k.a. "Reschke-Weber"),
>>> specifically in text about on the topic of pre-processing.

Title: valid URI reference
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/12
>>> #12 - Referencing RFC 3986 seems appropriate.

Title: move "comparison" into separate document?
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/15
>>> #15 - Belongs in the processing spec or equivalance spec.

Title: Adapt rules for bidi components to those in IDNAbis
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/25
>>> #25 - Belongs in the bidi spec.

Title: disallow combining characters at start of a component
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/26
>>> #26 - I think it's fine to say this is legal but a bad idea.

Title: do we need to say anything special about ZWNJ and ZWJ?
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/27
>>> #27 - Another instance of legal but a bad idea.
>>
>> Is it fair to say "...but a bad idea"? Isn't the use case valid for
>> ZWJ/ZWNJ in Arabic?
>>

Title: allow numbers at end of bidi components?
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/28
>>> #28 - Belongs in the bidi spec.

Title: Incomplete sentence in Section 3.7: "and in general there This
section gives"
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/34
>>> #34 - I have no idea what the missing text is. We could say:
>>>
>>> In some situations, for presentation and further processing,
>>> it is desirable to convert a URI into an equivalent IRI in
>>> which natural characters are represented directly rather
>>> than percent encoded. Of course, every URI is already an IRI
>>> in its own right without any conversion. However, this
>>> section gives one possible procedure for conversion.

Title: Some HTTP implementations send UTF8 path directly
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/36
>>> #36 - Belongs in the processing spec.

Title: Handling of backslash ("\")
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/38
>>> #38 - Belongs in the processing spec, on pre-processing.

Title: Warn about mistaken conversion for non-BMP characters
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/39
>>> #39 - Belongs in the processing spec, on pre-processing.

Title: Implementation advice on handling query strings
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/40
>>> #40 - Belongs in the processing spec, on pre-processing.

Title: How to with illegal and disallowed IRI characters
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/43
>>> #43 - I think we should say that systems accepting IRIs SHOULD NOT
>>> perform special handling of the printable characters in the
>>> US-ASCII range that are not allowed in URIs.
>>>
>>> (Maybe even MUST NOT.)
>>>
>>
>> This issue seems to be considering general percent-encoding of both
>> printable characters disallowed in URIs as well as non-printable.
>> Overall this seems like it could use more discussion. After all, it
>> seems common to me that the printable but disallowed US-ASCII can appear
>> unescaped in the query component at least, and are handled differently
>> in other components as well. For just a couple examples see:
>>
>> http://lists.w3.org/Archives/Public/public-iri/2011Jun/0071.html
>> http://www.lookout.net/2011/06/20/some-browsers-convert-pipe-to-colon-in-the-file-scheme/

Title: Reference Unicode TR 46, and if yes, how?
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/44
>>> #44 - Agreed on adding a non-normative reference to TR 46.
>>
>> Wouldn't section 3.4 "Mapping ireg-name" be the most appropriate place
>> to talk a little more about TR46 strategies? Also section 10 "Security
>> Considerations".

Title: Normative length limits on IRIs or components theroff
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/46
>>> #46 - We discussed this a bit in Quebec City. I'm of the opinion
>>> that any length limits on IRIs or components thereof belong
>>> in the specifications for application protocols that define
>>> new URI/IRI schemes.

Title: Practical length limits on IRIs or components thereoff
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/47
>>> #47 - I think it would be good to add some guidance to implementers
>>> regarding practical limits. IMHO this advice belongs in the
>>> processing specification

Title: Allow %-encoding to punycode conversion for ireg-name?
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/66
>>> #66 - Isn't the question of punycode conversion a matter for
>>> pre-processing of strings that will be fed to a DNS
>>> resolver? If we need to say something about it, it seems to
>>> belong in the processing spec.
>>
>> More testing seems appropriate, as browsers at least, don't totally
>> agree on what to do here. But in general I agree this could move to the
>> processing spec.

Title: Make conversion from '\' to '/' scheme-dependent
URL: http://trac.tools.ietf.org/wg/iri/trac/ticket/68
>>> #68 - This sounds like a post-processing guideline that belongs in
>>> the processing spec.

END
Received on Wednesday, 31 August 2011 00:40:01 GMT

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