-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2/18/13 2:20 PM, Peter Saint-Andre wrote:
> [ + [email protected] ]
>
> On 2/18/13 11:04 AM, Chris Newman wrote:
>> --On February 14, 2013 14:24:17 -0700 Peter Saint-Andre
>> <[email protected]> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> On 2/14/13 2:12 PM, Peter Saint-Andre wrote:
>>>> Hi Chris, thank you for the review.
>>>>
>>>> On 2/14/13 12:37 PM, Chris Newman wrote:
>>>>> A common construction for user names on the Internet is
>>>>> the form "[email protected]", specifically, a subset of
>>>>> email-address syntax with an embedded domain name is
>>>>> commonly used for login identity strings (although theses
>>>>> login identity strings may or may not be usable as actual
>>>>> email addresses).
>>>>
>>>>> As a result, the character class used for user names used
>>>>> for authentication needs to be a superset of the character
>>>>> class used for domain names. I was not able to tell from
>>>>> the specification if that was the case. If it isn't, I
>>>>> believe that should be fixed.
>>>>
>>>> It is the case, because all characters in the ASCII range are
>>>> grandfathered into the PRECIS NameClass. Thus some examples
>>>> are definitely in order! We'll add those to the next
>>>> version.
>>>
>>> I propose adding the second paragraph shown below to the end of
>>> Section 2.1, which defines the handling of simple user names:
>>>
>>> Note well that all code points and blocks not explicitly
>>> allowed in the PRECIS NameClass are disallowed; this includes
>>> private use characters, surrogate code points, and the other
>>> code points and blocks defined as "Prohibited Output" in
>>> Section 2.3 of RFC 4013.
>>>
>>> However, all characters in the ASCII range are "grandfathered"
>>> into the PRECIS NameClass. As a result, common constructions
>>> such as "[email protected]" are allowed as simple user names
>>> when using software that conforms to this specification, as
>>> they were under [RFC4013].
>
>> I don't see this as a necessary addition. It was quite clear
>> from the specifications that the ASCII range was grandfathered
>> in NameClass. It appears I was unclear in stating my concern, let
>> me try again to explain my concern.
>
> Yes, I did misconstrue your question.
>
>> My concern is that login identities should be able to contain a
>> valid IDNA U-label. It is not clear to me if NameClass permits
>> all valid U-labels. If it does not, then I believe using
>> NameClass for login identities is a mistake. The [email protected]
>> form for login identities will continue to be useful as the
>> infrastructure is expanded to allow UTF-8 characters in both the
>> "user" part and the "example.com" part of that form. If we
>> disallow valid U-labels in login identities then we break the
>> multi-domain model for lots of software out there and will force
>> that software to change its architecture when it adopts this
>> technology or to choose not to adopt this technology. If valid
>> IDNA U-labels are permitted in login identities then implementers
>> can keep their current architecture and adopt saslprepbis.
>
> Ah, I see. You raise a good question. The intent was that any code
> point allowed in IDNs would be allowed in the PRECIS NameClass,
> but looking closely at draft-ietf-precis-framework I realize that
> the intent might not be reflected in the spec right now. I will
> investigate further and post again when I have something definitive
> to report.
Hi Chris, I've been thinking about this further...
IMHO this is similar to the previous discussion about naming needing
to include space characters (after all, your name is "Chris Newman",
not "ChrisNewman"). After much discussion, participants in the PRECIS
WG concluded that it would be safer to disallow space characters in
the NameClass, and that application protocols would need to define
their constructs as a space-separated series of NameClass instances.
And in fact that's what we've done in draft-ietf-precis-saslprepbis:
simpleusername = simplepart [1*(1*SP simplepart)]
simplepart = 1*(namepoint)
;
; a "namepoint" is a UTF-8 encoded
; Unicode code point that conforms to
; the "NameClass" string class defined
; in draft-ietf-precis-framework
;
Here I see something similar: in order to allow strings like
[email protected], an application protocol would need to define its
constucts along these lines:
userathost = userpart '@' domainpart
userpart = 1*(namepoint)
;
; a "namepoint" is a UTF-8 encoded
; Unicode code point that conforms to
; the "NameClass" string class defined
; in draft-ietf-precis-framework
;
domainpart = IP-literal / IPv4address / ifqdn
ifqdn = 1*64(domainpoint)
;
; a "domainpoint" is a UTF-8 encoded
; Unicode code point that conforms to
; RFC 5890
;
Or, naturally, we could allow both styles (and others).
That said, we might want to allow some characters into the NameClass
that are outside LetterDigits ("A") in RFC 5892. I'm thinking
especially of some of the code points in Exceptions ("F"). This sounds
like an appropriate topic for discussion in Orlando...
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRIwggAAoJEOoGpJErxa2pW5wP/jWNKPKRPSm9JX/pgP6e8SVx
oxme9tEb/mw9ryW+bv343Ut46HX53EfVZnV1nUoxOexSP3TCJmViUQFgCTiD/wi5
r/UV8XqU0l1cSfxW0zyZEFG0BcFt64ggzg/e9GigKWEnKZBgZJqMNb3+urGmz9d3
BN6bIWEBBV57RSDcYPOTe10Wrq2H27AZerDxcYVn02BRM4iFM9RLSVIFfM0QwkeX
d1JRjYt9lhtNJkxMhNV6BS17z5g8H0w/Fhl96DWpxdQTWAETiybgz9LI1bpNsS59
IFrxkPWThUvUB/NUyIK1mFIrQq5FkJ3owT6S+Xg4ude/uXLWoOcExA6141dpguoS
0WGesk7jeN/6NUiPKX4oNMc4dd1fVOQlu/rFCY3+0hACTdT5xVLtJ69dRlb4hrmx
rmLKfOA8CljV/3NN4eYBDnQd6og66I1BanEJ/A9KuwWpTi8EEehbkejkc0B6FZyl
K9HKbEcu4iWDoOMGlRoKb7ApLKi3sW5GN44aqpwQRiZw4goIzlNJReubp64HdtoZ
mss9iPVY2V11JykVxKCGKMJ/WpnHLZtOmsrfIt6tjONsw9npQPlOm5XqktLjasR8
cobeV0qg9x8gJkT1oaZKbEjctPAZh7fz3H+i0EcTsTjOs0fjJTU30osUzAZTPIoq
VM4sgvjRuE4vfbtnkJXw
=6LeL
-----END PGP SIGNATURE-----
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
