Re: opinions on tracker issues

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 13:58:46 UTC