Subject: [newprep] WG Review: Stringprep after IDNA2008 WG (newprep)

From: IESG Secretary <[email-masked]>
Date: Tue, 11 May 2010 10:30:02 -0700 (PDT)

A new IETF working group has been proposed in the Applications Area.  The
IESG has not made any determination as yet. The following draft charter
was submitted, and is provided for informational purposes only. Please
send your comments to the IESG mailing list ([email-masked]) 
by Tuesday, May 18, 2010.                                            

Stringprep after IDNA2008 WG (newprep)
--------------------------------------------------
Current Status: Proposed Working Group

Last modified: 2010-04-23

Chair(s):
  TBD

Applications Area Director(s):
  Alexey Melnikov <[email-masked]>
  Peter Saint-Andre <[email-masked]>

Applications Area Advisor:
  Peter Saint-Andre <[email-masked]>

Mailing Lists:
  General Discussion: [email-masked]
  To subscribe: https://www.ietf.org/mailman/listinfo/newprep
  Archive:
http://www.ietf.org/mail-archive/web/newprep/current/maillist.html

Description of Working Group:

Problem Statement

The use of non-ASCII strings in Internet protocols requires additional
processing to be handled properly. As part of the Internationalized
Domain Names (idn) work in 2003, a method for preparation and comparison
of internationalized strings was defined and generalized to be re-used
by other protocols. This "stringprep" method [RFC 3454] defines the
overall framework whereas specific protocols define their own profiles.
Known existing IETF profiles are:

- The Nameprep profile [RFC 3490] for use in Internationalized Domain
Names in Applications (IDNA)

- The iSCSI profile [RFC 3722] for use in Internet Small Computer
Systems Interface (iSCSI) Names

- The Nodeprep and Resourceprep profiles [RFC 3920] for use in the
Extensible Messaging and Presence Protocol (XMPP)

- The Policy MIB profile [RFC 4011] for use in the Simple Network
Management Protocol (SNMP)

- The SASLprep profile [RFC 4013] for use in the Simple Authentication
and Security Layer (SASL)

- The trace profile [RFC 4505] for use with the SASL ANONYMOUS mechanism

- The LDAP profile (RFC 4518] for use with LDAP

The IAB completed a review of IDN and made recommendations for change
[RFC 4690], which triggered a new version of the IDNA protocol called
IDNA2008. Whereas IDNA2003 was tied to Unicode 3.2 via stringprep,
IDNA2008 does not use the stringprep method, but instead uses an
algorithm based on the properties of Unicode characters, which makes it
agile to the Unicode database version. The protocols using stringprep
need Unicode version agility and therefore need to investigate how to
move from the current stringprep approach, with the associated
challenges of backward compatibility and migration.

Objectives

The goal of this group is to assess whether a new method based on the
IDNA2008 algorithmic approach is the appropriate path forward for
existing stringprep protocols as well as for other application protocols
requiring internationalized strings.

The group will evaluate if a new generalized framework based on the
algorithmic approach is appropriate and, if so, define it.

The group will analyze existing stringprep profiles and will do one of
the following with regard to each profile:

1. Develop a replacement for the profile in close collaboration with
the related protocol working group.

2. Collaborate with another active working group which will be
developing the new profile as part of its charter.

3. Advise the authors of profiles for which there is no active working
group how to proceed.

The group will also define a set of best current practices for
preparation and comparison of internationalized strings.

Because the framework, profile replacements, and guidelines are very
much interrelated, work on them will proceed in parallel as much as
possible.

In completing its tasks, the working group should collaborate with other
teams involved in internationalized identifiers, such as the IETF's IRI
and EAI working groups as well as other relevant standards development
organizations (e.g., the Unicode Consortium).

Deliverables

1. Problem statement / analysis of existing stringprep profiles
(Informational).

2. Possible new framework to replace stringprep (Standards Track).

3. Possible replacements for the existing IETF stringprep profiles as
listed earlier in this charter (Standards Track).

4. String preparation and comparison guidelines (BCP).

Milestones

