Subject: [EMAIL FROM ZACK:] Re: ietf Digest, Vol 93, Issue 59

From: Zack Cylinder <[email-masked]>
Date: Tue, 16 Feb 2016 10:39:23 -0800

Great! Sounds good!

Zack Cylinder
Cloud Training Specialist
Cloudbakers.com

On Mon, Feb 15, 2016 at 9:46 AM, <[email-masked]> wrote:

> Send ietf mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/ietf
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ietf digest..."
>
>
> Today's Topics:
>
>    1. Re: Is Fragmentation at IP layer even needed ? (Joe Touch)
>    2. Re: Is Fragmentation at IP layer even needed ? (Masataka Ohta)
>    3. Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> (E Taylor)
>    4. Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
>       (Harald Alvestrand)
>    5. Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
>       (John C Klensin)
>    6. Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
>       (Harald Alvestrand)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 14 Feb 2016 20:00:16 -0800
> From: Joe Touch <[email-masked]>
> To: Masataka Ohta <[email-masked]>, [email-masked]
> Subject: Re: Is Fragmentation at IP layer even needed ?
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=iso-2022-jp
>
>
>
> On 2/13/2016 5:26 PM, Masataka Ohta wrote:
> > QoS (not CoS but real QoS) capable routers must inspect L4.
>
> That must be why there are QoS indicators in the L4 header.
>
> Oh, wait - those are in L3 (RFC2474 and its successors).
>
> Yes, layering is a difficult concept.
>
> Joe
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 15 Feb 2016 16:06:19 +0900
> From: Masataka Ohta <[email-masked]>
> To: Joe Touch <[email-masked]>, [email-masked]
> Subject: Re: Is Fragmentation at IP layer even needed ?
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=iso-2022-jp
>
> Joe Touch wrote:
>
> >> QoS (not CoS but real QoS) capable routers must inspect L4.
> >
> > That must be why there are QoS indicators in the L4 header.
>
> There are not.
>
> > Oh, wait - those are in L3 (RFC2474 and its successors).
>
> Can you read this?
>
>         QoS (not CoS but real QoS)
>
> > Yes, layering is a difficult concept.
>
> Layering is trivially easy. If you think it difficult,
> that is your problem.
>
>                                                 Masataka Ohta
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 15 Feb 2016 08:36:36 +0000
> From: E Taylor <[email-masked]>
> To: John C Klensin <[email-masked]>, [email-masked]
> Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=UTF-8
>
> Hello,
>
> Thank you, John, for your detailed comments on the i18n aspect of this
> draft, which I admit I hadn't fully considered.  I think you're right
> that, whatever approach is taken, it would make sense to add a short
> "Internationalization Considerations" section to state what the expected
> interaction is between this specification and non-ASCII addresses.
>
> More comments inline below:
>
> > Temporarily and for purposes of discussion, assume I agree with
> > the above as far as it goes (see below).   Given that, what do
> > you, and the systems you have tested, propose to do about
> > addresses that contain non-ASCII characters in the local-part
> > (explicitly allowed by the present spec)?  Note that lowercasing
> > [1] and case folding are different and produce different results
> > and that both are language-sensitive in a number of cases, what
> > specifically do you think the spec should recommend?
>
> I have not seen any specific examples of software which unintentionally
> converts characters to uppercase (although I can readily imagine such
> bugs/features), so I'm prepared to assume that the lowercasing logic can
> be safely limited to just the input strings which include only ASCII
> characters.  My idea was for the client to make a reasonable effort to
> correct for a plausible (but rare) problem, so for the purposes of an
> experiment I think it is acceptable if this correction does not try
> anything more clever, like converting [email-masked] to
> mustafa.ak?nc?@example.com (although [email-masked] should
> be tried).
>
> > Also, do you think it is acceptable to publish this document
> > with _any_ suggestions about lower-casing or "try this, then try
> > something else" search without at least an "Internationalization
> > Considerations" section that would discuss the issues [1] and/or
> > some more specific recommendation than "try lowercase" (more on
> > that, with a different problem case, below).
>
> You are right that adding such a section could be of great benefit to at
> least some implementers, even if the discussion in that section is
> simply "Only try lower-casing when the input is all ASCII".  If someone
> can come up with something more helpful than that brief statement, then
> I'd be very supportive of it.
>
> > Dropping that assumption of agreement for discussion, I
> > personally believe that this document could be acceptable _as an
> > Experimental spec_ with any of the following three models, but
> > not without any of them:
> >
> >  (i) The present "MUST not try to guess" text.
> >
> >  (ii) A recommendation about lowercasing along the lines
> >       you have outlined but with a clear discussion of i18n
> >       issues and how to handle them [2].
> >
> >  (iii) A clear statement that the experiment is just an
> >       experiment and that, for the purposes of the experiment,
> >       addresses that contain non-ASCII characters in the local
> >       part are not acceptable (note that would also require
> >       pulling the UTF-8 discussion out of Section 3 and
> >       dropping the references to RFC 6530 and friends).
>
> Perhaps you would settle for an option (ii.v) which is my lowercasing
> recommendation + a discussion of the i18n issues + that discussion being
> based on the experimental restriction of only applying the lowercasing
> logic to ASCII-only local parts.  I hope that would be in keeping with
> your sensible suggestions above.
>
> > ...
> > e.g.,
> >    U+0066 U+006F U+0308 U+006F   and
> >    U+0066 U+00F6 U+006F
> > are perfectly good (and SMTPUTF8-valid) representations of the
> > string "f?o"
> >
> > Using the same theory as your lower case approach, would you
> > recommend trying first one of those and then the other [3]?
>
> That is tempting, but I accept that it may be too much unnecessary
> complexity to suggest or recommend it at this stage of the experiment.
> I know that various ideas have been proposed for handling normalisation
> of local-parts more generally, and I think we should allow that work to
> progress separately, uncoupling it from the document at hand.
>
> > The more I think about it, the more I'm convinced that the
> > specification and allowance for UTF-8 [4] in the first bullet of
> > Section 3 is unacceptable without either text there that much
> > more carefully describes (and specifies what to do about) these
> > cases or an "Internationalization Considerations" section that
> > provides the same information.  I suggest that anyone
> > contemplating writing such text carefully study (not just
> > reference) Section 10.1 of RFC 6530.   Of course, simply
> > excluding non-ASCII local-parts from the experiment, as
> > suggested in (iii) above, would be an alternative.  I have mixed
> > feelings about whether it would be an acceptable one for an
> > experiment.  I am quite sure it would not be acceptable for a
> > standards-track document when the EAI work and/or the IETF
> > commitment to diversity are considered.
>
> I think that excluding non-ASCII local-parts from just the extra
> lower-casing logic, and pointing out the complexity of case handling in
> non-ASCII contexts in a separate section as you have suggested, might
> address the outstanding concerns, without hindering diversity.
>
> > ...
> > [2] I note that, historically, the DNS community has been very
> > reluctant to accept techniques that depend on or imply multiple
> > lookups for a single perceived object and, separately, for
> > "guess at this, try it, and, if that does not work, guess at
> > something else" approaches.  Unless those concerns have
> > disappeared, the potential for combinatorial explosion when
> > lower-casing characters that may lie outside the ASCII
> > repertoire is truly impressive.
>
> That's another reasonable point, thank you.  Hopefully it is mitigated,
> at least for the most part, by settling for only lower-casing characters
> for all-ASCII local-parts, avoiding the combinatorial explosion you
> mention.  Also, this extra lower-casing step will only happen in the
> relatively rare situations where the input local-part contains at least
> one upper-case character (although I don't know in practice how many
> extra lookups that will lead to, on average).
>
> Best regards,
> Edwin
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 15 Feb 2016 16:33:55 +0100
> From: Harald Alvestrand <[email-masked]>
> To: [email-masked]
> Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=utf-8
>
> On 02/15/2016 09:36 AM, E Taylor wrote:
> > Hello,
> >
> > Thank you, John, for your detailed comments on the i18n aspect of this
> > draft, which I admit I hadn't fully considered.  I think you're right
> > that, whatever approach is taken, it would make sense to add a short
> > "Internationalization Considerations" section to state what the expected
> > interaction is between this specification and non-ASCII addresses.
> >
> > More comments inline below:
> >
> >> Temporarily and for purposes of discussion, assume I agree with
> >> the above as far as it goes (see below).   Given that, what do
> >> you, and the systems you have tested, propose to do about
> >> addresses that contain non-ASCII characters in the local-part
> >> (explicitly allowed by the present spec)?  Note that lowercasing
> >> [1] and case folding are different and produce different results
> >> and that both are language-sensitive in a number of cases, what
> >> specifically do you think the spec should recommend?
> > I have not seen any specific examples of software which unintentionally
> > converts characters to uppercase (although I can readily imagine such
> > bugs/features), so I'm prepared to assume that the lowercasing logic can
> > be safely limited to just the input strings which include only ASCII
> > characters.  My idea was for the client to make a reasonable effort to
> > correct for a plausible (but rare) problem, so for the purposes of an
> > experiment I think it is acceptable if this correction does not try
> > anything more clever, like converting [email-masked] to
> > mustafa.ak?nc?@example.com (although [email-masked] should
> > be tried).
>
> Note that the user understandability of "only lowercase if it's all
> ASCII" is zero.
>
> If ARNE matches arne, but BL?B?R doesn't match bl?b?r, any user from an
> extended-ASCII country (which is *all* Latin script using countries,
> even though the non-ASCII variants in English are rarely used) will be
> mighty confused.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 15 Feb 2016 11:46:52 -0500
> From: John C Klensin <[email-masked]>
> To: Harald Alvestrand <[email-masked]>, [email-masked]
> Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=utf-8
>
>
>
> --On Monday, February 15, 2016 4:33 PM +0100 Harald Alvestrand
> <[email-masked]> wrote:
>
> > Note that the user understandability of "only lowercase if
> > it's all ASCII" is zero.
> >
> > If ARNE matches arne, but BL?B?R doesn't match bl?b?r, any
> > user from an extended-ASCII country (which is *all* Latin
> > script using countries, even though the non-ASCII variants in
> > English are rarely used) will be mighty confused.
>
> Indeed.
>
> However, that is exactly the decision we made with IDNA (both
> the "2003" and "2008" versions and, as there, may be
> justification for really strong advice for treating email
> addresses (both local and domain parts) as lower-case only.
>
> Harald, I am confident you know all of this, but others may
> not...  The idea of requiring that mailbox names be treated as
> all lower case was discussed during the work leading up to RFC
> 1123 and again in DRUMS (pre-2821).  The community reached what
> appeared to me as fairly strong consensus that we just couldn't
> do it.  Part of the problem was that, at the time 821 was
> written (and maybe as late as the time of DRUMS) there were
> still systems around that operated upper-case-only and had only
> the vaguest idea what lower case was.  Another part was that
> Unix (and Multics) and some of their successors were very
> case-sensitive in general: "foo" and "Foo" and "foO" were
> unambiguously three different names.
>
> Because of that history and consensus, the strong suggestions in
> 5321 are about as far as one is going to get as far as
> restrictions/ recommendations on the mailbox names themselves
> and the "don't try to guess" rule probably isn't going anywhere.
>
> In retrospect, we dodged a bullet because, for mailbox local
> parts, ARNE does not, in terms of anything a sender is allowed
> to predict, match arne.  That BL?B?R doesn't match bl?b?r
> may still be a surprise to some, but it is not more or a
> surprise.
>
> >From that perspective, the problem facing DANE is that either
> the basic "if they are not identical, they don't match" rules is
> applied or there is a need to invent rules different from the
> email rules and that de facto modify the email rules by
> restricting the syntax of a mailbox if there is any possibility
> a DANE DNS record will be used with it.  Nothing I'm aware of
> (other than probably the WG Charter) prohibits DANE from
> proposing an update to 5321 and 6530ff, but the history (and
> probable side-effects that no one has tried to analyze) predicts
> that the idea won't easily get community consensus.
>
>      john
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 15 Feb 2016 18:46:13 +0100
> From: Harald Alvestrand <[email-masked]>
> To: [email-masked]
> Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=utf-8
>
> On 02/15/2016 05:46 PM, John C Klensin wrote:
> >
> > --On Monday, February 15, 2016 4:33 PM +0100 Harald Alvestrand
> > <[email-masked]> wrote:
> >
> >> Note that the user understandability of "only lowercase if
> >> it's all ASCII" is zero.
> >>
> >> If ARNE matches arne, but BL?B?R doesn't match bl?b?r, any
> >> user from an extended-ASCII country (which is *all* Latin
> >> script using countries, even though the non-ASCII variants in
> >> English are rarely used) will be mighty confused.
> > Indeed.
> >
> > However, that is exactly the decision we made with IDNA (both
> > the "2003" and "2008" versions and, as there, may be
> > justification for really strong advice for treating email
> > addresses (both local and domain parts) as lower-case only.
> >
> > Harald, I am confident you know all of this, but others may
> > not...  The idea of requiring that mailbox names be treated as
> > all lower case was discussed during the work leading up to RFC
> > 1123 and again in DRUMS (pre-2821).  The community reached what
> > appeared to me as fairly strong consensus that we just couldn't
> > do it.  Part of the problem was that, at the time 821 was
> > written (and maybe as late as the time of DRUMS) there were
> > still systems around that operated upper-case-only and had only
> > the vaguest idea what lower case was.  Another part was that
> > Unix (and Multics) and some of their successors were very
> > case-sensitive in general: "foo" and "Foo" and "foO" were
> > unambiguously three different names.
> >
> > Because of that history and consensus, the strong suggestions in
> > 5321 are about as far as one is going to get as far as
> > restrictions/ recommendations on the mailbox names themselves
> > and the "don't try to guess" rule probably isn't going anywhere.
> >
> > In retrospect, we dodged a bullet because, for mailbox local
> > parts, ARNE does not, in terms of anything a sender is allowed
> > to predict, match arne.  That BL?B?R doesn't match bl?b?r
> > may still be a surprise to some, but it is not more or a
> > surprise.
> >
> > >From that perspective, the problem facing DANE is that either
> > the basic "if they are not identical, they don't match" rules is
> > applied or there is a need to invent rules different from the
> > email rules and that de facto modify the email rules by
> > restricting the syntax of a mailbox if there is any possibility
> > a DANE DNS record will be used with it.  Nothing I'm aware of
> > (other than probably the WG Charter) prohibits DANE from
> > proposing an update to 5321 and 6530ff, but the history (and
> > probable side-effects that no one has tried to analyze) predicts
> > that the idea won't easily get community consensus.
>
> Yep. I'm sympathetic to the quandary of DANE.
>
> Our strong advice was basically "if you (the recipient's mailbox
> manager) depend on case  differences to tell mailboxes apart, you are a
> fool; if you (the sender) depend on case not mattering, you are a bigger
> fool."
>
> DANE is an algorithm for the *sender* to look up information about the
> *recipient*'s mailbox in the DNS, which means that the whole experiment
> depends on the sender (who has no idea of what or where the recipient
> is) being able to construct exactly the same hash that is generated by
> the recipient - incompatible with the two pieces of advice I have
> abstracted out above.
>
> A possible way out (strawman!!!!) would be to say:
>
> - All recipient participants in the experiment MUST agree to ignore case
> differences in mailbox names. This has no effect on non-participants, so
> we can possibly get consensus for that.
>
> - All code in the experiment MUST use a particular algorithm to generate
> the LHS lookup key
> (I would suggest toLowerCase(NFC(string) in the C locale) off the top of
> my head - but one could also argue for caseFold(NFC(string)) or
> NFC(caseFold(string)) - and the people choosing had better know the
> difference)
>
> The case operations referenced are in Unicode 8.0.0 section 5.18 - I
> *strongly* recommend actually reading that chapter, and not making the
> (invalid) assumption that calling toLower() in some random library will
> actually do something compatible with this.
>
> I don't think anything less precise has a chance of being interoperable.
>
> 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.
>
> Replacing "and then" with ". The string is then" would fix the problem.
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>
>
> ------------------------------
>
> End of ietf Digest, Vol 93, Issue 59
> ************************************
>

---

From: Zack Cylinder <[email-masked]>
Date: Tue, 16 Feb 2016 10:39:23 -0800

Great! Sounds good!

Zack Cylinder

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 16 Feb 2016 21:19:21 +0100

Hello Zack,

You are responding to a DIGEST.

Which of the six messages are you answering?

BR Huub.

Great! Sounds good!

Zack Cylinder

Cloudbakers.com

On Mon, Feb 15, 2016 at 9:46 AM, <[email-masked]>
wrote:

Send ietf
mailing list submissions to

[email-masked]

[email-masked]

[email-masked]

When replying, please edit your Subject line so it is more
specific

Today's Topics:

1. Re: Is Fragmentation at IP layer even needed ? (Joe
Touch)

2. Re: Is Fragmentation at IP layer even needed ?
(Masataka Ohta)

3. Re: Last Call:
<draft-ietf-dane-openpgpkey-07.txt> (E Taylor)

4. Re: Last Call:
<draft-ietf-dane-openpgpkey-07.txt>

(Harald Alvestrand)

5. Re: Last Call:
<draft-ietf-dane-openpgpkey-07.txt>

(John C Klensin)

6. Re: Last Call:
<draft-ietf-dane-openpgpkey-07.txt>

(Harald Alvestrand)

Message: 1

To: Masataka Ohta <[email-masked]>,
[email-masked]

Joe

Message: 2

There are not.

Can you read this?

that is your problem.

Masataka
Ohta

Message: 3

To: John C Klensin <[email-masked]>,
[email-masked]

Subject: Re: Last Call:
<draft-ietf-dane-openpgpkey-07.txt>

Hello,

Thank you, John, for your detailed comments on the i18n
aspect of this

draft, which I admit I hadn't fully considered.  I think
you're right

that, whatever approach is taken, it would make sense to add
a short

"Internationalization Considerations" section to state what
the expected

interaction is between this specification and non-ASCII
addresses.

> specifically do you think the spec should recommend?

I have not seen any specific examples of software which
unintentionally

converts characters to uppercase (although I can readily
imagine such

bugs/features), so I'm prepared to assume that the
lowercasing logic can

be safely limited to just the input strings which include
only ASCII

characters.  My idea was for the client to make a reasonable
effort to

correct for a plausible (but rare) problem, so for the
purposes of an

experiment I think it is acceptable if this correction does
not try

anything more clever, like converting [email-masked]
to

mustafa.ak?nc?@example.com
(although [email-masked]
should

be tried).

> that, with a different problem case, below).

