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