- From: Peter Saint-Andre <stpeter@stpeter.im>
- Date: Tue, 02 Aug 2011 16:06:51 -0600
- To: "public-iri@w3.org" <public-iri@w3.org>
Sorry, I should've mentioned that these are only issues related to 3987bis, not the other I-Ds under consideration... On 8/1/11 11:31 AM, 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. > > #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 Tuesday, 2 August 2011 22:07:19 UTC