Hi everyone,
Please disregard.
On Tue, Feb 16, 2016 at 12:19 PM, Huub van Helvoort <huubatwork@xxxxxxxxx> wrote:
Hello Zack,
You are responding to a DIGEST.
Which of the six messages are you answering?
BR Huub.
Great! Sounds good!
On Mon, Feb 15, 2016 at 9:46 AM, <ietf-request@xxxxxxxx> wrote:
Send ietf mailing list submissions to
ietf@xxxxxxxx
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
ietf-request@xxxxxxxx
You can reach the person managing the list at
ietf-owner@xxxxxxxx
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 <touch@xxxxxxx>
To: Masataka Ohta <mohta@xxxxxxxxxxxxxxxxxxxxxxxxxx>, ietf@xxxxxxxx
Subject: Re: Is Fragmentation at IP layer even needed ?
Message-ID: <56C14D50.4040802@xxxxxxx>
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 <mohta@xxxxxxxxxxxxxxxxxxxxxxxxxx>
To: Joe Touch <touch@xxxxxxx>, ietf@xxxxxxxx
Subject: Re: Is Fragmentation at IP layer even needed ?
Message-ID: <56C178EB.1060903@xxxxxxxxxxxxxxxxxxxxxxxxxx>
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 <hagfish@xxxxxxxxxxxx>
To: John C Klensin <john-ietf@xxxxxxx>, ietf@xxxxxxxx
Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
Message-ID: <56C18E14.8060608@xxxxxxxxxxxx>
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 MUSTAFA.AKINCI@xxxxxxxxxxx to
mustafa.ak?nc?@example.com (although mustafa.akinci@xxxxxxxxxxx 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 <harald@xxxxxxxxxxxxx>
To: ietf@xxxxxxxx
Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
Message-ID: <56C1EFE3.4020405@xxxxxxxxxxxxx>
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 MUSTAFA.AKINCI@xxxxxxxxxxx to
> mustafa.ak?nc?@example.com (although mustafa.akinci@xxxxxxxxxxx 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 <john-ietf@xxxxxxx>
To: Harald Alvestrand <harald@xxxxxxxxxxxxx>, ietf@xxxxxxxx
Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
Message-ID: <28459DA6030B0DF750F2CD57@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=utf-8
--On Monday, February 15, 2016 4:33 PM +0100 Harald Alvestrand
<harald@xxxxxxxxxxxxx> 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 <harald@xxxxxxxxxxxxx>
To: ietf@xxxxxxxx
Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
Message-ID: <56C20EE5.4060009@xxxxxxxxxxxxx>
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
> <harald@xxxxxxxxxxxxx> 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
ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
------------------------------
End of ietf Digest, Vol 93, Issue 59
************************************
-- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样