> -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of John Levine > Sent: Wednesday, November 30, 2011 6:04 PM > To: ietf@xxxxxxxx > Subject: Re: Last Call: <draft-kucherawy-dkim-atps-11.txt> (DKIM Authorized Third-Party Signers) to Experimental RFC > > I'm one of the authors of RFC 5617, which this document would update if > it moved into the standards track. It doesn't seem very useful to me, > but it also seems mostly harmless so there's no reason not to publish > it as experimental. > > This strikes me a hack that appeals primarily to bulk mail senders who > grossly overestimate how interested receivers are in helping them do > their mail management. So I would be surprised if there were many > receiver-side implementations, but it's an experiment so what the heck. As the draft says, the point is to make the idea available and see if it sticks to anyone or anything. If the bulk senders (or receivers) do decide they collectively want this, there's something for them to try and report back. > > "No actions are required by IANA at this time. The following need > > only be applied if and when this specification reaches the Standards > > Track." > > I would strongly suggest changing the IANA section so that the DKIM- > Signature tags in section 8.4 are registered when this is published. > Tags are text strings, and I'd rather the tags it uses be noted and > reserved so that nobody uses them for something else in the future and > risks collisions. For the same reason, it'd probably be a good idea to > register the authentication-results tags described in sections 8.2 and > 8.3. I'd be fine with that, so long as experimental-status drafts are allowed to make IANA registrations. (I thought they weren't, which is why it is the way it is right now.) Thanks, -MSK _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf