Re: [precis] Fwd: I-D Action: draft-blanchet-precis-framework-01.txt

[Marc Blanchet <[e-mail]>]

Florian,
- thanks for your input.
- regarding your points on the properties, building tables, ...: we took 
roughly the same approach as IDNAbis (RFC5892) on purpose. About 
building the tables, as with IDNAbis, a registry would be setup 
similarly to http://www.iana.org/assignments/idnabis-tables

Regards, Marc.

Le 11-05-21 03:02, Florian Zeitz a écrit :
> Am 17.05.2011 18:29, schrieb Peter Saint-Andre:
>> This document attempts to incorporate the rough proposal I outlined in
>> Prague. It still contains a number of open issues. Feedback is very much
>> welcome!
>>
>> /psa
>>
> Hy,
>
> this is some feedback based on an initial read-through. It contains both
> comments and questions that came to mind during reading.
> The questions are largely unfiltered (i.e. answers to them became
> somewhat apparent after having read the whole document) in the hope that
> this will help identify areas where the text could be improved.
>
> First of all I maintain that "compatibility equivalent" (used in
> multiple places) is the wrong term. Unicode 6.0 Chapter 3.7 defines
> compatibility equivalent by their full compatibility decompositions
> being identical. Compatibility decomposition in turn however is defined
> as the result of applying both compatibility mappings and canonical
> mappings.
> That is different from the definition NFKC(cp) == cp.
> I think the proper wording for the category Q is "All compatibility
> decomposable characters".
>
> As someone else had mentioned in Prague I too am not sure "Wordything"
> is a good expression for passwords. While passwords are words in the
> sense of being elements of L((((A|Q)\(L|N|O|P))|K)*) (i.e. The language
> described by the regular expression that (hopefully) describes
> Wordything) people tend to think of words as "Those things listed in a
> dictionary" which is precisely what we don't want people to use as password.
>
> I understand Stringything stems from XMPP's resources.
> However the draft describes it as being used for nick-names. It is not
> clear to me what the argument for differentiating nick-names and normal
> names is. Especially considering both potentially need to be entered by
> a end-user.
>
> Having a Valid and a Disallowed rule was quite confusing. Especially
> considering that Valid rules contain exceptions from the Disallowed rule
> and vice-versa.
> Some of the questions that sprung to mind were:
> What about code points that are neither matched by the Valid nor the
> Disallowed rule? Can that happen?
> Is the union of both sets (Valid and Disallowed) the set of all Unicode
> code points? Is it guaranteed to stay that way in future Unicode versions?
> Also theses rules don't describe behaviour for CONTEXT? code points.
>
> The draft says in a lot of places that directionality, case-mapping and
> normalization rules are application specific (At least sections 3,
> 3.{1,2,3}.{4,5,6} and 4.1). That seams rather redundant.
>
> Maybe that's just me, but if we specify that applications need to
> specify how to do normalization I think it might be worthwhile to give
> some guidance on when to normalize strings.
>
> The OPEN ISSUE in section 3.2.5 suggests mapping uppercase and titlecase
> code points to their lowercase equivalents maximizes entropy. Maybe I'm
> just confused, but doesn't that effectively reduce the set of possible
> characters and therefore entropy?
> Personally I think saying it's NOT RECOMMENDED for application protocols
> to perform such mappings is the right thing to do.
> Furthermore I think allowing symbols and punctuation is the right thing
> to do. In the age of laptops not being able to type your password any
> more should be less of a problem.
>
> The Unassigned rule states that not yet assigned code points are to be
> considered Unassigned. To me that seems not only trivial, but especially
> doesn't appear to be a rule on how to handle unassigned code points at
> all...
>
> The fact that code points can only have one derived property appears
> strange to me. It makes the algorithm non-deterministic in that it
> sometimes sets the derived property to one of three values. I think
> allowing multiple derived properties at the same time might be clearer.
>
> Is it expected that people will calculate derived properties themselves,
> or look them up in a to be created normative table separate from the
> RFC? It seams to me that the former would need a complete Unicode table
> and an implementation of a  relatively complex algorithm, while the
> later is a simple table lookup from a smaller table.
> However the former still seems more elegant...
>
> And last and least a remark: IIRC what was agreed on was a inclusive
> approach only disallowing certain characters. The pseudo-code however
> defaults to DISALLOWED if no class was matched.
> That seems right to me, but implies we are still using an approach that
> is only allowing certain characters, however it's more flexible and
> version agile.
>
> --
> Florian Zeitz
>
>> -------- Original Message --------
>> Subject: I-D Action: draft-blanchet-precis-framework-01.txt
>> Date: Tue, 17 May 2011 09:22:44 -0700
>> From: [e-mail]
>> Reply-To: [e-mail]
>> To: [e-mail]
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>> 	Title           : PRECIS Framework: Handling Internationalized Strings
>> in Protocols
>> 	Author(s)       : Marc Blanchet
>>                            Peter Saint-Andre
>> 	Filename        : draft-blanchet-precis-framework-01.txt
>> 	Pages           : 24
>> 	Date            : 2011-05-17
>>
>>     Application protocols that make use of Unicode code points in
>>     protocol strings need to prepare such strings in order to perform
>>     comparison operations (e.g., for purposes of authentication or
>>     authorization).  In general, this problem has been labeled the
>>     "preparation and comparison of internationalized strings" or
>>     "PRECIS".  This document defines a framework that enables
>> application
>>     protocols to prepare various classes of strings in a way that depends
>>     on the properties of Unicode code points.  Because this framework
>>     does not depend on large tables of Unicode code points as in
>>     stringprep (RFC 3454), it is more agile with regard to changes in the
>>     underlying Unicode database and thus provides improved flexibility to
>>     application protocols.  A specification that reuses this framework
>>     either can directly use the base string classes defined in this
>>     document or can subclass the base string classes as needed.  This
>>     framework uses an approach similar to that of the revised
>>     internationalized domain names in applications (IDNA) technology (RFC
>>     5890, RFC 5891, RFC 5892, RFC 5893, RFC 5894) and thus adheres to the
>>     high-level design goals described in RFC 4690, albeit for non-IDNA
>>     technologies.  This document obsoletes RFC 3454.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-blanchet-precis-framework-01.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-blanchet-precis-framework-01.txt
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>
>>
>> _______________________________________________
>> precis mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/precis
>
> _______________________________________________
> precis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/precis


-- 
=========
IETF81 Quebec city: http://ietf81.ca
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN Implementation: http://postellation.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca
Space Assigned Number Authority: http://sanaregistry.org