On 8/29/14, 12:38 PM, John C Klensin wrote:
--On Friday, August 29, 2014 17:01 +0000 "Joe Hildebrand
(jhildebr)" <[email protected]> wrote:
...
I agree we want one set over time. But I thought that we had
agreed in Toronto that we were going to try to get Precis
right, then look at removing the tables from IDNA201x,
including Precis by reference in those documents.
Joe,
I did not come away from Toronto very sure about what had been
agreed. The Etherpad minutes
(http://etherpad.tools.ietf.org:9000/p/notes-ietf-90-precis?useMonospaceFont=true
to be sure I am looking at the right thing) don't help much and
I'm far more interested in Peter's interpretation as it will
show up in the next draft than I am in mine.
My interpretation is that sections 7.1-7.10 of the precis-framework
document will be changed to reference sections 2.1-2.10 of RFC 5982, not
copy text from RFC 5892.
This gives us one set of rules ("A" through "J" from RFC 5892, "K"
through "R" for PRECIS).
This does not give us one registry for such rules. My understanding of
the discussion in Toronto comports with Joe's: it would be good to
figure out a way to have one rulespace / tablespace, but that's not
something we can do immediately since it necessitates updates to
IDNA2008 (at least from the registration perspective).
My interpretation is also that we will remove the codepoint table from
the precis-framework document, since the algorithms govern how code
points are treated.
None of that really interacts with the intent of my note, which
was to stress the importance of moving swiftly to a single set
of rules and tables. That is an important distinction relative
to what you said above: at least in the context of what I
understood of the Toronto discussions, it didn't make much
difference whether the single set of rules and tables was the
IDNA ones, the PRECIS ones, or a new synthesis that both
referenced. What is important is that we have a fairly firm
commitment make the combination, not a "probably over time" or
"look at it in the future" situation. If we don't have a clear
plan and a sufficient commitment of resources that Pete (at
least) is convinced that the plan will be executed, then my
pre-Toronto concerns are unchanged and the compromises reached
there are meaningless.
As I see it, creating one rulespace and tablespace would require a new
synthesis that in PRECIS terms treats IDNA2008 as defining a base string
class ("NameClass"?) alongside the IdentifierClass and FreeformClass.
This is the modern equivalent of what we had under stringprep: NamePrep
for domain names and other classes for other kinds of strings.
That wasn't what caused my note. Again, I've been waiting for
Peter because I don't think it is worth commenting on what I
think might be in a draft that has not been posted. What did
prompt me to write it is that, in addition to the small bugs
Takahiro found, three things have happened (or gotten more on my
radar) since Toronto. I was planning to raise them, if still
relevant, only after Peter got the Framework spec posted, but
here goes:
(1) WHATEWG and W3C are charging ahead with an "Encoding"
specification that will apparently be normatively referenced
from HTML5. With luck, an update to/ replacement for the very
important "Charmod" spec will be right behind it. The
recommendations of those two documents are different from the
proposed PRECIS ones. One way of looking at those specs in the
PRECIS context is that they represent yet another profile and
that, if two or three (or more if IDNA is counted) are
acceptable, than one more doesn't make much difference. At the
other extreme, some people have taken the position about the W3C
Charmod and Encoding specs that the web, web browsers, web
applications, and web access to other protocols so dominates the
Internet that any conflicting specifications are irrelevant (or
various worse words). If the latter view is correct than the
PRECIS effort is, to a considerable degree, a waste of time and,
worse, a source of more confusion, at least for any protocol
that might be accessed via a URI or from a web page. My own
view is that reality lies somewhere between those positions, but
my ability to predict the near-term future is notoriously bad.
If the PRECIS effort is a waste of time, we might as well recognize our
sunk costs and scuttle the effort RIGHT NOW. I am sure that everyone on
this list has plenty of other things they could be doing.
Unfortunately, the alternative appears to be using stringprep + Unicode
3.2 forever, and doesn't seem viable.
Is there an alternative I'm missing? Use some emerging web-encoding
rules for everything on the Internet?
(2) There has been a heated discussion on the IDNA list. It
involves both rather small issues (the treatment of a single
code point that is now to Unicode 7.0 and perhaps a few code
points that are perceived as "like" it) and a very large one.
The latter involves two questions that might ultimately be the
same one: (1) Whether some of the fundamental assumptions that
were made in designing the rule structure for IDNA, assumptions
about code point assignment and Unicode evolution, were
incorrect and, if so, whether IDNA2008 itself is workable. (2)
Whether some fundamental assumptions made in IDNA about the
nature and implications about normalization, especially
normalization prior to comparison, are correct and, whether they
are correct or not, whether normalization as it actually works
is appropriate for contexts that involve short strings and no
language information or requirements to conform to the rules of
a single language. Those assumptions are fundamental enough to
the IDNA design and the parts of the PRECIS design that are
derived from the IDNA rule structure that, if there is a problem
with IDNA, there is probably (almost certainly) a problem with
PRECIS too.
Yes, PRECIS is downstream from IDNA in those ways.
(3) Independent of anything going on in the IETF, I've gotten
another reminder about something I mentioned briefly during the
meeting in Toronto. There is a sufficient cluster of
inter-organizational and political issues surrounding IDNA that
any attempt to open it and change its definitional method, even
if we assured people that the changes had no actual effect on
anything other than the definitional method, could cause some
very unpleasant reactions, some of which might be harmful to the
IETF. I'm just not sure that "eventually conform IDNA to
PRECIS" is really practical, especially since one of the
arguments that would certainly be made would compare the
in-depth review in multiple communities that IDNA2008 received
and its present deployment compared to those for PRECIS
documents.
Would updating the registries to have one rulespace & tablespace entail
modifications to the rules, or would it just be a matter of bookkeeping
by the IANA? (Likely something in between.)
Peter
john
But
But what??
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
