Subject: [precis] Barry Leiba's Discuss on draft-ietf-precis-framework-16: (with DISCUSS)

From: "Barry Leiba" <[email-masked]>
Date: Wed, 23 Apr 2014 15:42:27 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-precis-framework-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-precis-framework/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I will move to a strong "yes" on this, once we have some discussion of
the registry defined in Section 9.1.

The registry created in Section 9.1 is very odd indeed.  I guess IANA is
expected to assume that the format of the registry will look like the
non-normative table in the appendix, but Section 9.1 doesn't say what the
format of the registry will be.  In general, I see that IANA has asked
several questions in its review, and those questions haven't been
responded to (and, unusually, the IANA review is in the IESG mailing list
archive but *not* in the document history in the datatracker).  They
should be given a response.

But the real oddity here is that the specification of the registry
involves an *enormous* startup cost for the designated expert, *and*
requires that the DE be appointed and start her work immediately. 
Normally, IANA takes the required actions as soon as the document's
approval is announced, but in this case they will have to wait for the DE
to be appointed and to derive the entire content of the registry.

It seems to me that the right way to have handled this would have been
for the working group to have engaged the appropriate experts and made
the table Appendix A *be* the initial contents of the registry, rather
than explicitly denouncing Appendix A and leaving it as a seemingly quite
onerous startup task that will delay the IANA actions indefinitely.

Why was it done this way, and what is the plan to get the registry
content specified in a reasonable time?  Should approval of the document
wait for that content to be specified?  Or are we really expecting to
approve the document with the content of the registry left open?

---

From: Pete Resnick <[email-masked]>
Date: Wed, 23 Apr 2014 18:47:54 -0500

I do expect the authors to follow up with the IANA questions, but on the 
main point:

I refer you to RFC 5892, section 5.1 and Appendix B:

https://tools.ietf.org/html/rfc5892#section-5.1
https://tools.ietf.org/html/rfc5892#appendix-B

As well as the IANA registry referred to in that document:

http://www.iana.org/assignments/idna-tables-6.0.0/idna-tables-6.0.0.xhtml#idna-tables-6.0.0-properties

This is pretty much identical to what IDNA did. I agree that we should 
probably recruit the expert (and I hope we can recruit the same expert 
as the one for IDNA Derived Properties), but I don't think the task will 
be tremendously burdensome, even though it sounds that way. The point of 
"don't just copy Appendix A" is to account for the possibility that the 
Unicode properties might be moving targets. But for the most part, it's 
an act of checking that the properties are "as expected".

I will contact Patrik and see if he's willing.

pr

On 4/23/14 5:42 PM, Barry Leiba wrote:
> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis
>    

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 23 Apr 2014 18:26:51 -0600

On 4/23/14, 5:47 PM, Pete Resnick wrote:
> I do expect the authors to follow up with the IANA questions,

Will do this evening.

> but on the

Yes. And we had some discussion about that on the WG list:

http://www.ietf.org/mail-archive/web/precis/current/msg00605.html

http://www.ietf.org/mail-archive/web/precis/current/msg00606.html

Peter

---

From: Barry Leiba <[email-masked]>
Date: Thu, 24 Apr 2014 10:19:16 -0400

> I refer you to RFC 5892, section 5.1 and Appendix B:

It might not surprise you, but I don't very much care that IDNAbis did
it the wrong way also.

> probably recruit the expert (and I hope we can recruit the same expert as
> the one for IDNA Derived Properties), but I don't think the task will be
> tremendously burdensome, even though it sounds that way. The point of "don't
> just copy Appendix A" is to account for the possibility that the Unicode
> properties might be moving targets. But for the most part, it's an act of
> checking that the properties are "as expected".
>

It's good to hear that it won't be burdensome, but it still seems that
the working group produced an incomplete document.  The right way to
have handled this would have been to involve the appropriate experts
near the end of the working group's process, and to get the table in
Appendix A to be the initial registration data, already vetted by the
expert.  That way, the instructions to IANA would be clear, and the
IETF and the IESG would be reviewing the complete picture.  When the
document is approved and IANA creates the registry, they will contact
the authors to confirm that it's all correct, at which point the
authors would ask the expert to check it again.  It's unlikely that
there'd be any changes needed in the roughly four weeks between IETF
last call and document approval, and given that the expert you intend
to recruit is also our liaison to the Unicode Consortium, he could
confirm that they are not working on any updates just now.

