Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol

[Barry Leiba <[e-mail]>]

MNot says...
> As far as I can tell, this document specifies some extensions to the
> Cookie / Set-Cookie (RFC6265), and/or "squats" on some pre-defined
> cookie names. It's hard to tell, both because of how the draft is written,
> and because I read it very quickly.

I don't see any extension there.  I see it using the cookie mechanism
defined in 6265, and specifying how to use encrypted cookies instead
of plain-text ones.

> It seems to me that this *might* therefore conflict with the (previous) HTTPSTATE WG's work.

I have sympathy for that idea, but it doesn't bear out:

The authors proposed it to the httpstate WG on 22 Feb 2011:
http://www.ietf.org/mail-archive/web/http-state/current/msg01227.html

They followed up on 25 Feb and 7 March:
http://www.ietf.org/mail-archive/web/http-state/current/msg01247.html
http://www.ietf.org/mail-archive/web/http-state/current/msg01268.html

On 13 March they tried to get on the agenda for the Prague IETF meeting:
http://www.ietf.org/mail-archive/web/http-state/current/msg01277.html

That didn't happen, and the working group was closed in May 2011,
after the publication of RFC 6265:
http://www.ietf.org/mail-archive/web/http-state/current/msg01317.html

The only responses to any of their messages were two from Adam Barth
in the first (22 Feb) thread.  There appears to have been no interest
in taking on the work in httpstate.

What that says to me is that httpstate had the chance to take it, and
opted out.  It's not valid to now say that they should have, and this
document conflicts.

All that said, here's what I think, as the AD who's shepherding this
through the conflict review:

1. It's probably acceptable to do this through the ISE -- that is,
this probably does not *conflict* with IETF work.

2. It's probably better to do this through the IETF Stream -- it will
get better review and be a more solid document that way.

3. The authors are happy to do it that way; I've talked with them about it.

4. We could charter a new "son of httpstate" working group for this,
we could fit it into an existing working group (httpbis or appsawg,
likely), or we could do it as an AD-sponsored document (I would be
happy to sponsor it, and I suspect Stephen would also).  If we did
that, it would go as Proposed Standard   ... or we could let it
continue through the Independent Stream, as Informational.

Thoughts?

Barry