Re: opinions on tracker issues

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...
>>
>> #8 - Agreed on removing "uniformly".
>>
>> #10 - Agreed on removing "defined by".
>>
>> #11 - Belongs in the processing spec (a.k.a. "Reschke-Weber"),
>> specifically in text about on the topic of pre-processing.
>>
>> #12 - Referencing RFC 3986 seems appropriate.
>>
>> #15 - Belongs in the processing spec or equivalance spec.
>>
>> #25 - Belongs in the bidi spec.
>>
>> #26 - I think it's fine to say this is legal but a bad idea.
>>
>> #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?
>
>>
>> #28 - Belongs in the bidi spec.
>>
>> #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.
>>
>> #36 - Belongs in the processing spec.
>>
>> #38 - Belongs in the processing spec, on pre-processing.
>>
>> #39 - Belongs in the processing spec, on pre-processing.
>>
>> #40 - Belongs in the processing spec, on pre-processing.
>>
>> #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/
>
>
>
>> #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".
>
>>
>> #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.
>>
>> #47 - I think it would be good to add some guidance to implementers
>> regarding practical limits. IMHO this advice belongs in the
>> processing specification
>>
>> #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.
>
>>
>> #68 - This sounds like a post-processing guideline that belongs in
>> the processing spec.
>>
>> Peter
>>
>
>

Received on Friday, 12 August 2011 15:12:39 UTC