Re: Proposals for Arabic honorifics

If there are no comments on this specific issue, could someone care to comment on the idea of writing a proposal that extends and existing proposal? Is this considered bad form, or is it OK so long as it doesn't unnecessarily raise conflicting proposals? - Naz. On 5/10/2015 6:39 PM, Naz

Re: Proposals for Arabic honorifics

Hello Naz, Thank you for discussing your proposal on the unicode list. Not all experts monitor that list. That said, feel free to submit a proposal to "docsub...@unicode.org". Look forward to seeing your proposal. Lisa From: Naz Gassiep To:

Re: Unicode in passwords

On Tue, 6 Oct 2015 11:21:42 +0200 Mark Davis ☕️ wrote: > While I think that RFC is useful, it has been interesting just how > many of the problems recounted on this list go far beyond it, often > having to do with UI issues. It would be useful to have a paper > somewhere that

Re: Why Nothing Ever Goes Away

On Tue, 6 Oct 2015 15:57:37 +0200 Philippe Verdy wrote: > My opinion of UTF-7 is that > it was just a temporary and experimental solution to help system > admins and developers adopt the new UCS, including for their old > 7-bit environments. If you have a human controlling

Re: Unicode in passwords

2015-10-06 21:57 GMT+02:00 Richard Wordingham < richard.wording...@ntlworld.com>: > It's an interesting issue for a password that one can't type. It's by > no means a guarantee, either. I once specified a new a password that > changed case in the middle not realising that I had started with

Re: Unicode in passwords

On Tue, 6 Oct 2015 20:13:12 +0100 (BST) Julian Bradfield wrote: > On 2015-10-06, Asmus Freytag (t) wrote: > > All browsers I use display spaces in input boxes, and put blobs for > > hidden fields. Do you have evidence for broken input fields?

Re: Unicode in passwords

2015-10-06 16:31 GMT+02:00 Julian Bradfield : > On 2015-10-06, Philippe Verdy wrote: > > I don't think it is a good idea for tectual passwords to make differences > > based on the number of spaces. Being plain text they are likely to be > > displayed

Re: Unicode in passwords

On Tue, Oct 06, 2015 at 12:57:51PM +0900, Yoriyuki Yamagata wrote a message of 33 lines which said: > FYI, IETF is working on this issue. See Internet Draft > https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-17 based > on PRECIS framework RFC 7564

Re: Unicode in passwords

On 2015-10-06, Asmus Freytag (t) wrote: > All browsers I use display spaces in input boxes, and put blobs for > hidden fields. Do you have evidence for broken input fields? > > > Network keys. That interface seems to consistently give people a > choice

Re: Unicode in passwords

While I think that RFC is useful, it has been interesting just how many of the problems recounted on this list go far beyond it, often having to do with UI issues. It would be useful to have a paper somewhere that organizes all of the problems presented here, and maybe makes a stab at describing

Re: Unicode in passwords

On 2015-10-06, Philippe Verdy wrote: > Finally note that passwords are not necessarily single identifiers > (whitespaces and word separators are accepted, but whitespaces should > require special handling with trimming (at both ends) and compression of > multiple occurences.

Re: Unicode in passwords

I don't think it is a good idea for tectual passwords to make differences based on the number of spaces. Being plain text they are likely to be displayed in utser interfaces in a way that the user will not see. Without trimming, users won't see the initial or final space, and the password input

Re: Unicode in passwords

And there are severe issues in this RFC for its case mapping profile: it requires converting "uppercase" characters to "lowercase", but these properties are not stable (see for example the history of Cherokee letters, changed from gc=Lo to gc=Lu when lowercase letters were added and with case

Re: Why Nothing Ever Goes Away

2015-10-06 14:24 GMT+02:00 Sean Leonard : > 2. The Unicode code charts are (deliberately) vague about U+0080, U+0081, >> and U+0099. All other C1 control codes have aliases to the ISO 6429 >> set of control functions, but in ISO 6429, those three control codes don't >>

Re: Why Nothing Ever Goes Away

2. The Unicode code charts are (deliberately) vague about U+0080, U+0081, and U+0099. All other C1 control codes have aliases to the ISO 6429 set of control functions, but in ISO 6429, those three control codes don't have any assigned functions (or names). On 10/5/2015 3:57 PM, Philippe Verdy

Re: Unicode in passwords

Note that Java strings DO allow the presence of lone surrogates, as well as non-characters , because Java strings are unrestricted vectors of 16-bit code units (non-BMP characters are handled as pairs of surrogates). In those conditions, normalizing the Java string will leave those lone

Re: Unicode in passwords

> On Oct 6, 2015, at 6:04 , Philippe Verdy wrote: > > In those conditions, normalizing the Java string will leave those lone > surrogates (and non-characters) as is, or will throw an exception, depending > on the API used. Java strings do not have any implied encoding

Re: Why Nothing Ever Goes Away

Asmus Freytag (t) wrote: > Nobody wanted to follow the IBM code page 437 (then still the most > widely used single byte vendor standard). Although to this day, the UN/LOCODE manual [1] still refers to 437 as "the standard United States character set" and claims that it "conforms to these ISO

Re: Unicode in passwords

On 10/6/2015 7:31 AM, Julian Bradfield wrote: All browsers I use display spaces in input boxes, and put blobs for hidden fields. Do you have evidence for broken input fields? Network keys. That interface seems to consistently give people a choice

Re: Unicode in passwords

On 2015-10-06, Philippe Verdy wrote: > I don't think it is a good idea for tectual passwords to make differences > based on the number of spaces. Being plain text they are likely to be > displayed in utser interfaces in a way that the user will not see. Without This is true

Re: Why Nothing Ever Goes Away

On 10/6/2015 5:24 AM, Sean Leonard wrote: And, why did Unicode deem it necessary to replicate the C1 block at 0x80-0x9F, when all of the control characters (codes) were equally reachable via ESC 4/0 - 5/15? I understand why it is desirable to align