Douglas Otis wrote:
Changing a reference of RFC3490 to RFC5890 already represents an
incompatible change.
Your assertion is noted.
John, it is correct to reference RFC5890 but for any implementations
that currently have RFC3490 support there is a conflict verifiers need
to be aware of. A
On 4/20/11 5:02 PM, John R. Levine wrote:
Internationalized domain names MUST be encoded as Non-Reserved LDH,
A-Labels as described in RFC5891, or equivalent U-Labels.
Repeating this bad idea doesn't make it a good idea,
Besides being a bad idea on its own merits, this would without question
On 21/Apr/11 14:25, John R. Levine wrote:
Use of A-labels within header fields supporting UTF-8 is a bad idea.
Since DKIM is defined on RFC 5322 messages, and 5322 is ASCII-only, no
header fields in a compliant message can contain UTF-8.
It would be surprising if DKIM supported UTF-8 in the
On 4/21/11 5:25 AM, John R. Levine wrote:
Use of A-labels within header fields supporting UTF-8 is a bad idea.
Since DKIM is defined on RFC 5322 messages, and 5322 is ASCII-only, no
header fields in a compliant message can contain UTF-8. I don't know
why you keep repeating this uttetly
While the majority of users within your borough may not care, a large
population within Asia and elsewhere do. In fact, much of their email
already violates RFC5322's ASCII-only requirements.
I have trouble reading this as other than we're going to leapfrog
everything that EAI is doing in
Murray S. Kucherawy wrote:
Oops, this is a separate issue. But I hope it's also not
contentious.
[...]
Since I'm not exactly an EAI/IDNA expert...
The only thing that's not obvious to me is whether the hash functions
should hash the bytes of the UTF-8, or convert them to UTF wide
On Wed, 20 Apr 2011 09:24:26 +0100, Hector Santos hsan...@isdg.net wrote:
Murray S. Kucherawy wrote:
Oops, this is a separate issue. But I hope it's also not
contentious.
[...]
Since I'm not exactly an EAI/IDNA expert...
The only thing that's not obvious to me is whether the hash
The only thing that's not obvious to me is whether the hash functions
should hash the bytes of the UTF-8, or convert them to UTF wide
characters and hash those. Depending on the way the MTA is written,
either might seem more natural, but I'm inclined to say you hash the
UTF-8 bytes because
Is there anything that actually needs to be done with a UTF-8 header that
is not covered already in our DKIm spec.?
No, it's fine, so long as we make my proposed changes that clarify that
the bits of domain names in the DKIM-Signature: header (d= i= s=) are
represented as A-labels.
Regards,
Charles Lindsey wrote:
Murray,
I viewed this as another layer issue. Adding a DKIM-Signature: header
is no different than any other RFC5322 header where UTF8 conversion is
already a consideration. But maybe to provide guidance for what parts
of the DKIM-Signature RFC5322 header needs to be
On 4/20/11 7:09 AM, John R. Levine wrote:
Is there anything that actually needs to be done with a UTF-8 header that
is not covered already in our DKIm spec.?
No, it's fine, so long as we make my proposed changes that clarify that
the bits of domain names in the DKIM-Signature: header (d= i=
Internationalized domain names MUST be encoded as Non-Reserved LDH,
A-Labels as described in RFC5891, or equivalent U-Labels.
Repeating this bad idea doesn't make it a good idea,
Besides being a bad idea on its own merits, this would without question
require us to recyle at proposed standard.
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of John Levine
Sent: Tuesday, April 12, 2011 11:32 PM
To: ietf-dkim@mipassoc.org
Subject: [ietf-dkim] ISSUE: non-ascii header text
Oops, this is a separate issue. But I hope
Oops, this is a separate issue. But I hope it's also not
contentious.
3.5, d= and i= tags: references to RFC3490 should be RFC5890. The
reference to ToASCII() should go, or else in both places say IDNs are
represented as A-labels.
Suggested new language under d= on page 22:
Change:
Oh, one other thing:
3.5, s= tag. Since the selector is components of a domain name, they can
also be IDNs, so on page 26, between the sentence describing s= and the ABNF:
Add: Internationalized domain names MUST be represented as A-labels
as described in [RFC5890].
Regards,
John
I'm generally in favor of updating the document to match the current state of
IDN and EAI work, but I don't know it well enough to comment intelligently on
whether John's proposed text does so.
What John has looks right to me, and is consistent with earlier advice
from John Klensin and with
On 4/13/2011 10:31 AM, J.D. Falk wrote:
I'm generally in favor of updating the document to match the current state of
IDN and EAI work, but I don't know it well enough to comment intelligently on
whether John's proposed text does so.
as phrased, I'll disagree with this.
one spec should
one spec should not try to track fluid developments of other specs. it
should cite stable specs, and preferably ones that have gained adoption.
Agreed. That's why I only cited 5890.
The other comments were basically saying that as far as I can tell, once
we take out the reference to 2047
On Apr 13, 2011, at 12:07 PM, Dave CROCKER wrote:
On 4/13/2011 10:31 AM, J.D. Falk wrote:
I'm generally in favor of updating the document to match the current state
of IDN and EAI work, but I don't know it well enough to comment
intelligently on whether John's proposed text does so.
as
Dave CROCKER wrote:
On 4/13/2011 10:31 AM, J.D. Falk wrote:
I'm generally in favor of updating the document to match the current state
of IDN and EAI work, but I don't know it well enough to comment
intelligently on whether John's proposed text does so.
as phrased, I'll disagree with
20 matches
Mail list logo
