Subject: [precis] draft-blanchet-precis-framework-00

From: Marc Blanchet <[email-masked]>
Date: Tue, 06 Jul 2010 10:16:34 -0400

Hello,
  I just submitted one approach to precis framework. The idea here is 
that usage of i18n strings in protocols would most likely be grouped 
into a few classes of strings. Therefore, the idea is to define these 
classes, and then define a variation of the IDNA2008 algorithm to 
support these classes. Currently, as a strawman, I've (loosely) defined:
-  RI:restricted identifier(typical i18n usernames) and
- LRI less-restrictive identifiers).  The IDNA2008 is augmented by 
having PVALID, RI_PVALID, LRI_PVALID.

This document is incomplete and incorrect but would like to see if the 
overall approach would make sense before digging into specific string 
classes.

Marc.

=========
Filename:	 draft-blanchet-precis-framework
Revision:	 00
Title:		 Precis Framework: Handling Internationalized Strings in Protocols
Creation_date:	 2010-07-05
WG ID:		 Independent Submission
Number_of_pages: 20

Abstract:
Using Unicode codepoints in protocol strings requires preparation of
the string.  This document describes the Precis Protocol Framework
that prepares various classes of strings used in protocol elements.
A protocol specification chooses a class of strings and then
implements the corresponding preparation steps described in this
document.  This document is based on the IDNAbis approach.  It
obsoletes the Stringprep algorithm.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 06 Jul 2010 17:18:26 +0200

Hi!  I quickly browsed this document looking for how it deals with
currently defined StringPrep profiles, but I could not find much?  I'm
not sure that is within the scope of this document either, and in that
case it seems confusing that the document claims to obsolete 3454?

/Simon

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 06 Jul 2010 13:32:34 -0400

> case it seems confusing that the document claims to obsolete 3454?

well,
0) you are right. no current provision for current profiles.
1) very first cut. as written, draft is incomplete.
2) before going into "transition from stringprep profiles to the new 
solution", I guess I would prefer having some concensus on what is the 
new solution. One can argue that part of the new solution is the 
transition. yes, but...
3) this is a starting point for discussion. other proposals are also 
welcomed.
4) text and contributions are welcome!

do you agree with the general approach?

Marc.

-- 
=========
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: "Martin J. Dürst" <[email-masked]>
Date: Wed, 07 Jul 2010 09:28:56 +0900

Hello Mark,

In principle, your approach makes very much sense. Ideally, protocol 
designers would just look at the work product of this group, and pick a 
profile, and be done with it. But what about the "not invented here" 
syndrome, or real or strongly perceived needs by a specific protocol for 
something different from the profiles we are going to define? As far as 
I understand, stringprep was more of a "bag of tools", not predefined 
profiles.

Just thinking out loud.

Regards,   Martin.

On 2010/07/06 23:16, Marc Blanchet wrote:
> Hello,
> I just submitted one approach to precis framework. The idea here is that
> usage of i18n strings in protocols would most likely be grouped into a
> few classes of strings. Therefore, the idea is to define these classes,
> and then define a variation of the IDNA2008 algorithm to support these
> classes. Currently, as a strawman, I've (loosely) defined:
> - LRI less-restrictive identifiers). The IDNA2008 is augmented by having
> PVALID, RI_PVALID, LRI_PVALID.
>
> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]