Signaling One-Click Functionality for List Email Headers
draft-levine-herkula-oneclick-10

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.

Thanks for addressing my comments

Victor Kuarsingh <victor@jvknet.com> performed the opsdir review

I support Stephen's discuss points and also did not find any changes that resulted from the SecDir review.

Thanks.

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.