Dear Peter and all PRECIS related members,
Thank you very much, and I'm really sorry that our definition
had a serious mistake which have confused many of you.
I'll talk with co-authors (especially, Nemoto-san) again and
revise the document as soon as possible,
to restart the next steps as fast as possible.
# That's why our specification has mentioned about
# the mapping for spaces, which are not included by current definition.
When I talked with Peter and Julian, we mentioned about
another character classes during the talk, and at that time
I should be noticed that I possibly referred the incorrect class.
> A wider question: why do you think that the definition of an HTTP
> username needs to be so loose? Do you define things this way to be
> backward compatible with existing implementations, or do you really
> think that this is a best practice? I'm truly curious. (And I wonder
> if we even want to call this construct a "username"...)
I think the reasons are both.
1: For backward compatibility, we need to keep all ASCII "printable"
(U+0020 - U+007E, including SP) characters as is, as well as
Latin-1 printable (U+00A1 - U+00FF, except SHY) be independent.
2: For more semantic reasons, HTTP authentication will be a vehicle
for many different kinds of existing application frameworks, including
IMs, Web mails, social network, and others.
It should be able to accept all kinds of "user name" formats,
for example a simple "user ID" (yoiwa), user "Name" (Yutaka OIWA),
a mail address ([email protected]),
Social ID formats (@yoiwa or =yoiwa), and many others.
Unlike SASL or XMPP which have its own semantics in framework,
the authentication names in HTTP must be semanticless,
unstructured strings, which can later be added a meaningful
semantics for each application which uses Web/HTTP.
We are not likely to correct all possible use cases of
IDs which are to be used with HTTP (including future uses) and
then take a union set of these,
so instead we're defining a "grand-father" ID notations,
expecting that all ID string use-cases are likely to be subsets of it.
At the same time, defining it just a "UTF-8" makes users' confusion
and inter-operability mess about possible "visiblly-same" strings,
so we must care about that side of string preparation with PRECIS.
For example, NBSP and other spaces should be replaced.
2014-03-15 10:55 GMT+09:00 Peter Saint-Andre <[email protected]>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/12/2014 06:54 PM, Yutaka OIWA wrote:
>> Dear Peter,
>>
>> I feel that I'm bit confusing about the situation and possible
>> mistake.
>>
>> As presented in a precis WG long before, and as talked with you
>> with Julien, my intended set for username in HTTP is almost "every
>> printable string", so "@yoiwa", "@@@@@", "Yutaka Oiwa", "Y O"
>> must be all allowed, and my understanding is that saslprepbis does
>> not allow most of these. In other words, http's name must be
>> superset of sasl, and is never be a proper subset of that. Did I
>> made some mistake on specification or interpretation of
>> saslprepbis?
>
> What you describe is not consistent wtih the definition in your
> document, because your ABNF says that only characters from the
> IdentifierClass are allowed (note, for example, SPACE is disallowed in
> the IdentifierClass).
>
> When you say "every printable string", does that include all symbol
> characters, all punctuation characters, every kind of space character
> (not just ASCII space), etc.? What about characters that are
> disallowed even by the FreeformClass, such as Old Hangul Jamo
> characters, control characters, and the ignorable characters described
> in Section 7.13 of the PRECIS framework specification?
>
> I think you need to revisit your httpauthprep document and more
> clearly define the allowable characters for your use cases in terms of
> the PRECIS framework. If you really want to allow "Y O" (with six
> spaces between 'Y' and 'O') as an HTTP username then even
> draft-ietf-precis-nickname is too restrictive for you.
>
> A wider question: why do you think that the definition of an HTTP
> username needs to be so loose? Do you define things this way to be
> backward compatible with existing implementations, or do you really
> think that this is a best practice? I'm truly curious. (And I wonder
> if we even want to call this construct a "username"...)
>
> Peter
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJTI7MJAAoJEOoGpJErxa2pBu0P/3QCU4zx2i/smvPk5RJAlkYq
> 8b17rjXZfnS+K4zLS89FI7KtBsQjGglT7CTvoe4VJt9Xr62/xpMdgRIhfjOC8ZgA
> hAs0l7zbADArHgcA1AENBVUV0C/GGu5QPgJRgn/Mhnf51JxVgyu2ejG+iL0amr7I
> +eQ+0aEhefItYpXF3rhiB8c3hZK+YRrpj6yK4WUDeSzGUi6MPQyhq6WkfHX87gNj
> SsN0T26wIUq5asXKbTC7Yia1aABBYwp+DwMu4O46CkltRv3MYdX1sIAE4sljgzaE
> 837hQE10WTXgSJOQ/qyIHsIBddAItvwewzYNEqUjT1fo8de/hL2gMQ/KV+VTyBEi
> eq59I5wlvqBNlmGj8mOWtv1aVPk/0ANLHeOJVdgumppkYhRbvmSGfjZ5qsFLMDML
> hDxHeQdYb319KlNTrbRmcPLgBZnv5Mlk8T5p9/jUIkID4gk8lDEOVGHImI7ip/jK
> z0mgrCmbsWJtu12cKMHy34URtYVVN0pfdVGup/83/mK4Aq67Mb2iCnv6xWXsc61l
> 1OtGFh1KNY8fTkpabUPwFj5ZAMARI32EQNUbwF4A7kh4aktItqyq6IWhOq3qABlt
> Z6xl3gofvbOQ3LDrrqY/7XKxWNtz4WaGWa0b9SWe8zgopXxQ5W/QncmtMqkCnrG+
> aWDhAUslrrTuqHqw15mp
> =aaQD
> -----END PGP SIGNATURE-----
--
Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group
Research Institute for Secure Systems (RISEC)
National Institute of Advanced Industrial Science and Technology (AIST)
Mail addresses: <[email protected]>, <[email protected]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5]
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
