Re: Last Call: <draft-levine-herkula-oneclick-04.txt> (Signalling one-click functionality for list email headers) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



John,

On 9/18/2016 5:15 PM, John R Levine wrote:
Here's the XML.  Feel free to rewrite it (really), keeping in mind that
the bits on the wire are already cast in concrete.

oh.  well, that would make the IETF process a very pure example of a
rubber stamp, which it has historically been quite vigorous in
refusing to be.

I probably shouldn't try and answer mail when dinner is burning on the
stove.  Sigh.

In any event, where you see a rubber stamp (and I could swear that
someone with a name similar to yours was part of the group that dropped
DMARC on the IETF), I see a question of whether the IETF has defined
itself into irrelevance.

That you think the two situations are equivalent is broken at a very basic level.


I don't remember whether you were at the MAAWG in Philadelphia, but when
I was there I stumbled upon a conversation with Tobias and Sri from
Gmail et al, who were ready to implement a truly dreadful design for
one-click, using magic fragment identifiers in http GETs.  I stuck in my
oar, explained why POST would be semantically better and no harder to
code, and then ran off to fix Tobias' design, which is where this draft
comes from.

Gmail and AOL and probably all the other large mail systems are going to
implement this whether or not it has an IETF stamp on it.  I'd rather it
be documented so people outside the MAAWG club can interoperate, too,
and I think that's more important than whatever tiny tweaks might make
it more IETF-ishly optimal.  What do you think?

First, you appear to be thinking that I don't like the proposal, but my review didn't criticize the intent or basic approach. I took issue with some of the details and some of the writing. I made suggestions where I could.

I note that you have not yet responded to the very specific technical concerns I raised.

Given the tone and language of your responses, I then took issue with your stated inflexibility.

A 'take it or leave it' stance with existing work being handed to the IETF qualifies the work for non-standards track status.[*] So publish the thing as Independent Stream and Informational.

The premise behind IETF standards track is that the work is subject to IETF community input. Your comments have taken a position against incorporating that input.


d/


[*] When existing work has an installed base, then assessing how important it is to preserve that base is part of the acceptance process when the IETF work is chartered. Since there's no working group chartering process here, there's been no discussion about the need for protecting the installed base. Rather, you have simply imposed the requirement by fiat. And as an afterthought, quite late in this very abbreviated process.

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]