Subject: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep

From: John C Klensin <[email-masked]>
Date: Sun, 15 Jul 2012 11:49:30 -0400

Hi.

Just checking that what this document says is what everyone
wants...

Section 3.2 of draft-ietf-eai-rfc5721bis-05 is very heavily
dependent on SASLprep [RFC4013], including MUST requirements.
SASLPrep is, in turn, dependent on Stringprep, which is tied to
Unicode 3.2.   Questions:

(1) Could someone who is closer to SASLPrep and the PRECIS work
tell us whether they are comfortable with this or whether the
text in this spec should be modified somewhat?  If any changes
are likely to be completely compatible, I don't think there is a
problem.  However,...

(2) If changes are needed, should Section 3.2 be rewritten to
explicitly allow conformance with the successors of 4013 as an
alternative?  I think that would require only a few changes of
wording.

(3) Or are we better off just leaving this alone and monitoring
any 4013bis efforts to make sure they contain provisions to
explicitly update our spec when the time comes?

These are just questions --if the WG is ok with things as they
are, so am I.  But I can see this causing questions during IETF
Last Call and want to be sure we have considered the issue.

    john

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 16 Jul 2012 17:59:58 +0100

> Hi.
Hi John,

> alternative?  I think that would require only a few changes of
But that would require pointing to a document with unclear date of 
completion...
> Last Call and want to be sure we have considered the issue.

I think (3) is the best way forward, but just my 2 pence.

---

From: John C Klensin <[email-masked]>
Date: Mon, 16 Jul 2012 13:09:48 -0400

--On Monday, July 16, 2012 17:59 +0100 Alexey Melnikov
<[email-masked]> wrote:

Alexey, thanks. 
>...

> But that would require pointing to a document with unclear
> date of completion...

Nope.  It would require saying something like "MUST conform to
4013 or one of its standards-track successors".  That doesn't
promise that there will be such successors much less when they
will be done.  And it ties the MUST to any version, not the
particular version represented by 4013.  I am _not_ suggesting
that is the best thing to do, only that it wouldn't be hard if
we decided to do it.

>> (3) Or are we better off just leaving this alone and
>> monitoring any 4013bis efforts to make sure they contain
>> provisions to explicitly update our spec when the time comes?
>> 
>> are, so am I.  But I can see this causing questions during
>> IETF Last Call and want to be sure we have considered the
>> issue.
> 

Wfm.  I just need some signs of consensus, rough or otherwise.

    john

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 16 Jul 2012 19:22:49 +0200

I think the substance of the requirements is fine.

> explicitly update our spec when the time comes?

I'm sure some pedant will scan for 4013 references if/when 4013 is 
updated, so let's just leverage that pedantry for our comfort.

Arnt
(occasional pedant)

---

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 17 Jul 2012 07:51:03 +0800

----- Original Message ----- 
From: "Arnt Gulbrandsen" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 17, 2012 1:22 AM
Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and 
Stringprep

> updated, so let's just leverage that pedantry for our comfort.

I think that  adding the sentence similar to  "MUST conform to
4013 or one of its standards-track successors" is to help readers to look 
for the new version of rfc 4013, instead of depending on pedant tools only.
Since the new version of  rfc 4013 is very likely to come, I add the  " one 
of its standards-track successors" to the new version.

I think that it is a very small change.

Jiankang Yao

> Arnt
> (occasional pedant)
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima
>

---

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 17 Jul 2012 08:08:31 +0800

----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Cc: "EAI WG" <[email-masked]>
Sent: Tuesday, July 17, 2012 1:09 AM
Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and 
Stringprep

> that is the best thing to do, only that it wouldn't be hard if

I think that your suggestion saying something like "MUST conform to
4013 or one of its standards-track successors"  is something between choice 
2 and 3.
Since the time to submission cut off is coming, I have submitted the new 
version.
If the WG has the consensus on it, we can update it or keep it.

Jiankang Yao

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Jul 2012 08:35:51 -0400

--On Tuesday, July 17, 2012 08:08 +0800 Jiankang Yao
<[email-masked]> wrote:

>...
>...
>>>> (2) If changes are needed, should Section 3.2 be rewritten
>>>> to explicitly allow conformance with the successors of 4013
>>>> as an alternative?  I think that would require only a few
>>>> changes of wording.
>> 
> 4013 or one of its standards-track successors"  is something
> between choice 2 and 3.
> Since the time to submission cut off is coming, I have
> submitted the new version.

Thanks.  What do others think?

   john

---

