On 12/7/14, 8:49 PM, Peter Saint-Andre - &yet wrote:
On 11/23/14, 7:58 AM, Patrik Fältström wrote:
I have on request from the chairs done a review of three Precis
documents. Here is the review of draft-ietf-precis-framework-20.
Patrik, many thanks for the thorough review!
The review has focused on the use of Unicode and the relationship
with IDNA2008.
You see my comments below.
Best, Patrik Fältström
draft-ietf-precis-framework-20
Abstract
Application protocols using Unicode characters in protocol strings
need to properly handle such strings in order to enforce
internationalization rules for strings placed in various protocol
slots (such as addresses and identifiers) and to perform valid
comparison operations (e.g., for purposes of authentication or
authorization). This document defines a framework enabling
application protocols to perform the preparation, enforcement, and
comparison of internationalized strings ("PRECIS") in a way that
depends on the properties of Unicode characters and thus is agile
with respect to versions of Unicode. As a result, this framework
provides a more sustainable approach to the handling of
internationalized strings than the previous framework, known as
Stringprep ( RFC 3454). This document obsoletes RFC 3454 .
Explanation on what my review is concentrating on:
When using a character set like Unicode where things like
transformation, comparisons etc, the actual transformation can happen
in multiple locations in the architecture, and what is needed is for
applications to understand what format the strings are that are
received and what format strings are expected to be in when being
sent. Of course the principle of "be liberal in what you accept, and
conservative in what you send" is very important.
A simplified sketch of the architecture is as follows:
1. [A] sends a string to [B] for storage
2. [C] send a string to be for lookup, which implies matching
algorithm is applied
3. If there is a match, data is sent back to [C]
In this very simple way of looking at the issues the questions
include:
A. What Unicode code points should [A] accept as input
B. What transformation is [A] expected to do?
C. What transformation is [A] allowed to do?
D. What Unicode code points is [A] allowed to send to [B]?
E. What Unicode code points can [B] expect from [A]?
F. What transformation is [B] expected to do on data sent from [A]
before data is stored in the database?
: :
I.e. it must be as clear as possible for each one of the parties A, B
and C what they are expected to do, what they must (and must not)
do.
For the profiles and application usages that go along with the framework
(draft-ietf-precis-saslprepbis, draft-ietf-precis-nickname,
draft-ietf-xmpp-6122bis), we have tried to address the considerations
you raise. However, I think that in several places we could do a better
job, such as:
i. Explain not only what entities are expected to do, but also what they
are allowed to do.
ii. Specify what various using applications need to do (e.g., I don't
think we've made that fully clear in the saslprepbis and nickname
documents, although I think it is very clear in 6122bis).
These are matters that we can focus on during WGLC for those specs, I
think.
I have updated the saslprepbis and nickname specs in an attempt to
address these issues:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-13.txt
http://tools.ietf.org/rfcdiff?url2=draft-ietf-precis-nickname-14.txt
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
