Subject: Re: [http-state] http-state Digest, Vol 13, Issue 4

From: eric bianchetti <[email-masked]>
Date: Tue, 11 May 2010 19:13:19 -0700 (PDT)

Hello,

Maybe it's because my level of english; but to me both of the following sentences are contradicting (if a server SHOULD NOT do soemthing, why then speak of what might happend if they do that thing?) : 

4.1.1.  Syntax
.....
 
Servers SHOULD NOT include two Set-Cookie header fields in the same
   response with the same cookie-name.

.....
 
If a server sends multiple responses containing Set-Cookie headers
   concurrently to the user agent (e.g., when communicating with the
   user agent over multiple sockets), these responses create a "race
   condition" that can lead to unpredictable behavior.

My opinion (as not english native) is a reformulation, or even the suppression of the second sentence , would give more clarity.
 
Best regards

----- Original Message ----
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Sent: Wed, May 12, 2010 2:00:13 AM
Subject: http-state Digest, Vol 13, Issue 4

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/http-state

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send http-state mailing list submissions to
    mailto:[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
    https://www.ietf.org/mailman/listinfo/http-state
or, via email, send a message with subject or body 'help' to
    mailto:[email-masked]

You can reach the person managing the list at
    mailto:[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of http-state digest..."

Today's Topics:

  1. Initiating WG Last Call: draft-ietf-httpstate-cookie-08 (=JeffH)

----------------------------------------------------------------------

Message: 1
Date: Tue, 11 May 2010 09:21:29 -0700
From: =JeffH <[email-masked]>
Subject: [http-state] Initiating WG Last Call:
    draft-ietf-httpstate-cookie-08
To: IETF HTTP State WG <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

The purpose of this message is to initiate an HTTPSTATE
Working Group Last Call on the "HTTP State Management
Mechanism" Internet Draft.

WHAT DOCUMENT?

The document in last call is:

  draft-ietf-httpstate-cookie-08

  <http://www.ietf.org/id/draft-ietf-httpstate-cookie-08.txt>

  <http://tools.ietf.org/html/draft-ietf-httpstate-cookie-08>

  Issue tracker at:

  <http://trac.tools.ietf.org/wg/httpstate/trac/query?component=cookie>

WHAT IS A LAST CALL FOR?

The purpose of the Working Group Last Call (WGLC) is to
ensure that the working group has reached consensus on the
document, believes that all the known outstanding issues
have been addressed, and is ready to put the document
forward for consideration as an RFC at Proposed Standard
maturity level.

During the last call, any comments on the documents are
collected and discussed on the [email-masked]
mailing list.

HOW LONG DOES IT LAST?

The last call starts today and will last approximately
three weeks. It will end on Monday, 31-May-2010 2359h PDT
(UTC: Tuesday, June 1, 2010 at 0659h).

WHAT'S THE NEXT STEP?

After the last call completes, there are three possible
outcomes:

1) No changes are required and we request our ADs to put
forward the document to the IESG for proposed standard
status.

2) Minor changes agreed to on the list are required, and
the document is revised. We then ask our ADs to put
forward the revised document to the IESG for proposed
standard status.

3) Major issues are raised and no consensus is reached on
the list. In this case, we slink back and discuss things
until consensus is reached, at which time another working
group last call will be issued.

Assuming we achieve outcome 1) or 2), and that the ADs
agree with our assessment, the next stop for the document
is with the IESG. The IESG reads it and may approve the
documents (with or without changes), or send the document
back to the working group to have major issues addressed.

If the first outcome happens, the document is put forward
for a two-week IETF-wide Last Call, and after successful
completion the document is published as an RFC at proposed
standard maturity level.

If the second outcome happens, we go back and address
the issues, putting the document forward again when we
believe we're ready.

WHAT SHOULD I DO?

You should read the document, making sure that 1) there
are no problems or deficiencies or outstanding issues that
need to be resolved; and 2) that there are no typos,
formatting problems, grammatical errors, etc.

Any substantive problems you find, you should send to the
list. Any minor problems (typos, etc.) you may send to the
list or just to the authors. If, for some reason, you have
comments you don't want to send to the entire list, you may
send them to me.

Read, enjoy, and send your comments in!

------------------------------

_______________________________________________
http-state mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/http-state

End of http-state Digest, Vol 13, Issue 4
*****************************************

---

From: Adam Barth <[email-masked]>
Date: Tue, 11 May 2010 19:16:46 -0700

Sometimes people do things they shouldn't...

You might find http://www.ietf.org/rfc/rfc2119.txt helpful.

Adam