Subject: [precis] Fwd: Milestones changed for precis WG

From: "Marc Blanchet" <[email-masked]>
Date: Tue, 01 Mar 2016 17:23:21 -0500

hello,
  we were thinking of closing the working group since the main topics 
have been done and published as RFC. However, as some mailing list 
discussions require that some corrections to RFC 7564 and 7613 are 
needed, we added those two milestones to the charter. The intent is when 
those are done, we would close the working group.

Regards, Marc (co-chair hat)

Forwarded message:

> From: IETF Secretariat <[email-masked]>
> To: [email-masked], [email-masked]
> Subject: Milestones changed for precis WG
> Date: Tue, 01 Mar 2016 14:19:28 -0800
>
> Changed milestone "New version of RFC 7564", set state to active from
> review, accepting new milestone.
>
> Changed milestone "New version of  RFC 7613", set state to active from
> review, accepting new milestone.
>
> URL: https://datatracker.ietf.org/wg/precis/charter/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 1 Mar 2016 15:56:39 -0700

> those are done, we would close the working group.

Thanks, Marc. Here is my understanding of what needs to be done:

In RFC 7564:

1. Change §5.2.3 to mention Unicode toLower() as an alternative to 
Unicode Default Case Folding and describe the circumstances in which 
toLower() is appropriate.

2. Change the order of operations in §7 from MUST to SHOULD (we've 
already deviated from that slightly in RFC 7613 §3.2.1).

3. Clarify the meaning of 'preparation' (because it is different from 
what stringprep meant by the term).

In RFC 7613:

a. Revisit Unicode Default Case Folding here, too.

b. Modify the *presentation* (but not the content) of the rules for each 
profile, along the lines of what we did in RFC 7700 (i.e., describe the 
rules in one section and then use them in separate sections on 
preparation, enforcement, and comparison).

We'll also want to review and correct the errata that have been reported.

I can commit to doing this work.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Mar 2016 11:30:08 -0600

> I can commit to doing this work.

FYI, I plan to submit -00 versions of the bis documents when the 
submission window opens again on April 3.

Marc, would you like me to submit these as individual I-Ds or WG I-Ds? 
(They would be draft-[ietf|saintandre]-rfc[7564|7613|7700]-bis-00.)

Peter

---

From: "Marc Blanchet" <[email-masked]>
Date: Mon, 28 Mar 2016 15:28:32 -0400

> (They would be draft-[ietf|saintandre]-rfc[7564|7613|7700]-bis-00.)

I’m sure that the wg is likely to be ok with wg drafts, but let’s do 
the normal process. Please submit first as individual draft and we will 
call later for wg adoption.

Marc.

>
> Peter
>
>
> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis

---

From: John C Klensin <[email-masked]>
Date: Mon, 28 Mar 2016 15:50:35 -0400

--On Monday, March 28, 2016 15:28 -0400 Marc Blanchet
<[email-masked]> wrote:

>> Marc, would you like me to submit these as individual I-Ds or
>> WG I-Ds?  (They would be
>> draft-[ietf|saintandre]-rfc[7564|7613|7700]-bis-00.)
> 
> I'm sure that the wg is likely to be ok with wg drafts, but
> let's do the normal process. Please submit first as
> individual draft and we will call later for wg adoption.

Marc,

For whatever my opinion as a participant is worth, that would be
meaningless, time-wasting, ritual for its own sake.   These are
the descendants of WG documents, responding to issues that came
up during or immediately after LC.  The issues should have been
detected earlier (a failing by the WG).  At least some of those
issues arguably should have stopped the relevant documents
pre-publication except that there seemed to be general feeling
that is was better to get the documents out and then revisit the
issues with revisions.  Based on your announcement, the WG has
been kept open precisely to deal with that set of issues.
Remembering that Peter is the author or co-author of the key
drafts being revised, unless you have reason to believe that new
drafts that he might create would be so far out of line that the
WG couldn't use them as a starting point for discussion, the
only things that going through individual drafts and then
calling for WG adoption accomplish are to create extra ritual,
extra confusion, and more delay in getting to substance.

If there really is concern that these documents should be
published first as individual drafts, wouldn't it be reasonable
to see if you could get formal and substantive consensus (and a
collection of committed volunteers and participants) for
continuing with the WG?  As far as I know, that question has not
been formally asked of the participants.  Given the extent,
depth, and number of participants in the review of some of the
documents -- to say nothing of whatever caused the issues that
are now the topic of revisions-- it seems to me that a
determination of whether you actually have critical mass to
continue on a WG basis is a far more important next step than
creating a ritual about WG adoption of a set of follow-on and
correction documents.

     john

---

From: Christian Schudt <[email-masked]>
Date: Mon, 28 Mar 2016 21:58:04 +0200

Hi,

let me raise one concern, which I had while implementing RFC 7564 and 7613. I’ve raised it already on this mailing list, but it got no attention.

Instead of changing RFC 7564 §7 from MUST to SHOULD, why not changing RFC 7613 §3.2.2 (and likely other Enforcement sections) to stick to the order of rules?

For me as an implementer it simply felt more clean and straightforward, e.g. when I faced this issue:

It’s still unclear what to do with U+212B (ANGSTROM SIGN) in Usernames.

If I stick to the rules in RFC 7613 § 3.2.2, it would be disallowed (HasCompat == true, => preparation *before* other rules fails).
If I stick to the rules in RFC 7564 § 7, it would be allowed (NFC converts it to U+00C5 => preparation *after* other rules succeeds).

The workaround for half and fullwidth characters in RFC 7613 §3.2.1 suggests, that the authors *want* a workaround for HasCompat characters, but they only specified it for a few characters, which somehow feels like they overlooked it.
=> It would be nice if the authors could give their thoughts on it!

If all profiles simply sticked to the rules in §7, no workarounds are needed.

+1 for the clarification of the meaning of „preparation“. It suggests that a string, which passes the preparation step is valid. But in fact a rule could still fail during enforcement (e.g. Bidi rule).

Thanks for your attention,
Christian

> Am 28.03.2016 um 21:28 schrieb Marc Blanchet <[email-masked]>:
> 
> 	• Change §5.2.3 to mention Unicode toLower() as an alternative to
> 	• Change the order of operations in §7 from MUST to SHOULD (we've
> 	• Clarify the meaning of 'preparation' (because it is different from
> b. Modify the presentation (but not the content) of the rules for each
> FYI, I plan to submit -00 versions of the bis documents when the submission window opens again on April 3.
> 
> Marc, would you like me to submit these as individual I-Ds or WG I-Ds? (They would be draft-[ietf|saintandre]-rfc[7564|7613|7700]-bis-00.)
> 
> I’m sure that the wg is likely to be ok with wg drafts, but let’s do the normal process. Please submit first as individual draft and we will call later for wg adoption.
> 
> Marc.
> 
> Peter
> 
> precis mailing list
> [email-masked]

---

From: "Marc Blanchet" <[email-masked]>
Date: Mon, 28 Mar 2016 16:01:47 -0400

On 28 Mar 2016, at 15:50, John C Klensin wrote:

> meaningless, time-wasting, ritual for its own sake.

disagree. the step from individual to wg is the normal process and has 
no impact on technical work: the technical work can continue whatever 
the filename is. Let’s spend time on technical discussions on the 
content of the to-be-published draft.

Marc.

> These are

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Mar 2016 14:56:50 -0600

On 3/28/16 2:01 PM, Marc Blanchet wrote:
>     [email-masked] <mailto:[email-masked]> wrote:
>

I have no preference, but to be clear the -00 versions will be exactly 
what is in the published RFCs so that we can more easily track changes.

Peter