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

[Zack Cylinder <[e-mail]>]

Hi everyone,

Please disregard.

Zack Cylinder
Cloud Training Specialist
Cloudbakers.com


On Tue, Feb 16, 2016 at 12:19 PM, Huub van Helvoort <[e-mail]>
wrote:

> Hello Zack,
>
> You are responding to a DIGEST.
>
> Which of the six messages are you answering?
>
> BR Huub.
>
> 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
>> ************************************
>>
>
>
>
> --
> *****************************************************************
>               请记住，你是独一无二的，就像其他每一个人一样
>
>