Subject: Re: [precis] review of codepoint table in draft-ietf-precis-framework-17

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 01 Sep 2014 20:53:13 +0900

On 2014/08/30 03:38, John C Klensin wrote:

> (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.

I might be wrong, but I see no connection between the "Encoding" spec 
and PRECIS. "Encoding" is about codepoints (Unicode scalar values,...) 
<=> bytes, and that's below PRECIS.

I also don't think that an update of the "Charmod" spec will be "right 
behind it". Actually, there are several parts to the "Charmod" spec, in 
different stages:

Charmod Fundamentals (http://www.w3.org/TR/charmod/) is a Rec since 2005 
and some parts of it are somewhat outdated (if one believes the 
"Encoding" spec, then e.g. http://www.w3.org/TR/charmod/#C020 would be 
outdated), but starting an update would be a major undertaking and there 
sure would be much better ways to spend I18N resources.

Charmod Normalization (http://www.w3.org/TR/charmod-norm/, nowadays the 
subtitle is "String Matching and Searching") is in active but rather 
slow development, at Working Draft stage. It is probably the one most 
related to PRECIS. The differences are that A) it deals with both 
identifiers and content, whereas PRECIS deals with identifiers (or what 
they are called) only; and B) it (in one way or another over the 
timespan of way more than 10 years) only recommends NFC, whereas PRECIS 
provides further restrictions. Whether this part of Charmod will proceed 
"right behind" "Encoding" or not depends on the meaning of "right 
behind", but the above differences A and B have been around since these 
issues were first introduced into IDNA and Charmod drafts, so taking 
that as News of any kind would be very surprising.

There isn't any fundamental conflict between IDNA/PRECIS and Charmod 
Normalization. Discussions about the specific versions of IDNA apart, 
browsers and other infrastructure in perfectly capable to use IDNA 
checks or conversions on the domain part of an URI/IRI/URL even if 
putting the rest of an URI/IRI/URL and the rest of a document is just 
recommended to be in NFC. Things would be different if Charmod 
Normalization suddenly started to recommend or require NFD or some such.

Charmod Resource Identifiers (http://www.w3.org/TR/charmod-resid/) 
formally is in Candidate Recommendation since 2004, and that shows how 
little attention it got over the years, although the use of non-Unicode 
characters in Web addresses (use whatever acronym you want) is certainly 
a reality at least in some important contexts (such as HTML, XML, and RDF).

Regards,   Martin.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Sep 2014 07:00:51 -0600

On 8/30/14, 12:41 AM, Patrik Fältström wrote:
>
> On 29 aug 2014, at 23:03, John C Klensin <[email-masked]> wrote:
>
>>> 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).
>>
>> That definitely works for me.
>
> Sounds good, I think. Let me just check...do you imply that the referenced rule B from 5892 is in PRECIS still called B? Not that L in PRECIS is B in 5892?
>
> I think we should call the same rule the same letter in both standards, if you know what I mean. I think that is what you say, right?

That has been the intent all along, but again if people think we haven't 
actualized that intent then let us know!

Peter

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 2 Sep 2014 16:27:23 +0000

On 9/2/14, 1:00 PM, "Peter Saint-Andre" <[email-masked]> wrote:

>> Sounds good, I think. Let me just check...do you imply that the 
>>referenced rule B from 5892 is in PRECIS still called B? Not that L in 
>>PRECIS is B in 5892?
>>
>> I think we should call the same rule the same letter in both standards, 
>>if you know what I mean. I think that is what you say, right?
>

I'm fine with this approach as well.  I was going to suggest moving the 
start of the PRECIS block to "P", but I don't think it's worth the hassle.

-- 
Joe Hildebrand

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Sep 2014 10:30:15 -0600

> start of the PRECIS block to "P", but I don't think it's worth the hassle.

Yeah but do we have a i26 problem when we run out of letters from the 
Latin alphabet? ;-)

Peter

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 2 Sep 2014 16:31:32 +0000

>Yeah but do we have a i26 problem when we run out of letters from the 

Heh.  No.  The rule names don't go in protocol slots.

-- 
Joe Hildebrand