You are right that adding such a section could be of great
benefit to at

least some implementers, even if the discussion in that
section is

simply "Only try lower-casing when the input is all ASCII".
If someone

can come up with something more helpful than that brief
statement, then

>       dropping the references to RFC 6530 and friends).

Perhaps you would settle for an option (ii.v) which is my
lowercasing

recommendation + a discussion of the i18n issues + that
discussion being

based on the experimental restriction of only applying the
lowercasing

logic to ASCII-only local parts.  I hope that would be in
keeping with

> recommend trying first one of those and then the other
[3]?

That is tempting, but I accept that it may be too much
unnecessary

complexity to suggest or recommend it at this stage of the
experiment.

I know that various ideas have been proposed for handling
normalisation

of local-parts more generally, and I think we should allow
that work to

progress separately, uncoupling it from the document at
hand.

> commitment to diversity are considered.

I think that excluding non-ASCII local-parts from just the
extra

lower-casing logic, and pointing out the complexity of case
handling in

non-ASCII contexts in a separate section as you have
suggested, might

address the outstanding concerns, without hindering
diversity.

> repertoire is truly impressive.

That's another reasonable point, thank you.  Hopefully it is
mitigated,

at least for the most part, by settling for only
lower-casing characters

for all-ASCII local-parts, avoiding the combinatorial
explosion you

