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

[Dave Crocker <[e-mail]>]

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