On Tue, Mar 17, 2015 at 8:23 AM, Alessandro Vesely <[email protected]> wrote:
> > Right, which is why things like semi-colon don't need to be > > percent-encoded; they're already special characters in the context of a > URL. > > So are comma and exclamation. What puzzles me is that DMARC spec treats > them > differently while RFC3896 does not. Comma and semicolon seem to behave the > same; e.g.: > Ah, that's true. I was looking specifically at one and not all three. At this point, since RFC7489 has just been published, I suggest you choose (perhaps with direction from the co-chairs) how to record this discrepancy for handling when the base draft gets updated. You could open an erratum report, or you could add it to the WG's tracker, or maybe they have another suggestion. > > They aren't formally imported, and I'm not sure that's necessary here. > The > > ABNF we have should be comprehensive over DMARC tag-value sets. The > prose > > you cited is merely meant to convey that they follow the same style. > > Right. The question is if implementations can reuse DKIM parsers. > Without studying the ABNF again, I believe so. DKIM parsers separate tag-value entities at unencoded semicolons, after which the tag name and tag value are separated at unencoded equal signs. DMARC records are the same up to that point, and it's below there for "ruf" and "rua" in the DMARC case that things get interesting. Just like in the case of "b=" for DKIM, those two have special rules for value interpretation: make up a list of URIs using an unencoded comma as the separator. > > Your question is "Are they equivalent?" I believe they are. Although it > > might be ideal to have a specification so tight that there's exactly one > > way to do something, in the end I don't think it's harmful to have two > ways > > to say the same thing. It's more of a concern if there's to ways to > > interpret a single thing; that's when we arguably have something to fix. > > I tried the "NOT RECOMMENDED" syntax quoted above. Dmarcian[1] doesn't > raise a > brow, and RFC3896-compliant uriparser[2] ingests it smoothly. However, > although I sent a test message to a gmail account, I received no report. I > guess Google's implementation doesn't deploy a proper URI parser, but just > looks for "mailto:"; followed by a plain path consisting of a single[3] > addr-spec (as defined in RFC6068, i.e. w/o comments) with no query nor > fragment > --that's what I'd do myself, but I find no arguments in the spec that help > proving that that record is bad. > I think we've wandered into implementation comparisons rather than getting the ABNF right in the specification. Or maybe a better way to say that is: I don't think fixing the discrepancy you've raised would resolve the disparity you're observing. > The spec says a report "is normally sent to each". How can a publisher > express > that two URIs are meant to be either-or alternatives to each other? > Is that a capability you require? I don't think that's a use case I've ever encountered. > It may also be worth to require domain in addr-spec to be A-label, as that > simplifies verification and improves dn_ compression. Such idea apparently > conflicts with the example at the end of Section 6.3 of RFC6068, where the > IDN > is percent-encoded instead. > That is a completely different topic, something that should be taken up when we do a standards track version. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
