Signaling One-Click Functionality for List Email Headers
RFC 8058

Note: This ballot was opened for revision 07 and is now closed.

(Alexey Melnikov) Yes

Comment (2016-11-30 for -09)
No email
send info
Regarding JSON versa other formats question that came up during IETF LC: I believe this is an implementation preference and not everyone wants to have a JSON parser on the server side.

Similarly about what is exactly returned in the form-data.

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2016-11-30 for -09)
No email
send info
Thanks for addressing my comments

(Benoît Claise) No Objection

Alissa Cooper No Objection

Comment (2016-11-30 for -09)
No email
send info
I agree with Stephen that either the SHOULD NOT send cookies, etc. bit should be changed to MUST NOT or the exceptional circumstances under which it's ok to send them need to be listed. I don't get what those exceptions would be.

(Spencer Dawkins) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2016-11-07 for -08)
No email
send info
Thanks for the changes from -07 to -08 which are good 
enough to resolve my discuss points. 

I note you say that cookies etc SHOULD NOT be sent,
whereas I'd argue for MUST NOT. If you want to leave
that at SHOULD NOT then please do add the logic for
when/why it is ok to send state information (which I 
guess is to handle some kind of intranet/internal list 
use cases is it?)

-- OLD DISCUSS BELOW

I have two discuss points, both much more of interest if
this spec is implemented within an MUA, which is not the
use-case that the authors are (very reasonably) mainly
interested in handling.

(1) This needs to say to never send client state (cookies
etc.) esp for the case the client is an MUA.

(2) The ability to cause the POST to match such a broad
range of web forms seems wrong. Surely there's no need for
that? Can't you limit the set of post data that are
allowed to be emitted in some way to get rid of that
aspect? I can't imagine such flexibility is really needed
for just this.

-- OLD COMMENTS BELOW

- I'm not clear whether or not changes discussed in the
secdir review [1] are all reflected in the current draft.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06783.html

- I think it might be useful to more clearly state where
you really intend for this to be implemented, which iiuc
is within a webmail server. 

- Intro: Why no mention of http schemed URLs? Wouldn't it
be a good idea to at least say these SHOULD/MUST NOT be
used?

- Section 4: The 2nd para there means that the http client
MUST NOT send the POST message unless the DKIM
signature is valid.  If that's correct (and I hope it is)
then might it be good to be more explicit about that? The
current wording doesn't tie the signature validation so
clearly to the action being (dis)allowed I think. (If
someone has implemented this based on just the I-D and
gotten this correct, then a change is probably not
needed.) I wonder if implementations will easily be able
to still check the DKIM signature status when sending the
http POST message, but I'll believe you if you tell me
that's ok.

(Joel Jaeggli) No Objection

Comment (2016-10-26 for -07)
No email
send info
Victor Kuarsingh <victor@jvknet.com> performed the opsdir review

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2016-10-26 for -07)
No email
send info
I support Stephen's discuss points and also did not find any changes that resulted from the SecDir review.

Thanks.

Alvaro Retana No Objection