Subject: [dmarc-ietf] AD review of draft-ietf-dmarc-rfc7601bis-03.txt

From: Alexey Melnikov <[email-masked]>
Date: Thu, 25 Oct 2018 12:03:02 +0100

Hi,

I've started IETF LC on the document, as my comments are really minor:

1) I am not sure that deleted IANA registry descriptions (when compared 
to RFC 7601) is the best way, considering that this document obsoletes 
RFC 7601. I think it would be better to just keep the text and add a 
sentence saying that it is unchanged from RFC 7601. But I am happy to 
hear what IESG has to say about this.

2) The following took really long time to verify for correctness:

Section 2.5 says about authserv-id:

   Note that in an EAI-formatted message, this identifier may be
         expressed in UTF-8.

So I decided to check whether this statement is actually true.
authserv-id is defined in Section 2.2 as:

   authserv-id = value

   "value" is as defined in Section 5.1 of [MIME].

Section 5.1 of RFC 2045:

    value := token / quoted-string

"token" doesn't allow UTF-8 (I think), but quoted-strings does, if 
updated by RFC 6532.

So, can I suggest that in Section 2.2, the following clarification is made:

OLD:

"value" is as defined in Section 5.1 of [MIME].

NEW:

"value" is as defined in Section 5.1 of [MIME], with "quoted-string" 
updated as specified in RFC 6532.

Best Regards,

Alexey

---

From: Brandon Long <[email-masked]>
Date: Fri, 26 Oct 2018 17:33:27 -0700

should authserv-id bet a dot-atom instead?  That seems to be the main uses
I see, as a domain, and that would allow UTF-8.

I don't know how bad that is compared to a token, and clearly that doesn't
allow a quoted-string, so I guess it would likely need to be
authserv-id = dot-atom-text / quoted-string

except that dot-atom-text isn't the same as token.. it allows "?" / "=" /
in particular, and I guess atext doesn't allow . on the ends ...
= could be problematic with some parsers given the prevalence of = in the
rest of the header.

I guess the alternative is to define a utf8-token that was VCHAR instead,
ie:

utf8-token := 1*<VCHAR except SPACE, CTLs, or tspecials>

with VCHAR updated by rfc 6532 to allow utf-8.

Or do we say that rfc 2045 should have been updated to VCHAR?  Probably a
bit annoying to do that.

Brandon

On Thu, Oct 25, 2018 at 4:03 AM Alexey Melnikov <[email-masked]>
wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "John Levine" <[email-masked]>
Date: 27 Oct 2018 12:20:32 -0400

>So I decided to check whether this statement is actually true.

Oops.

>updated as specified in RFC 6532.

That seems the smallest adequate fix.  In general EAI allows UTF-8 in
fields that humans look at, but not ones just for computers like
message-IDs.  The alternative would be to leave the old text and add a
note that says in the common case that the identifier is a domain
name, IDNs are represented as A-labels.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 30 Oct 2018 18:52:57 +0100

On Sat 27/Oct/2018 02:33:27 +0200 Brandon Long wrote:

> should authserv-id bet a dot-atom instead?  That seems to be the main uses I
> see, as a domain, and that would allow UTF-8.

That was also discussed at the time of rfc5451bis:
https://www.ietf.org/mail-archive/web/apps-discuss/current/msg09122.html

Best
Ale
--