From: Joseph Yee <[email-masked]>
Date: Tue, 17 Jul 2012 09:42:45 -0400

Personal thought.

If we picked (2) with "... or one of its standards-track successors",
then I have some concern whether the following paragraph (the 4th in
section 3.2, about how to apply SASLprep on different arguments) may
trip or confuse readers.  I may simply worry too much [I hope].

If we picked (3), are we meant to write another bis when RFC4013 being
updated/obsoleted?

That say, I prefer (2), and would like to ask others if leaving the
4th paragraph unchanged ok.

Joseph

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Jul 2012 10:03:51 -0400

--On Tuesday, July 17, 2012 09:42 -0400 Joseph Yee
<[email-masked]> wrote:

> Personal thought.
> 
> If we picked (2) with "... or one of its standards-track
> successors", then I have some concern whether the following
> paragraph (the 4th in section 3.2, about how to apply SASLprep
> on different arguments) may trip or confuse readers.  I may
> simply worry too much [I hope].

See the notes I am about to post.  Already noted that.
Sometimes Jiankang reacts a bit too quickly and doesn't bother
to think about context, but this isn't the first time.

> If we picked (3), are we meant to write another bis when
> RFC4013 being updated/obsoleted?

I'd hope that 4013bis would explicitly update this document.

> That say, I prefer (2), and would like to ask others if
> leaving the 4th paragraph unchanged ok.

Wait for my notes to appear on the list.

   john

---

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 17 Jul 2012 22:24:41 +0800

----- Original Message ----- 
From: "Joseph Yee" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Cc: "Jiankang Yao" <[email-masked]>; "Alexey Melnikov" 
<[email-masked]>; "EAI WG" <[email-masked]>
Sent: Tuesday, July 17, 2012 9:42 PM
Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and 
Stringprep

> trip or confuse readers. >

I do not think that it will cause confusion.

The fourth paragraph of section said "When applying SASLprep [RFC4013], 
servers MUST reject UTF-8 user
   names or passwords that contain a Unicode character listed in Section
   2.3 of SASLprep [RFC4013]. "

That paragraph is for RFC4013- SASLprep ,  not for  its standards-track 
successors since the reference to SASLprep is rfc4013 not  its 
standards-track successors .
So it will not cause confusion.

Before adding the words "one of its standards-track successors", I actually 
consider the fourth paragraph.
My personal judgement is that it is ok to add it without causing the 
confusion.

Jiankang Yao

> I may simply worry too much [I hope].

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Jul 2012 10:35:25 -0400

Jiankang,

My apologies.

If you considered the fourth paragraph carefully before making
the changes, I think the changes are reasonable.  My personal
preference, although not a strong one, is that we try to
future-proof these documents -- and raise the odds as much as
possible that an update to SASLPrep will explicitly update this
and other documents as needed.

I had assumed that you had not considered those issues (similar
things did occur with some changes in prior versions) and
erroneously assumed that you had not done so here.  Again, I
apologize for jumping to that conclusion and for any comments I
made as a result.

I take the point make by others that either the authors of such
a SASLprep revision or various people reviewing that spec will
spot this.  But there are a _lot_ of interconnections.  I'd
really prefer to avoid having to reopen this spec when a
revision to SASLprep occurs -- the difficulty getting reviews
and comments while this WG is active predicts that it might be
even more difficult if/when revisions are needed after the WG
has concluded its work.

    john

--On Tuesday, July 17, 2012 22:24 +0800 Jiankang Yao
<[email-masked]> wrote:

>> paragraph (the 4th in section 3.2, about how to apply
>> SASLprep on different arguments) may trip or confuse readers.
>> >
> 
> The fourth paragraph of section said "When applying SASLprep
> [RFC4013], servers MUST reject UTF-8 user
> That paragraph is for RFC4013- SASLprep ,  not for  its
> standards-track successors since the reference to SASLprep is
> rfc4013 not  its standards-track successors .

---

From: [email-masked]
Date: Tue, 17 Jul 2012 20:17:01 -0700 (PDT)

> Thanks.  What do others think?

Well, if you want my honest and frank opinion, I think this stuff qualifies as
"Mostly Harmless". I view the chances of people implementing Xprep in protocol
Y, for pretty much any value of X or Y, as fairly low, and the chances of
implementations keeping this sort of thing up to date as about as likely as my
winning the lottery.

That said, I don't see any downside either. If what we say doesn't matter, it
doesn't matter what we say.

				Ned

P.S. I've never purchased a lottery ticket.