[ Old thread alert! ]
On 3/25/14, 12:52 AM, Yutaka OIWA wrote:
Dear Peter,
I have a side question: looking into saslprepbis spec,
username = userpart [1*(1*SP userpart)]
/ userpart ’@’ domainpart
userpart = 1*(idpoint)
domainpart = IP-literal / IPv4address / ifqdn
ifqdn = 1*1023(domainpoint)
Is the set of strings generated by "userpart '@' domainpart"
the proper subset of the set generated by userpart rule?
Yes, I think so.
(Compare the derived property calculation rules in RFC 5892 against
draft-ietf-precis-framework.)
If so, I will be more-than-80% happy by just removing the
redundant second line from the username rule.
Do you mind if we explain in the text that it is possible to create such
a construct? See also:
https://tools.ietf.org/html/draft-ietf-precis-framework-18#section-4.2
We (from HTTP side) do not want any rule which may
even *seem* to handle any characters (here, the @ mark)
specially than others. It's up to the application's own definition.
Yes, and that's what the PRECIS framework says.
We're aware of some use case for which
the application defines a meaningful semantics
for strings with 2 @ marks.
(user@domain style identifier used for roaming accesses,
appended with another @provider-domain suffix.
So, the result is user@internal-domain@external-domain.)
(Exception: the colon is special in HTTP Basic and Digest,
but I see it as a known technical issue of these and
should not be generalized for every HTTP authentication.)
I have to (and will) dig in to the original Unicode table for
more analysis, but the thing I intuitively want seems to be
something between IdentifierClass and FreeFormClass.
I think you want a username, if we adjust the saslprepbis definition
slightly.
My answers to the Peter's questions:
"Y u taka O i w a"
Current HTTP allows it, and we don't need to reject that mostly.
Does the HTTPAUTH WG want to support everything that HTTP currently
supports, or is it open to restricting things a bit more?
Usernames like that don't make sense to me. However, I don't think I
have a strong reason for disliking them, other than UX concerns. So I'm
open to loosening the saslprepbis rules here, if only to prevent forking
(or another profile just for HTTPAUTH).
(and saslprepbis's username acutally allows it except the last spaces.)
"♖♘♗♕♔♗♘♖" (i.e., the back line of white chess pieces)
I have a 50-50 feeling on this, little bit offseted to accept.
It's really weired, *I* will never use this, but it's still harmless, I think.
Someone may be using this as a funny identifier.
IMHO it's appropriate as a nickname but not as a username. But perhaps
I'm being too strict.
Note: if we allow those characters, then we're far beyond the PRECIS
IdentifierClass (which forbids symbols). So if the HTTPAUTH WG wants to
support symbols, it needs to profile the PRECIS FreeformClass.
I think I have to convince HTTP people that it's harmful.
Well, it would require another profile, since we're not going to allow
symbols into the PRECIS IdentifierClass.
"mycatisa bby" (where those spaces are actually a tab)
I think this should be either rejected or replaced with a single space.
So no control characters. That's something. :-)
The support: most text input field of modern applications accepts
the top two, but for the last case some apps are rejecting TAB.
At least, almost all applications explicitly filter CR and LF out.
OK.
I think we can declare that "CR, LF, TAB, SHY and NBSP are harmful
so we should handle it as a part of I18N string handling".
It's the purpose of PRECIS, I agree.
(and that's why I am strongly opposing against "just UTF-8" in HTTPAUTH WG).
Has there been further discussion about this in the HTTPAUTH WG? I'm on
that mailing list and I haven't seen much discussion on this topic.
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
