Subject: Re: [Ietf-krb-wg] WG Review: Stringprep after IDNA2008 WG (newprep)

From: Sam Hartman <[email-masked]>
Date: Tue, 18 May 2010 13:15:18 -0400

Hi.
I think there are two items that should be considered with the scope of
this working grou.

The first is RFC 4282.  RFC 4282 section 2.4 discusses
internationalization strategies based on stringprep and IDNA2003.  It
does not define its own profile.  Apparently, in addition to all the
reasons you would probably want to update anything based on IDNA 2003,
RFC 4282 does not meet the needs of the implementor community.  One
proposal for addressing RFC 4282 is draft-dekok-radext-nai-01.txt I
think any proposal in this space will require both help from newprep and
from the radext/aaa community.  Based on my past experience in emu, the
aaa community, like the rest of the IETF, can use i18n help.

Secondly, I'd like to see Kerberos considered as newprep thinks about
saslprep.  Kerberos's formal internationalization is confused and spotty
as a specification level.  At the last time that there was active work
on this within krb-wg, the plan was to use saslprep; a prior stringprep
profile was explicitly dropped in favor of saslprep.  For this reason, I
think that considering and working with the Kerberos community would be
really useful.

I'm not sure if either of these needs an explicit charter change; I
suspect the first probably does and the second may not.  However I think
these both are well within the spirit of the proposed charter.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 May 2010 14:27:14 -0400

>>>>> "Marc" == Marc Blanchet <[email-masked]> writes:

    Marc> we had a discussion about the same subject: i.e. should we
    Marc> restrict the scope to a specific set of documents to
    Marc> review/update/... or do we keep some provision for other
    Marc> documents coming in the stream that require "help" of the
    Marc> newprep. I was arguing for the latter. To me, what you are
    Marc> talking about is the latter. Obviously, some people wanted the
    Marc> charter to be restrictive in order to not go all over the
    Marc> place, and I agree in principle... However, this work is kinda
    Marc> horizontal: touches many areas, so having a more large view of
    Marc> the problem space and documents that depends on this newprep
    Marc> work would be very valuable to the working group
    Marc> work. Therefore, I'm more for opening a bit the charter for
    Marc> the cases like the ones you are talking about.

I'm happy with a restrictive charter so long as the work areas
identified today (including mine) are included.  I'm happy drawing a
line in the sand and saying "here's what we'll touch first," so long as
people who bring up items now get included.  I'd probably be happier
with a reasonably open charter.

I'm not at all happy if the items I bring up or other similar items
brought up now are excluded.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 18 May 2010 13:59:27 -0400

we had a discussion about the same subject: i.e. should we restrict the 
scope to a specific set of documents to review/update/... or do we keep 
some provision for other documents coming in the stream that require 
"help" of the newprep. I was arguing for the latter. To me, what you are 
talking about is the latter. Obviously, some people wanted the charter 
to be restrictive in order to not go all over the place, and I agree in 
principle... However, this work is kinda horizontal: touches many areas, 
so having a more large view of the problem space and documents that 
depends on this newprep work would be very valuable to the working group 
work. Therefore, I'm more for opening a bit the charter for the cases 
like the ones you are talking about.

Marc.

Le 10-05-18 13:15, Sam Hartman a écrit :
> newprep mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/newprep

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 18 May 2010 14:32:16 -0400

Le 10-05-18 14:27, Sam Hartman a écrit :
>>>>>> "Marc" == Marc Blanchet<[email-masked]>  writes:
>
> identified today (including mine) are included.

my guess is that we most likely will discover other issues/newprep 
potential "customers" as we go, that it might be useful to work on, 
since they have a lot of similarities with the others official in the 
charter. therefore, more "opened" than closed charter.

Marc.

> I'm happy drawing a

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 May 2010 07:40:56 -0600

On 5/18/10 12:32 PM, Marc Blanchet wrote:
> charter. 

Agreed.

> therefore, more "opened" than closed charter.

We're trying to balance two things here: (1) we want to get as much
input as possible from current and potential customers of stringprep or
newprep/stringprepbis/whatever, but (2) we want to scope the WG tightly
enough that it doesn't have a mandate to work on "anything related to
internationalized strings".

>> brought up now are excluded.

In an email exchange with Marc and Alexey Melnikov last week, I proposed
adding the following paragraph to the charter:

   Although the group may provide advice regarding other technologies,
   it will prioritize work on the above-listed stringprep profiles and
   will take on additional tasks as official milestones only after
   rechartering.

We might want to broaden that a bit further to explicitly mention
seeking feedback from customers other than the existing stringprep profiles:

   Although the group will seek input from and may provide advice to
   "customers" working on other technologies, it will prioritize work
   on the above-listed stringprep profiles and will take on additional
   tasks as official milestones only after rechartering.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Sam Hartman <[email-masked]>
Date: Wed, 19 May 2010 12:36:20 -0400

I believe that without explicitly listing the use cases I've brought up
in the body of the charter, the additional paragraph would be a
significant step backward.  I would object to chartering the group with
that paragraph added without explicitly listing any use cases including
the onse I brought up that have come forward in this discussion.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 19 May 2010 09:42:46 -0400

> internationalized strings".

agreed.

>     tasks as official milestones only after rechartering.

fine by me.

Marc.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 May 2010 17:24:39 +0100

Hi Mark,

Mark Lentczner wrote:

