Subject: [precis] review template

From: Marc Blanchet <[email-masked]>
Date: Mon, 08 Nov 2010 15:08:09 +0800

hello,
  during the meeting today, we started brainstorming on the review 
template. This is the initial outcome, fyi.

Boxes
Case folding; case sensitivity, preserve case
User input
Normalization
Classes
User exposed to
published/seen
security/authentication decisions
Impacts of false positves and false negatives
tolerance of changes in the community
Delimiters such as .

Marc.
-- 
=========
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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 18 Nov 2010 13:04:45 -0700

> template. This is the initial outcome, fyi.

It would be quite helpful if Dave Thaler could provide a one-sentence
description of each "box" as discussed at the meeting, because otherwise
folks reading the email list will be clueless. :)

> Case folding; case sensitivity, preserve case

Ack. Naturally there are complexities involved (e.g, for what codepoint
blocks do we want to preserve case?).

> User input

Can we unpack that a bit? It might involve answers to at least the
following questions (and probably more):

a. Do users input the strings directly?

b. If so, how? (keyboard, stylus, voice, copy-paste, etc.)

c. Where do we place the dividing line between user interface and
protocol? (see RFC 5895)

> Normalization

I'm rereading http://unicode.org/reports/tr15/ now... ;-)

> Classes

I take it these are econceptually similar to the string classes proposed
in draft-blanchet-precis-framework, but we need to figure out which
classes we think are appropriate. It might help to ask:

a. Which other strings or identifiers are these most similar to?

b. Are these strings or identifiers sometimes the same as strings or
identifiers from other protocols (e.g., does an IM system sometimes use
the same credentials database for authentication as an email system)?

> published/seen

Again, exactly how are users exposed to these strings, how are they
published? (vCard, web directory, business card, side of the bus, etc.)

> Impacts of false positves and false negatives

As we discussed in Beijing, authentication and authorization issues
probably fall under "impacts of false positives and false negatives".
What other security issues do we envision? (denial of service, etc.)

> tolerance of changes in the community

And also perhaps "desire for something better / more sustainable / more
agile w.r.t. Unicode versions".

> Delimiters such as .

I think we can generalize "delimiters" to something like "does the
string or identifier have internal structure?"

That's it for now...

Peter

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

---

From: Dave Thaler <[email-masked]>
Date: Thu, 18 Nov 2010 20:15:31 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Peter Saint-Andre
> Sent: Thursday, November 18, 2010 12:05 PM
> To: [email-masked]
> Subject: Re: [precis] review template
> 
> It would be quite helpful if Dave Thaler could provide a one-sentence description
> of each "box" as discussed at the meeting, because otherwise folks reading the
> email list will be clueless. :)

They're in the minutes from IETF:

>  3 types of identifiers used by precis customers:
>   a) compare byte-by-byte
>   b) compare by a common algorithm that everyone agrees on
>   c) No single common comparison algorithm for everyone
>   (Specifically, everyone might want the comparison to be tailored for their locale, for some definition of locale)

Except I called them 1-3, where they're a-c in the minutes :)

In Beijing I also mentioned a subcase of (3) which is:
3a) No single common comparison algorithm for everyone, but within one or more constrained subsets of users/uses there may be an agreed on comparison algorithm.    E.g., US-ASCII users might agree on a comparison algorithm but US-ASCII vs Turkish users may not, for a given type of identifier.

> Ack. Naturally there are complexities involved (e.g, for what codepoint blocks
> do we want to preserve case?).
> 
> > User input
> 
> Can we unpack that a bit? It might involve answers to at least the following
> questions (and probably more):
> 
> c. Where do we place the dividing line between user interface and protocol?
> (see RFC 5895)
> 
> > Normalization
> 
> I take it these are econceptually similar to the string classes proposed in draft-
> blanchet-precis-framework, but we need to figure out which classes we think
> are appropriate. It might help to ask:
> 
> b. Are these strings or identifiers sometimes the same as strings or identifiers
> from other protocols (e.g., does an IM system sometimes use the same
> credentials database for authentication as an email system)?
> 
> > User exposed to
> > published/seen
> 
> Again, exactly how are users exposed to these strings, how are they published?
> (vCard, web directory, business card, side of the bus, etc.)
> 
> As we discussed in Beijing, authentication and authorization issues probably fall
> under "impacts of false positives and false negatives".
> And also perhaps "desire for something better / more sustainable / more agile
> w.r.t. Unicode versions".
> 
> > Delimiters such as .
> 
> I think we can generalize "delimiters" to something like "does the string or
> identifier have internal structure?"
> 
> That's it for now...
> 
> Peter
> 
> --
> Peter Saint-Andre
> https://stpeter.im/
> 
>