Re: [precis] review template

[Dave Thaler <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Peter Saint-Andre
> Sent: Thursday, November 18, 2010 12:05 PM
> To: [e-mail]
> Subject: Re: [precis] review template
> 
> On 11/8/10 12:08 AM, Marc Blanchet wrote:
> > hello,
> >  during the meeting today, we started brainstorming on the review
> > template. This is the initial outcome, fyi.
> >
> > Boxes
> 
> 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.

> 
> > 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)?
> 
> > 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.)
> 
> > security/authentication decisions
> > 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/
> 
>