draft-ietf-httpbis-p4-conditional-09.txt   draft-ietf-httpbis-p4-conditional-10.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track One Laptop per Child Intended status: Standards Track Alcatel-Lucent
Expires: September 9, 2010 J. Mogul Expires: January 13, 2011 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
March 8, 2010 July 12, 2010
HTTP/1.1, part 4: Conditional Requests HTTP/1.1, part 4: Conditional Requests
draft-ietf-httpbis-p4-conditional-09 draft-ietf-httpbis-p4-conditional-10
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 4 of the information initiative since 1990. This document is Part 4 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines
request header fields for indicating conditional requests and the request header fields for indicating conditional requests and the
rules for constructing responses to those requests. rules for constructing responses to those requests.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.10. The changes in this draft are summarized in Appendix C.11.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 13, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2. ABNF Rules defined in other Parts of the 1.2.2. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 5 Specification . . . . . . . . . . . . . . . . . . . . 5
2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 6 2.1. Example: Entity Tags varying on Content-Negotiated
3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 6 Resources . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7
4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 7 3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 7
5. Rules for When to Use Entity Tags and Last-Modified Dates . . 9 3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 8
6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11 4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 8
6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Rules for When to Use Entity Tags and Last-Modified Dates . . 11
6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 12
6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13 6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15 6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16 6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 14
6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 17 6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17
7.1. Status Code Registration . . . . . . . . . . . . . . . . . 17 6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Message Header Registration . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7.1. Status Code Registration . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 7.2. Message Header Registration . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Compatibility with Previous Versions . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 20 Appendix A. Compatibility with Previous Versions . . . . . . . . 20
A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 21
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 20 publication) . . . . . . . . . . . . . . . . . . . . 21
C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 20 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21
C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 21 C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 22
C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 21 C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 22
C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 21 C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 22
C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 21 C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 22
C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 22 C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 23
C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 22 C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 23
C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 22 C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 23
C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 22 C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 23
C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 22 C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 23
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
This document defines HTTP/1.1 response metadata for indicating This document defines HTTP/1.1 response metadata for indicating
potential changes to payload content, including modification time potential changes to payload content, including modification time
stamps and opaque entity-tags, and the HTTP conditional request stamps and opaque entity-tags, and the HTTP conditional request
mechanisms that allow preconditions to be placed on a request method. mechanisms that allow preconditions to be placed on a request method.
Conditional GET requests allow for efficient cache updates. Other Conditional GET requests allow for efficient cache updates. Other
conditional request methods are used to protect against overwriting conditional request methods are used to protect against overwriting
or misunderstanding the state of a resource that has been changed or misunderstanding the state of a resource that has been changed
skipping to change at page 4, line 35 skipping to change at page 4, line 35
mess reflects how widely dispersed these topics and associated mess reflects how widely dispersed these topics and associated
requirements had become in [RFC2616]. requirements had become in [RFC2616].
1.1. Requirements 1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or more An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocols it of the "MUST" or "REQUIRED" level requirements for the protocols it
implements. An implementation that satisfies all the MUST or implements. An implementation that satisfies all the "MUST" or
REQUIRED level and all the SHOULD level requirements for its "REQUIRED" level and all the "SHOULD" level requirements for its
protocols is said to be "unconditionally compliant"; one that protocols is said to be "unconditionally compliant"; one that
satisfies all the MUST level requirements but not all the SHOULD satisfies all the "MUST" level requirements but not all the "SHOULD"
level requirements for its protocols is said to be "conditionally level requirements for its protocols is said to be "conditionally
compliant." compliant".
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the ABNF syntax defined in Section 1.2 of This specification uses the ABNF syntax defined in Section 1.2 of
[Part1] (which extends the syntax defined in [RFC5234] with a list [Part1] (which extends the syntax defined in [RFC5234] with a list
rule). Appendix B shows the collected ABNF, with the list rule rule). Appendix B shows the collected ABNF, with the list rule
expanded. expanded.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
skipping to change at page 6, line 5 skipping to change at page 6, line 5
could be substituted for each other with no significant change in could be substituted for each other with no significant change in
semantics. A weak entity tag can only be used for weak comparison. semantics. A weak entity tag can only be used for weak comparison.
An entity tag MUST be unique across all versions of all entities An entity tag MUST be unique across all versions of all entities
associated with a particular resource. A given entity tag value MAY associated with a particular resource. A given entity tag value MAY
be used for entities obtained by requests on different URIs. The use be used for entities obtained by requests on different URIs. The use
of the same entity tag value in conjunction with entities obtained by of the same entity tag value in conjunction with entities obtained by
requests on different URIs does not imply the equivalence of those requests on different URIs does not imply the equivalence of those
entities. entities.
2.1. Example: Entity Tags varying on Content-Negotiated Resources
Consider a resource that is subject to content negotiation (Section 4
of [Part3]), and where the representations returned upon a GET
request vary based on the Accept-Encoding request header field
(Section 5.3 of [Part3]):
>> Request:
GET /index HTTP/1.1
Host: www.example.com
Accept-Encoding: gzip
In this case, the response may use the gzip Content Coding or not.
If it does, it might look like that:
>> Response:
HTTP/1.1 200 OK
Date: Thu, 26 Mar 2010 00:05:00 GMT
ETag: "123-a"
Content-Length: 70
Vary: Accept-Encoding
Content-Type: text/plain
Hello World!
Hello World!
Hello World!
Hello World!
Hello World!
A variant that does use gzip Content Coding would be:
>> Response:
HTTP/1.1 200 OK
Date: Thu, 26 Mar 2010 00:05:00 GMT
ETag: "123-b"
Content-Length: 43
Vary: Accept-Encoding
Content-Type: text/plain
Content-Encoding: gzip
...binary data...
Note: Content Codings are a property of the response entity, thus
affect the Entity Tag. An alternative are Transfer Codings
(Section 6.2 of [Part1]) which apply only to the transfer of the
message, and thus do not require assigning distinct entity tags.
3. Status Code Definitions 3. Status Code Definitions
3.1. 304 Not Modified 3.1. 304 Not Modified
If the client has performed a conditional GET request and access is If the client has performed a conditional GET request and access is
allowed, but the document has not been modified, the server SHOULD allowed, but the document has not been modified, the server SHOULD
respond with this status code. The 304 response MUST NOT contain a respond with this status code. The 304 response MUST NOT contain a
message-body, and thus is always terminated by the first empty line message-body, and thus is always terminated by the first empty line
after the header fields. after the header fields.
skipping to change at page 18, line 46 skipping to change at page 20, line 5
9. Acknowledgments 9. Acknowledgments
10. References 10. References
10.1. Normative References 10.1. Normative References
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
and Message Parsing", draft-ietf-httpbis-p1-messaging-09 and Message Parsing", draft-ietf-httpbis-p1-messaging-10
(work in progress), March 2010. (work in progress), July 2010.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
and Content Negotiation", draft-ietf-httpbis-p3-payload-10
(work in progress), July 2010.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
Partial Responses", draft-ietf-httpbis-p5-range-09 (work Partial Responses", draft-ietf-httpbis-p5-range-10 (work
in progress), March 2010. in progress), July 2010.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
6: Caching", draft-ietf-httpbis-p6-cache-09 (work in 6: Caching", draft-ietf-httpbis-p6-cache-10 (work in
progress), March 2010. progress), July 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
10.2. Informative References 10.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
skipping to change at page 22, line 48 skipping to change at page 23, line 48
non-GET requests" (If-Match still was defined to require strong non-GET requests" (If-Match still was defined to require strong
matching) matching)
o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
registrations for optional status codes" registrations for optional status codes"
C.10. Since draft-ietf-httpbis-p4-conditional-08 C.10. Since draft-ietf-httpbis-p4-conditional-08
No significant changes. No significant changes.
C.11. Since draft-ietf-httpbis-p4-conditional-09
No significant changes.
Index Index
3 3
304 Not Modified (status code) 6 304 Not Modified (status code) 7
4 4
412 Precondition Failed (status code) 6 412 Precondition Failed (status code) 8
E E
ETag header 11 ETag header 13
G G
Grammar Grammar
entity-tag 5 entity-tag 5
ETag 11 ETag 13
ETag-v 11 ETag-v 13
If-Match 12 If-Match 13
If-Match-v 12 If-Match-v 13
If-Modified-Since 13 If-Modified-Since 15
If-Modified-Since-v 13 If-Modified-Since-v 15
If-None-Match 15 If-None-Match 16
If-None-Match-v 15 If-None-Match-v 16
If-Unmodified-Since 16 If-Unmodified-Since 17
If-Unmodified-Since-v 16 If-Unmodified-Since-v 17
Last-Modified 17 Last-Modified 18
Last-Modified-v 17 Last-Modified-v 18
opaque-tag 5 opaque-tag 5
weak 5 weak 5
H H
Headers Headers
ETag 11 ETag 13
If-Match 12 If-Match 13
If-Modified-Since 13 If-Modified-Since 14
If-None-Match 15 If-None-Match 16
If-Unmodified-Since 16 If-Unmodified-Since 17
Last-Modified 17 Last-Modified 18
I I
If-Match header 12 If-Match header 13
If-Modified-Since header 13 If-Modified-Since header 14
If-None-Match header 15 If-None-Match header 16
If-Unmodified-Since header 16 If-Unmodified-Since header 17
L L
Last-Modified header 17 Last-Modified header 18
S S
Status Codes Status Codes
304 Not Modified 6 304 Not Modified 7
412 Precondition Failed 6 412 Precondition Failed 8
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Day Software Day Software
23 Corporate Plaza DR, Suite 280 23 Corporate Plaza DR, Suite 280
Newport Beach, CA 92660 Newport Beach, CA 92660
USA USA
Phone: +1-949-706-5300 Phone: +1-949-706-5300
Fax: +1-949-706-5305 Fax: +1-949-706-5305
Email: fielding@gbiv.com EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Jim Gettys Jim Gettys
One Laptop per Child Alcatel-Lucent Bell Labs
21 Oak Knoll Road 21 Oak Knoll Road
Carlisle, MA 01741 Carlisle, MA 01741
USA USA
Email: jg@laptop.org EMail: jg@freedesktop.org
URI: http://www.laptop.org/ URI: http://gettys.wordpress.com/
Jeffrey C. Mogul Jeffrey C. Mogul
Hewlett-Packard Company Hewlett-Packard Company
HP Labs, Large Scale Systems Group HP Labs, Large Scale Systems Group
1501 Page Mill Road, MS 1177 1501 Page Mill Road, MS 1177
Palo Alto, CA 94304 Palo Alto, CA 94304
USA USA
Email: JeffMogul@acm.org EMail: JeffMogul@acm.org
Henrik Frystyk Nielsen Henrik Frystyk Nielsen
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Email: henrikn@microsoft.com EMail: henrikn@microsoft.com
Larry Masinter Larry Masinter
Adobe Systems, Incorporated Adobe Systems, Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
Email: LMM@acm.org EMail: LMM@acm.org
URI: http://larry.masinter.net/ URI: http://larry.masinter.net/
Paul J. Leach Paul J. Leach
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Email: paulle@microsoft.com EMail: paulle@microsoft.com
Tim Berners-Lee Tim Berners-Lee
World Wide Web Consortium World Wide Web Consortium
MIT Computer Science and Artificial Intelligence Laboratory MIT Computer Science and Artificial Intelligence Laboratory
The Stata Center, Building 32 The Stata Center, Building 32
32 Vassar Street 32 Vassar Street
Cambridge, MA 02139 Cambridge, MA 02139
USA USA
Email: timbl@w3.org EMail: timbl@w3.org
URI: http://www.w3.org/People/Berners-Lee/ URI: http://www.w3.org/People/Berners-Lee/
Yves Lafon (editor) Yves Lafon (editor)
World Wide Web Consortium World Wide Web Consortium
W3C / ERCIM W3C / ERCIM
2004, rte des Lucioles 2004, rte des Lucioles
Sophia-Antipolis, AM 06902 Sophia-Antipolis, AM 06902
France France
Email: ylafon@w3.org EMail: ylafon@w3.org
URI: http://www.raubacapeu.net/people/yves/ URI: http://www.raubacapeu.net/people/yves/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
Phone: +49 251 2807760 Phone: +49 251 2807760
Fax: +49 251 2807761 Fax: +49 251 2807761
Email: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
 End of changes. 38 change blocks. 
105 lines changed or deleted 161 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/