<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
--
Peter Saint-Andre
https://stpeter.im/