Aug 2010 - Accept problem statement document as a WG item
Nov 2010 - Accept framework document as a WG item
Nov 2010 - Accept new profile documents as WG items
Dec 2010 - Start Working Group Last Call on problem statement document
Jan 2011 - Submit problem statement document to the IESG
Jan 2011 - Accept guidelines document as a WG item
May 2011 - Start Working Group Last Call on framework document
May 2011 - Start Working Group Last Call on new profile documents
Jun 2011 - Submit framework document to the IESG
Jun 2011 - Submit new profile documents to the IESG
Jun 2011 - Start Working Group Last Call on guidelines document
Aug 2011 - Submit guidelines document to the IESG

---

From: JFC Morfin <[email-masked]>
Date: Wed, 12 May 2010 01:33:50 +0200

>by Tuesday, May 18, 2010.

As I have explained, and been opposed for that, many times, it was 
necessary for IDNA that an independent domain name character set 
(DNCS)  eventually be worked out. It was to be adequately formed in 
using ISO 10646 code points, to permit easy interoperability. The 
process used to prepare a UCS string into a DNCS string, could be 
named a "domainization".

My reading of the concerned parts of IDNA2008 is that it has achieved 
a first big step towards that end, what permitted my consensual 
support. IDNA2008 is related but independent from Unicode. A 
difficulty remains however: the support of Latin language majuscules 
and other orthotypographical issues (i.e. not the way machines but 
people's languages use characters)  because the Unicode format does 
not support metadata.

Yet, I only consider such a DNCS in-parts as a super-set of a 
"multilingual registry regular character set" ("regcode") prepared in 
the same manner, but also with anti-phishing considerations, so that 
the resulting charset can serve as a secure man/machine 
multiorthotypographic universal charset (passports, security cards, 
operating system commands, databases, ISO 11179 registries, etc. and 
metadata). So, this regcode can be the Internet presentation layer 
character set.

This is why a secure "regcode" encoding table should eventually be 
produced that could be based upon Unicode + lingual context, and be 
attached to ISO 3166, in using my ccTAGs 
(http://tools.ietf.org/id/draft-mltf-jfcm-cctags-01.txt) for a unique 
secure international sorting and indexing order that could be used in 
"internatioperable" applications. (ccTAGs are my proposition of a 
stable, standard rooted, of tagging legal orthotypographies that can 
be used by networked machines, when langtags correspond to subjective 
linguist classification).

Such a regcode will permit to address the international and Internet 
protocols' needs through a standard "regularization" process, and to 
free Unicode from every network operations constraints.

This issue is going to be a part of my IAB level appeal, because 
IDNA2008 is (per its charter and by its results) a severance of the 
Internet from Unicode. The responses to the questions legitimately 
raised by the proposed charter do in fact belong to the IAB guidance 
that I claim IESG should have requested before approving IDNA2008 - 
or quoted in a disclaimer indicating that IDNA2008 is the network 
side of multilingualization, not the whole of it.

As you know, some consider that the other part belongs to the UI 
(User Interface, cf. "resman" draft 
<http://www.ietf.org/internet-drafts/draft-resman-idna2008-mappings-01.txt>http://www.ietf.org/internet-drafts/draft-resman-idna2008-mappings-01.txt). 
I personally think that it also belongs to the architectural IUI 
(Internet Usage Interface) introduced by IDNA2008 if one are also to 
respect the constraints investigated by the IAB in its Domain 
Internationalization draft 
<http://tools.ietf.org/html/draft-iab-idn-encoding-01>http://tools.ietf.org/html/draft-iab-idn-encoding-01 
(i.e. the question raised by the AD at the end of the IETF/LC and 
left open by the "Mapping" Document). This is why these two document 
are important. As important as tedious but comprehensive enough 
(<http://www.ietf.org/iesg/appeal/morfin-2010-03-10.pdf>http://www.ietf.org/iesg/appeal/morfin-2010-03-10.pdf) 
compilation of my IESG level appeal for those wanting to get the 
details and grasp the context of the problem at sole IDN level.

This is why, through UI or IUI, the work this Charter considers is 
necessary to complete a more comprehensive review. This can only help 
the [email-masked] work on the IDNA2008 user side, and the 
IDNA2012 work on their common adminance [technological 
administration, maintenance, planning].

However, I would suggest not engaging in it, before the IAB has 
published its position on the matter in response to my appeal (family 
obligations as you delay me quite a lot).

Your response to my appeal shows that you accept that the issues I 
raise are worth an I_D and a BoF (or several ones since there are 
several major (IMHO) concerns which should be consistently investigated).

However, until IAB has commented your answer, I do not really know in 
which area (if any) such IUI related issues (including the issues 
concerned by this charter) should be discussed.

Please remember that IAB has initiated a Draft on IDNs that, at least 
for the time being, seems to contradict the very IDNA2003 
architectural principle of IDN in Applications and lead to consider 
an "IDNApplication" that would certainly impact your evaluation 
process because it would permit more flexibility on the user side. 
Actually, my own ML-DNS proposition would be much more flexible but 
at the same time much more defined in terms of "stringprep" equivalent.

Basically, one cannot have _several_ software modules in different 
convergent computer technologies that may convert and resolve 
strings, semantic addresses, domain names differently.

So, I fully support the beginning of the Charter: to evaluate the 
need. However, I do not think the need is "applications" - but use 
and users oriented, so the charter should be very open (like a 
rechartering once the evaluation is completed?) to best locate and 
charter the next step.

I was opposed by Yao Jiankang that "NewPrep" does not want to focus 
on IDN, but internationalized string, there is a difference.

I think I explained that I am not interested in domain names per se, 
but in coherence in the way international strings are handled.

More importantly, I feel that the first thing to be done is to 
consider if the intended works is to be a set of Charset patches, or 
to fit in the Internet architecture which is now based upon RFC 1958, 
RFC 3439 and IDNA2008.

I am only interested in the later. This is why I disagree with the 
ambiguous "internationalized string" wording. Because we should not 
necessarily replicate alternative solutions (RFC 1958) and because we 
also should strive for the simplest one (RFC 3439). If we want this 
work to be of use, we need to discuss universal services character sets.

The target is to support a multilingual universal networked system, 
where IETF so far has tried to diversely internationalize functions 
of an ASCII network system. Today, based upon experience we reached 
the point where the IDNA2008 character set seems a good enough 
working basis for such a multilingual universal network system 
character set. This is why for clarity sake I call it "regcode" 
(regular code) and its use in replacement of another system (i.e. a 
general StringPrep function) "regularization".

I can already list as constraints:

-          "user readyness",
-           interoperability with ASCII and ISO 10646 code points,
-          usability by IDNApplications (users side) and IDNA (network side),
-          as being much phishing proof as possible,
-          orthotypographically acceptable (no semantic value having 
to be bent/lost due to regcode constraints)
-          to be unambiguously multilingually/scripturally sortable 
throughout all the world digital ecosystem (for example in being able 
to be used with my ccTAG proposition).
-          I also add as a major constraint: its universal usability 
by IUI slots, what implies a common adminance of this regcode.

In a nutshell we need a world digital ecosystem equivalent to ASCII 
(when UCS is a complete CS for typographers).

As I explained, at this stage I am questioning the IETF through a 
possible three steps process (appeal to IESG and IAB, possibly ISOC 
further to experimental operations) in order to know

-  (1) in which kind of Internet architectural understanding should 
we now operate
-  (2) who should lead its adminance [technological administration, 
maintenance, planning] (because precisely we do not focus on IDN, and 
even not on network issues) and on which grounds.

This leads to a very simple question here:

-          should we adapt a code to existing functions,
-          or adapt protocols and functions to a code - and then which code?

As far as I am concerned I know we need an IUI system wide character 
set encoding, and I need all the listed functions to be 
interoperational through the IUI (i.e. on the Internet side and the 
convergence with other technologies, standards, and users sides).

jfc

---

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.

---

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

---

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: 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: 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".

> adding ...

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.

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. 

	- 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?

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: Alexey Melnikov <[email-masked]>
Date: Wed, 19 May 2010 17:24:39 +0100

Hi Mark,

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

>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 c…
Right. This would be my preferred approach as well.
I don't think the proposed charter prevents the approach you suggest.

---

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.

---

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.

---

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