Re: opinions on tracker issues

I haven't seen any objections to these suggestions so let's make the 
changes and move along to the remaining issues!

Martin and Larry - can you update the document where recommended text 
has been suggested?

---
Chris Weber, IRI WG co-chair



On 8/30/2011 5:39 PM, Peter Saint-Andre wrote:
> 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 Thursday, 1 September 2011 22:14:50 UTC