From: Kenneth Whistler (email@example.com)
Date: Tue Aug 03 2010 - 13:31:13 CDT
> In a discussion about a new protocol, there was some issue about how to
> replace illegal bytes in UTF-8 with U+FFFD. That let me remember that
> there was once a Public Review Issue about this, and that as a result, I
> added something to the Ruby (programming language) codebase. I traced
> this back to the method test_public_review_issue_121 added at
> What I now would like to know is what became of the UTC "tentative
> preference for option #2", and where this is documented,
Unicode 5.2, Chapter 3:
pp. 94 - 95, Subsection, "Constraints on Conversion Processes".
> and if
> possible, which other programming languages and libraries use or don't
> use this preference.
Somebody else needs to step up to the plate on that one.
> On a higher level, this also suggests that it would be very good to add
> a bit more of (meta)data to these review issues, such as date opened and
> date closed and resolution.
That information is carried on the resolved-pri-* pages. (Well, the
date opened has never been tracked, although it would in principle
be possible to recover most of them by digging back through the
action item documentation to pick up the close dates on the action
items to open the PRI's. But it seems a bit much to try to post all
of that information up, too.)
> After manipulating the URI a bit, I got to
> http://www.unicode.org/review/ and from there to
> http://www.unicode.org/review/resolved-pri-100.html, where I can find:
> Resolution: Closed 2008-08-29. The UTC decided to adopt option 2 of the PRI.
> This should be directly linked from
> http://www.unicode.org/review/pr-121.html (or just put that information
> on that page).
The background documents associated with
PRI's have never been updated with resolution information after
the fact. The permalink for the PRI should be to the PRI itself,
and not to the background document, since the resolution of the PRI
will be located there.
For this one, that would be:
but I agree that that isn't a very predictable URI, and it is
unfortunate that the scheme in place moves the location of
open PRI's when they are resolved. Perhaps that could be fixed.
Many of the resolved PRI's don't result in particular text in
a known permanent location, but a few of them do -- in which
case it might also be useful to provide a link at the point
of resolution to some subsequent text added, to make this
easier for inquiries of your type.
> Also, I'm still interested about where the result of this
> resolution is nailed down (a new version of the standard, with chapter
> and verse, or a TR or some such.
See above for the details.
This archive was generated by hypermail 2.1.5 : Tue Aug 03 2010 - 13:33:31 CDT