mention.  Also, this extra lower-casing step will only
happen in the

relatively rare situations where the input local-part
contains at least

one upper-case character (although I don't know in practice
how many

Best regards,

Edwin

Message: 4

To: [email-masked]

Subject: Re: Last Call:
<draft-ietf-dane-openpgpkey-07.txt>

> mustafa.ak?nc?@example.com
(although [email-masked]
should

it's all

ASCII" is zero.

user from an

extended-ASCII country (which is *all* Latin script using
countries,

even though the non-ASCII variants in English are rarely
used) will be

mighty confused.

Message: 5

To: Harald Alvestrand <[email-masked]>,
[email-masked]

Subject: Re: Last Call:
<draft-ietf-dane-openpgpkey-07.txt>

--On Monday, February 15, 2016 4:33 PM +0100 Harald
Alvestrand

<[email-masked]>

Indeed.

However, that is exactly the decision we made with IDNA
(both

not...  The idea of requiring that mailbox names be treated
as

all lower case was discussed during the work leading up to
RFC

1123 and again in DRUMS (pre-2821).  The community reached
what

appeared to me as fairly strong consensus that we just
couldn't

still systems around that operated upper-case-only and had
only

Because of that history and consensus, the strong
suggestions in

restrictions/ recommendations on the mailbox names
themselves

and the "don't try to guess" rule probably isn't going
anywhere.

parts, ARNE does not, in terms of anything a sender is
allowed

surprise.

>From that perspective, the problem facing DANE is that
either

the basic "if they are not identical, they don't match"
rules is

applied or there is a need to invent rules different from
the

restricting the syntax of a mailbox if there is any
possibility

a DANE DNS record will be used with it.  Nothing I'm aware
of

probable side-effects that no one has tried to analyze)
predicts

john

Message: 6

To: [email-masked]

Subject: Re: Last Call:
<draft-ietf-dane-openpgpkey-07.txt>

On 02/15/2016 05:46 PM, John C Klensin wrote:

Our strong advice was basically "if you (the recipient's
mailbox

manager) depend on case  differences to tell mailboxes
apart, you are a

fool; if you (the sender) depend on case not mattering, you
are a bigger

fool."

DANE is an algorithm for the *sender* to look up information
about the

*recipient*'s mailbox in the DNS, which means that the whole
experiment

depends on the sender (who has no idea of what or where the
recipient

is) being able to construct exactly the same hash that is
generated by

the recipient - incompatible with the two pieces of advice I
have

abstracted out above.

- All recipient participants in the experiment MUST agree to
ignore case

differences in mailbox names. This has no effect on
non-participants, so

- All code in the experiment MUST use a particular algorithm
to generate

the LHS lookup key

(I would suggest toLowerCase(NFC(string) in the C locale)
off the top of

my head - but one could also argue for caseFold(NFC(string))
or

NFC(caseFold(string)) - and the people choosing had better
know the

difference)

The case operations referenced are in Unicode 8.0.0 section
5.18 - I

*strongly* recommend actually reading that chapter, and not
making the

(invalid) assumption that calling toLower() in some random
library will

I don't think anything less precise has a chance of being
interoperable.

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

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

Replacing "and then" with ". The string is then" would fix
the problem.

Subject: Digest Footer

ietf mailing list

[email-masked]

--
*****************************************************************
请记住，你是独一无二的，就像其他每一个人一样

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 16 Feb 2016 23:02:44 +0100

Please ignore my previous message.

BR, Huub.

---

From: Zack Cylinder <[email-masked]>
Date: Fri, 19 Feb 2016 09:29:39 -0800

Hi everyone,

Please disregard.

Zack Cylinder

---

From: Zack Cylinder <[email-masked]>
Date: Fri, 19 Feb 2016 09:29:39 -0800

Hi everyone,

Please disregard.

Zack Cylinder