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

[Zack Cylinder <[e-mail]>]

Great! Sounds good!

Zack Cylinder
Cloud Training Specialist
Cloudbakers.com


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

> Send ietf mailing list submissions to
>         [e-mail]
>
> 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
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> 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 <[e-mail]>
> To: Masataka Ohta <[e-mail]>, [e-mail]
> Subject: Re: Is Fragmentation at IP layer even needed ?
> Message-ID: <[e-mail]>
> 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 <[e-mail]>
> To: Joe Touch <[e-mail]>, [e-mail]
> Subject: Re: Is Fragmentation at IP layer even needed ?
> Message-ID: <[e-mail]>
> 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 <[e-mail]>
> To: John C Klensin <[e-mail]>, [e-mail]
> Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
> Message-ID: <[e-mail]>
> 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 [e-mail] to
> mustafa.ak?nc?@example.com (although [e-mail] 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 <[e-mail]>
> To: [e-mail]
> Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
> Message-ID: <[e-mail]>
> 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 [e-mail] to
> > mustafa.ak?nc?@example.com (although [e-mail] 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 <[e-mail]>
> To: Harald Alvestrand <[e-mail]>, [e-mail]
> Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=utf-8
>
>
>
> --On Monday, February 15, 2016 4:33 PM +0100 Harald Alvestrand
> <[e-mail]> 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 <[e-mail]>
> To: [e-mail]
> Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
> Message-ID: <[e-mail]>
> 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
> > <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>
>
> ------------------------------
>
> End of ietf Digest, Vol 93, Issue 59
> ************************************
>