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

RE: 3987bis issues

From: Larry Masinter <masinter@adobe.com>
Date: Fri, 12 Aug 2011 07:23:00 -0700
To: Peter Saint-Andre <stpeter@stpeter.im>, "public-iri@w3.org" <public-iri@w3.org>
Message-ID: <C68CB012D9182D408CED7B884F441D4D05D41A7AC6@nambxv01a.corp.adobe.com>
I'm working through the simple edits/issues and adding discussion to the ones still open.  I  urge people to review issues in Tracker and put comments there... 

I went ahead and posted -06 with just a few minor changes, except for the split out of comparison & canonicalization.



> #8 - Agreed on removing "uniformly".

Fixed in -06

>> #10 - Agreed on removing "defined by".

Fixed in -06

>> #11 - Belongs in the processing spec (a.k.a. "Reschke-Weber"),
>>       specifically in text about on the topic of pre-processing.

No changes yet, see notes in http://trac.tools.ietf.org/wg/iri/trac/ticket/11#comment:1



>> #12 - Referencing RFC 3986 seems appropriate.

Previous edit just removed reference, which seems to work.

>> #15 - Belongs in the processing spec or equivalance spec.

Moving stuff into a separate document posted as draft-masinter-iri-comparison.

Have not yet processed these (intent is to either fix or to leave comments in tracker).

>> #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.
>>
>> #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.)
>>
>> #44 - Agreed on adding a non-normative reference to TR 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.
>>
>> #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.
>>
>> #68 - This sounds like a post-processing guideline that belongs in
>>       the processing spec.
>>
>> Peter
>>

Received on Friday, 12 August 2011 14:23:58 GMT

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