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
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:
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
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
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
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?
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
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
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
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
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.
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
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
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
>>
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
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
> 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
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
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
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
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
21 matches
Mail list logo