On 02/16/2016 12:14 AM, Paul Wouters wrote:
> On Mon, 15 Feb 2016, Harald Alvestrand wrote:
>
>> BTW, this text from the draft is obviously not saying what it intended
>> to say:
>>
>> o The user name (the "left-hand side" of the email address, called
>> the "local-part" in the mail message format definition [RFC5322]
>> and the local-part in the specification for internationalized
>> email [RFC6530]) should already be encoded in UTF-8 (or its subset
>> ASCII). If it is written in another encoding it should be
>> converted to UTF-8 and then hashed using the SHA2-256 [RFC5754]
>> algorithm, with the hash truncated to 28 octets and represented in
>> its hexadecimal representation, to become the left-most label in
>> the prepared domain name. Truncation comes from the right-most
>> octets. This does not include the at symbol ("@") that separates
>> the left and right sides of the email address.
>>
>> As written, it states that hashing is only applied to strings that are
>> not originally in UTF-8 - but the "for example" text below makes it
>> clear that this is not intended.
>
> That text is not quoted from the 07 draft, because 07 states:
>
> o The user name (the "left-hand side" of the email address, called
> the "local-part" in the mail message format definition [RFC5322]
> and the local-part in the specification for internationalized
> email [RFC6530]) is encoded in UTF-8 (or its subset ASCII). If
> the local-part is written in another encoding it MUST be converted
> to UTF-8.
>
> o The local-part is hashed using the SHA2-256 [RFC5754] algorithm,
> with the hash truncated to 28 octets and represented in its
> hexadecimal representation, to become the left-most label in the
> prepared domain name.
>
> Paul
>
Oops - yes, I was reading -06. Good fix!