>On May 19, 2010, at 6:40 AM, Peter Saint-Andre wrote:
>  
>
 [...]

>>adding ...
>Wait: That seems like a step back from the original charter. That seems to exclude any work on a "stringprepbis"
>
IMHO, Stringprepbis is already covered by one of the milestones.

>or other generally useful draft. If so, I'm left a bit in the cold.
>  
>
No, the charter is just saying that if additional work is to be taken, 
then the WG need to rechartered. This is mostly to keep the WG focused 
on the main tasks. But rechartertering is not difficult, if the WG 
decides that it is really needed.

>It seems to me that while the WG should examine the particulars of the stringprep profiles under concern one by one - that wouldn't be the way we'd want to update them. Instead we'd want to either come up with a way to bring stringprep as a concept forward, or replace it with something similar, so that all the profiles under examination would have a consistent treatment in "updating". (Though I admit the likelihood of exceptions.) I don't think this kind of approach should be out of scope from the get go. 
>  
>
Right. This would be my preferred approach as well.
I don't think the proposed charter prevents the approach you suggest.

>	- Mark
>
>P.S.: I've simply replied all, but should this discussion be just newprep only, or do all those other lists want/need to be in on it?
>  
>

---

From: Mark Lentczner <[email-masked]>
Date: Wed, 19 May 2010 08:11:16 -0700

> internationalized strings".

I read this, and the proposed charter as meeting my needs: I'm not working with a current stringprep profile, but want to define something like a stringprep profile. I now don't want to use stringprep as is, but it's framework approach is what I need. I'm willing to put effort into such work.

I also whole-heartedly agree that we don't want this working group to be "anything related to non-ASCII strings".

>   tasks as official milestones only after rechartering.

Wait: That seems like a step back from the original charter. That seems to exclude any work on a "stringprepbis" or other generally useful draft. If so, I'm left a bit in the cold.

	- Mark

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden
[email-masked]

---

From: Alan DeKok <[email-masked]>
Date: Wed, 19 May 2010 17:26:30 +0200

> aaa community, like the rest of the IETF, can use i18n help.

  The intent of 4282 was to standardize the usage of "realms" (i.e. most
commonly DNS domain names) within AAA protocols.  Other goals were
general i18n issues, and not creating another registry.

  The result contained a lot of i18n text, which IMHO doesn't really
belong.  The AAA and EAP supplicant implementors seem to have agreed, as
they've uniformly ignored the i18n suggestions in 4282.

  The needs of the AAA community (IMHO) are reflected in updated
document.  The authors of 4282 generally agree with the attitude of that
document.

  What this means for stringprep is simple: the needs of the AAA
community can likely be addressed by serving the needs of DNS, and
general user data entry.  The AAA community will probably leverage that
work to carry i18n strings "verbatim" in their protocols.

  i.e. AAA proxies have *no business* doing anything with names they
carry, other than comparing them for byte-by-byte equality or
inequality.  The proxy is an intermediary, and knows nothing about the
end user or the home authentication system.

  Alan DeKok.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 25 May 2010 23:04:03 -0400

> the onse I brought up that have come forward in this discussion.

As always, text is welcome. :)

I proposed:

Seemingly you would prefer:

   Based on normal working group processes for achieving consensus, the
   group will attempt to gather input from, and may provide advice to,
   "customers" working on other IETF technologies, including but not
   limited to Network Address Identifiers (RFC 4282) and Kerberos (RFC
   4120).  However, the group will prioritize work on the previously
   listed stringprep profiles above work on other technologies, and
   will formally accept additional tasks as official milestones only
   after rechartering.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Sam Hartman <[email-masked]>
Date: Thu, 27 May 2010 12:07:28 -0400

>>>>> "Peter" == Peter Saint-Andre <[email-masked]> writes:

    Peter> On 5/19/10 12:36 PM, Sam Hartman wrote:
    >> I believe that without explicitly listing the use cases I've
    >> brought up in the body of the charter, the additional paragraph
    Peter> I proposed:

    Peter>    Although the group will seek input from and may provide
    Peter> advice to "customers" working on other technologies, it will
    Peter> prioritize work on the above-listed stringprep profiles and
    Peter> will take on additional tasks as official milestones only
    Peter> after rechartering.

I am actually fine with this if you note in the above text that Kerberos
needs to be considered when considering SASLPREP and explicitly add RFC
4282.

What I'm objecting to is prioritizing the list of stringprep profiles
you've identified to other stringprep profiles that came up during the
discussion of the charter.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Jiankang YAO" <[email-masked]>
Date: Fri, 28 May 2010 10:00:25 +0800

----- Original Message ----- 
From: "Sam Hartman" <[email-masked]>
To: "Peter Saint-Andre" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Marc Blanchet" <[email-masked]>; <[email-masked]>; <[email-masked]>; "Sam Hartman" <[email-masked]>; <[email-masked]>
Sent: Friday, May 28, 2010 12:07 AM
Subject: Re: [newprep] WG Review: Stringprep after IDNA2008 WG (newprep)

> needs to be considered when considering SASLPREP and explicitly add RFC

+1

> discussion of the charter.

If there are many things we must do, we(WGs) normally prioritize the things.
sometimes, the easier one first; sometimes, the difficult one first.

If peter's list is not ok for you, could you kindly give us your list?

thanks.

Jiankang Yao

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