As it stands, what the working group seems to be saying is that they
don't have the expertise to get this right, and can't get the right
experts involved... which, in any other context, we would push back on
very hard, indeed.

All that said, we've now had the discussion and Pete has this in hand,
so even though I think it was done badly (which is beating up Pete as
much as it is the working group), it's time for me to move this to a
non-blocking comment.  If this sort of thing comes up again, *please*
do not do it this way.  Get the experts involved earlier, and present
the community with a finished document.

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Apr 2014 08:39:53 -0600

> confirm that they are not working on any updates just now.

That all sounds beautiful. I'm sorry we didn't do it that way.

> experts involved... which, in any other context, we would push back on

IMHO the WG has worked hard to get things right - we've had two separate 
implementations comparing their output, etc. But as we know i18n is 
difficult, and perhaps only John Klensin has the expertise to get this 
right anyway. :-) That's partly why in general we based PRECIS on the 
same technical approach taken in IDNA.

> the community with a finished document.

I, for one, intend to never work on an internationalization framework 
again...

Peter

---

From: Barry Leiba <[email-masked]>
Date: Thu, 24 Apr 2014 10:46:37 -0400

> I, for one, intend to never work on an internationalization framework

He-he-he........

[And so, unfortunately, does I18N burn out experts at an alarming rate.]

b

---

From: Pete Resnick <[email-masked]>
Date: Thu, 24 Apr 2014 10:17:39 -0500

On 4/24/14 9:19 AM, Barry Leiba wrote:
> the working group produced an incomplete document.

Sort of. The problem is that it really isn't the IETF's expertise or 
responsibility to create that sort of document. In fact what would be 
ideal is to point to a document or registry controlled by the Unicode 
Consortium. But the conclusion of the community during IDNA was that we 
would not be provided such a stable reference. Given that, IDNA did a 
de-reference; we'd create an IANA registry, run by a Unicode expert, but 
that tracked the state of the properties that we needed for our 
purposes. Not pretty or ideal, but practical. This WG followed that 
lead, I think equally pragmatically.

As you say, water under the bridge. I got email back and Patrik has 
agreed to be the expert; I'll add a management item during agenda bash. 
He'll prepare the contents of the registry and we should be good to go.

pr

---

From: John C Klensin <[email-masked]>
Date: Thu, 24 Apr 2014 12:01:31 -0400

--On Thursday, April 24, 2014 08:39 -0600 Peter Saint-Andre
<[email-masked]> wrote:

> IMHO the WG has worked hard to get things right - we've had
> two separate implementations comparing their output, etc. But
> as we know i18n is difficult, and perhaps only John Klensin
> has the expertise to get this right anyway. :-) That's partly
> why in general we based PRECIS on the same technical approach
> taken in IDNA.

I know only three things:

(1) How little I actually know, an assessment that gets worse
with each passing week and problem.

(2) How badly some approaches can lead us astray and into
problems, including the Law of Least Astonishment one and its
relationship to profiles in this area.

(3) Following up Peter's comment, how dangerously close to
burning out I get at regular intervals, sometimes unfortunately
resulting in tuning out as a self-preservation measure.  The
latter got me several times during PRECIS discussions, in large
measure because the whole approach that could lead to "one
application, one profile" struck me as so profoundly wrong.  I
couldn't get the WG to address that issue and investing energy
in fine-tuning documents that reflected that approach just
didn't seem productive.

    john

p.s. The W3C i18n WG has had an action item on its agenda since
late (Northern Hemisphere) summer to note the differences
between the evolving PRECIS approach and that of the Charmod
revision, differences in string matching, and some normalization
concerns.  From the viewpoint of my "too many profiles"
concerns, Charmod is yet another profile approach as is UAX31
("Unicode Identifier and Pattern Syntax").  I did mention on
their call today that the action item is probably OBE but, if
anyone wants to pursue those differences, the contact points are
   Addison Phillips <[email-masked]>  and
   Richard Ishida <[email-masked]>