<meta-aside>Maybe the IETF should create an XML DTD for protocol specs that
hastags for <MUST></MUST>, <ADVICE></ADVICE>, ...</meta-aside>

Due to some clumsiness on my part, some of these diffs got swapped;I've corrected them by hand so that the upper half of each is theversion from the most recent draft, and the lower half is my suggestedchange, with commentary in the format Jeff originated (thanks for
thescript, Jeff). The result is that they are ok for human use,
butdon't try to feed this to 'patch' or anything.

***************** issue MMS_AUDIT_ITEM_130:*** 5146,5152 **** from being used with a media range,
such an event is believed to be unlikely given the lack of any "q"
parameters in the IANA media type registry and the rare usage
of any media type parameters in! Accept. Future media types should be
discouraged from registering any parameter named "q".

The example--- 5146,5152 ---- from being used with a media range,
such an event is believed to be unlikely given the lack of any "q"
parameters in the IANA media type registry and the rare usage
of any media type parameters in! Accept. Future media types are discouraged
from registering any parameter named "q".

The example***************Reason:

Not a protocol requirement; changed to active voice.

---------------** issue MMS_AUDIT_ITEM_131:*** 5198,5207 **** image/jpeg
= 0.5 text/html;level=2
= 0.4 text/html;level=3
= 0.7! Note: A user agent may be provided with
a default set of quality values for certain media ranges.
However, unless the user agent is a closed system which cannot interact
with other rendering agents,! this default set should be configurable
by the user.

14.2 Accept-Charset--- 5198,5207 ---- image/jpeg
= 0.5 text/html;level=2
= 0.4 text/html;level=3
= 0.7! Note: A user agent might be provided
with a default set of quality values for certain media ranges.
However, unless the user agent is a closed system which cannot interact
with other rendering agents,! this default set aught to be configurable
by the user.

! Character set values are described in section 3.4.
Each charset may be given an associated quality value which represents
the user's preference for that charset. The default value is q=1.
An example is

! Character set values are described in section 3.4.
Each charset MAY be given an associated quality value which represents
the user's preference for that charset. The default value is q=1.
An example is

***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_133:*** 5289,5304 **** information that a different content-coding
is meaningful to the client.

Note: If the request does not include
an Accept-Encoding field, and! if the "identity" content-coding is unavailable,
then preference! should be given to content-codings commonly
understood by HTTP/1.0! clients (i.e., "gzip" and "compress");
some older clients! improperly display messages sent with
other content-encodings. The! server may also make this decision based
on information about the! particular user-agent or client.

Note: Most HTTP/1.0 applications
do not recognize or obey qvalues! associated with content-codings. This
means that qvalues should! never be sent with x-gzip or x-compress.

--- 5289,5304 ---- information that a different content-coding
is meaningful to the client.

Note: If the request does not include
an Accept-Encoding field, and! if the "identity" content-coding is unavailable,
then it is! advisable to give preference to content-codings
commonly! understood by HTTP/1.0 clients (i.e.,
"gzip" and "compress"); some! older clients improperly display messages
sent with other! content-encodings. The server might also
make this decision based on! information about the particular user-agent
or client.

Note: Most HTTP/1.0 applications
do not recognize or obey qvalues! associated with content-codings. This
means that it will not work! to send qvalues with x-gzip or x-compress.

***************Reason:

Rephrased to avoid keywords; not normative; this is advice toimplementors on backward compatibility, not requirements for 1.1

---------------** issue MMS_AUDIT_ITEM_134:*** 5348,5354 **** header is present, then all languages which
are assigned a quality factor greater than 0 are acceptable.

! It may be contrary to the privacy expectations of
the user to send an Accept-Language header with the complete linguistic
preferences of the user in every request. For a discussion of this
issue, see section 15.1.4.--- 5348,5354 ---- header is present, then all languages which
are assigned a quality factor greater than 0 are acceptable.

! It might be contrary to the privacy expectations of
the user to send an Accept-Language header with the complete linguistic
preferences of the user in every request. For a discussion of this
issue, see section 15.1.4.***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_135:*** 5356,5369 **** Note: As intelligibility is highly
dependent on the individual user, it is recommended that client
applications make the choice of linguistic preference available
to the user. If the choice is not! made available, then the Accept-Language
header field must not be given in the request.

Note: When making the choice of linguistic
preference available to! the user, implementers should take into
account the fact that users are not familiar with the details
of language matching as described! above, and should provide appropriate
guidance. As an example,! users may assume that on selecting "en-gb",
they will be served any kind of English document if British
English is not available. A

--- 5356,5369 ---- Note: As intelligibility is highly
dependent on the individual user, it is recommended that client
applications make the choice of linguistic preference available
to the user. If the choice is not! made available, then the Accept-Language
header field MUST NOT be given in the request.

Note: When making the choice of linguistic
preference available to! the user, implementers are advised to
take into account the fact that users are not familiar with the details
of language matching as described! above, and provide appropriate guidance.
As an example,! users might assume that on selecting
"en-gb", they will be served any kind of English document if British
English is not available. A

A proxy MUST NOT modify the Allow header field
even if it does not! understand all the methods specified, since the user
agent MAY have other means of communicating with the origin
server.

14.8 Authorization

A user agent that wishes to authenticate itself
with a server--usually,! but not necessarily, after receiving a 401 response--MAY
do so by including an Authorization request-header field
with the request. The Authorization field value consists of credentials
containing the authentication information of the user agent
for the realm of the--- 5444,5457 ---- header in the response giving the actual supported
methods.

A proxy MUST NOT modify the Allow header field
even if it does not! understand all the methods specified, since the user
agent might have other means of communicating with the origin
server.

14.8 Authorization

A user agent that wishes to authenticate itself
with a server--usually,! but not necessarily, after receiving a 401 response--does
so by including an Authorization request-header field
with the request. The Authorization field value consists of credentials
containing the authentication information of the user agent
for the realm of the***************Reason:

---------------** issue MMS_AUDIT_ITEM_138:*** 5461,5467 **** HTTP access authentication is described in "HTTP
Authentication: Basic and Digest Access Authentication" .. If a request
is authenticated and a realm specified, the same credentials SHOULD
be valid for all other! requests within this realm.

When a shared cache (see section 13.7) receives
a request containing an Authorization field, it MUST NOT return the
corresponding response as a--- 5461,5469 ---- HTTP access authentication is described in "HTTP
Authentication: Basic and Digest Access Authentication" .. If a request
is authenticated and a realm specified, the same credentials SHOULD
be valid for all other! requests within this realm (assuming that the authentication
scheme! itself does not require otherwise, such as credentials
that vary! according to a challenge value or using syncronized
clocks).

When a shared cache (see section 13.7) receives
a request containing an Authorization field, it MUST NOT return the
corresponding response as a***************Reason:

This isn't strictly an MMS change, but I think that it may clarify
theintent; take it or leave it.

3. If the response includes the "public"
Cache-Control directive, it! may be returned in
reply to any subsequent request.

--- 5487,5493 ---- authenticate the
new request.

3. If the response includes the "public"
Cache-Control directive, it! MAY be returned in
reply to any subsequent request.

***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_140:*** 5501,5514 **** adversely interfering with the request or response.
These directives typically override the default caching algorithms.
Cache directives are unidirectional in that the presence of a directive
in a request does not! imply that the same directive should be given in
the response.

! Note that HTTP/1.0 caches may not implement
Cache-Control and may only implement Pragma: no-cache
(see section 14.32).

! Cache directives must be passed through by a proxy
or gateway application, regardless of their significance
to that application, since! the directives may be applicable to all recipients
along the request/response chain. It is not possible to
specify a cache-directive for a specific cache.

--- 5503,5516 ---- adversely interfering with the request or response.
These directives typically override the default caching algorithms.
Cache directives are unidirectional in that the presence of a directive
in a request does not! imply that the same directive is to be given in the
response.

! Cache directives MUST be passed through by a proxy
or gateway application, regardless of their significance
to that application, since! the directives might be applicable to all recipients
along the request/response chain. It is not possible to
specify a cache-directive for a specific cache.

---------------** issue MMS_AUDIT_ITEM_141:*** 5542,5548 **** directive appears with a 1#field-name parameter,
it applies only to the named field or fields, and not to the rest of
the request or response. This mechanism supports extensibility; implementations
of future! versions of the HTTP protocol may apply these directives
to header fields not defined in HTTP/1.1.

The cache-control directives can be broken down
into these general--- 5544,5550 ---- directive appears with a 1#field-name parameter,
it applies only to the named field or fields, and not to the rest of
the request or response. This mechanism supports extensibility; implementations
of future! versions of the HTTP protocol might apply these directives
to header fields not defined in HTTP/1.1.

The cache-control directives can be broken down
into these general***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_142:*** 5584,5590 **** single user and MUST NOT be cached
by a shared cache. This allows an origin server to state that the
specified parts of the response are intended for only one user and are
not a valid response for requests! by other users. A private (non-shared)
cache may cache the response.

Note: This usage of the word private
only controls where the response may be cached, and cannot
ensure the privacy of the--- 5586,5592 ---- single user and MUST NOT be cached
by a shared cache. This allows an origin server to state that the
specified parts of the response are intended for only one user and are
not a valid response for requests! by other users. A private (non-shared)
cache MAY cache the response.

Note: This usage of the word private
only controls where the response may be cached, and cannot
ensure the privacy of the***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_143:*** 5620,5626 **** no-store The purpose of the no-store directive
is to prevent the inadvertent release or retention of sensitive
information (for example, on backup! tapes). The no-store directive applies
to the entire message, and may be sent either in a response or
in a request. If sent in a request, a cache MUST NOT store any part of
either this request or any response to it. If sent in a response, a
cache MUST NOT store any part of--- 5622,5628 ---- no-store The purpose of the no-store directive
is to prevent the inadvertent release or retention of sensitive
information (for example, on backup! tapes). The no-store directive applies
to the entire message, and MAY be sent either in a response or
in a request. If sent in a request, a cache MUST NOT store any part of
either this request or any response to it. If sent in a response, a
cache MUST NOT store any part of***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_144:*** 5631,5655 **** attempt to remove the information
from volatile storage as promptly as possible after forwarding it.

! Even when this directive is associated
with a response, users may explicitly store such a response
outside of the caching system (e.g.,! with a "Save As" dialog). History buffers
may store such responses as part of their normal operation.

The purpose of this directive is
to meet the stated requirements of certain users and service authors
who are concerned about accidental releases of information via unanticipated
accesses to cache data! structures. While the use of this directive
may improve privacy in some cases, we caution that it is
NOT in any way a reliable or sufficient mechanism for ensuring
privacy. In particular, malicious! or compromised caches may not recognize
or obey this directive; and! communications networks may be vulnerable
to eavesdropping.

14.9.3 Modifications of the Basic Expiration
Mechanism

! The expiration time of an entity may be specified
by the origin server! using the Expires header (see section 14.20). Alternatively,
it may be specified using the max-age directive in a response.
When the max-age cache-control directive is present in a cached
response, the response is stale if its current age is greater than the
age value given (in--- 5633,5657 ---- attempt to remove the information
from volatile storage as promptly as possible after forwarding it.

! Even when this directive is associated
with a response, users MAY explicitly store such a response
outside of the caching system (e.g.,! with a "Save As" dialog). History buffers
MAY store such responses as part of their normal operation.

The purpose of this directive is
to meet the stated requirements of certain users and service authors
who are concerned about accidental releases of information via unanticipated
accesses to cache data! structures. While the use of this directive
might improve privacy in some cases, we caution that it is
NOT in any way a reliable or sufficient mechanism for ensuring
privacy. In particular, malicious! or compromised caches might not recognize
or obey this directive; and! communications networks might be vulnerable
to eavesdropping.

14.9.3 Modifications of the Basic Expiration
Mechanism

! The expiration time of an entity MAY be specified
by the origin server! using the Expires header (see section 14.20). Alternatively,
it MAY be specified using the max-age directive in a response.
When the max-age cache-control directive is present in a cached
response, the response is stale if its current age is greater than the
age value given (in***************Reason:

(1, 2) Upcase keyword; normative (not sure that it
should be, but I couldn't see a way to fix this without a rewrite
and I think we'd rather avoid that particular firestorm).(3) Rephrased to avoid keywords; not normative.(4) Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_145:*** 5662,5668 **** the max-age directive overrides the Expires
header, even if the Expires header is more restrictive. This rule allows
an origin server to provide, for a given response, a longer expiration
time to an HTTP/1.1! (or later) cache than to an HTTP/1.0 cache. This
may be useful if certain HTTP/1.0 caches improperly calculate
ages or expiration times, perhaps due to desynchronized clocks.

--- 5664,5670 ---- the max-age directive overrides the Expires
header, even if the Expires header is more restrictive. This rule allows
an origin server to provide, for a given response, a longer expiration
time to an HTTP/1.1! (or later) cache than to an HTTP/1.0 cache. This
might be useful if certain HTTP/1.0 caches improperly calculate
ages or expiration times, perhaps due to desynchronized clocks.

***************Reason:

Rephrased to avoid keywords; not normative;this is backward-compatibility advise to implementors, not a requirement

---------------** issue MMS_AUDIT_ITEM_146:*** 5701,5713 **** Note: most older
caches, not compliant with this specification, do not implement
any Cache-Control directives. An origin server wishing to use
a Cache-Control directive that restricts, but! does not prevent, caching
by an HTTP/1.1-compliant cache may exploit the requirement
that the max-age directive overrides the Expires header,
and the fact that pre-HTTP/1.1-compliant caches do not observe
the max-age directive.

Other directives allow a user agent to modify
the basic expiration! mechanism. These directives may be specified on a
request:

max-age Indicates that the client is willing
to accept a response whose age--- 5703,5715 ---- Note: most older
caches, not compliant with this specification, do not implement
any Cache-Control directives. An origin server wishing to use
a Cache-Control directive that restricts, but! does not prevent, caching
by an HTTP/1.1-compliant cache MAY exploit the requirement
that the max-age directive overrides the Expires header,
and the fact that pre-HTTP/1.1-compliant caches do not observe
the max-age directive.

Other directives allow a user agent to modify
the basic expiration! mechanism. These directives MAY be specified on a
request:

max-age Indicates that the client is willing
to accept a response whose age***************Reason:

(1, 2) Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_147:*** 5740,5746 **** the expiration time of a response, the cache
MUST attach a Warning header to the stale response, using Warning
110 (Response is stale).

! Note: A cache may be configured to return
stale responses without validation, but only if this does
not conflict with any MUST-level requirements concerning cache validation
(e.g., a "must-revalidate" Cache-Control directive).--- 5742,5748 ---- the expiration time of a response, the cache
MUST attach a Warning header to the stale response, using Warning
110 (Response is stale).

! Note: A cache MAY be configured to return
stale responses without validation, but only if this does
not conflict with any MUST-level requirements concerning cache validation
(e.g., a "must-revalidate" Cache-Control directive).***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_148:*** 5752,5758 ****

14.9.4 Cache Revalidation and Reload Controls

! Sometimes a user agent may want or need to insist
that a cache revalidate its cache entry with the origin server
(and not just with the next cache along the path to the origin server),
or to reload its cache entry from the origin server. End-to-end revalidation
may be necessary--- 5754,5760 ----

14.9.4 Cache Revalidation and Reload Controls

! Sometimes a user agent might want or need to insist
that a cache revalidate its cache entry with the origin server
(and not just with the next cache along the path to the origin server),
or to reload its cache entry from the origin server. End-to-end revalidation
may be necessary***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_149:*** 5760,5766 **** expiration time of the cached response. End-to-end
reload may be necessary if the cache entry has become corrupted
for some reason.

! End-to-end revalidation may be requested either when
the client does not have its own local cached copy, in which case
we call it "unspecified end-to-end revalidation", or when the client
does have a local cached copy, in which case we call it "specific end-to-end
revalidation."--- 5762,5768 ---- expiration time of the cached response. End-to-end
reload may be necessary if the cache entry has become corrupted
for some reason.

! End-to-end revalidation might be requested either
when the client does not have its own local cached copy, in which case
we call it "unspecified end-to-end revalidation", or when the client
does have a local cached copy, in which case we call it "specific end-to-end
revalidation."***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_150:*** 5770,5777 ****

End-to-end reload The request includes a "no-cache"
Cache-Control directive or, for! compatibility with HTTP/1.0 clients,
"Pragma: no-cache". No field! names may be included with the no-cache
directive in a request. The server MUST NOT use a cached copy
when responding to such a request.[jg178]

--- 5772,5779 ----

End-to-end reload The request includes a "no-cache"
Cache-Control directive or, for! compatibility with HTTP/1.0 clients,
"Pragma: no-cache". Field! names MUST NOT be included with the no-cache
directive in a request. The server MUST NOT use a cached copy
when responding to such a request.[jg178]

***************Reason:

Rephrased to use MUST NOT instead of 'No xxx may' to clarify - theconstruction in the draft isn't as clear in its use of the keywords.

directive, to revalidate its own
cache entry, and the client has! supplied its own validator in the request,
the supplied validator may differ from the validator currently
stored with the cache entry. In! this case, the cache may use either validator
in making its own request without affecting semantic
transparency.

! However, the choice of validator may affect
performance. The best approach is for the intermediate
cache to use its own validator when making its request. If the server
replies with 304 (Not Modified),! then the cache should return its now
validated copy to the client with a 200 (OK) response. If the
server replies with a new entity and! cache validator, however, the intermediate
cache should compare the returned validator with the one
provided in the client's request, using the strong comparison function.
If the client's validator is equal to the origin server's, then
the intermediate cache simply returns 304 (Not Modified). Otherwise,
it returns the new entity with a 200 (OK) response.

! If a request includes the no-cache directive,
it should not include min-fresh, max-stale, or max-age.

directive, to revalidate its own
cache entry, and the client has! supplied its own validator in the request,
the supplied validator might differ from the validator currently
stored with the cache entry. In! this case, the cache MAY use either validator
in making its own request without affecting semantic
transparency.

! However, the choice of validator might
affect performance. The best approach is for the intermediate
cache to use its own validator when making its request. If the server
replies with 304 (Not Modified),! then the cache can return its now validated
copy to the client with a 200 (OK) response. If the
server replies with a new entity and! cache validator, however, the intermediate
cache can compare the returned validator with the one
provided in the client's request, using the strong comparison function.
If the client's validator is equal to the origin server's, then
the intermediate cache simply returns 304 (Not Modified). Otherwise,
it returns the new entity with a 200 (OK) response.

! If a request includes the no-cache directive,
it SHOULD NOT include min-fresh, max-stale, or max-age.

only-if-cached***************Reason:

(1, 2, 3, 4) Rephrased to avoid keywords; not normative; these areadvice to implementors, not requirements.

---------------** issue MMS_AUDIT_ITEM_152:*** 5832,5846 **** forwarded within that group of caches.

must-revalidate! Because a cache may be configured to
ignore a server's specified! expiration time, and because a client
request may include a max-stale directive (which has a similar effect),
the protocol also includes a mechanism for the origin server
to require revalidation of a cache entry on any subsequent use. When
the must-revalidate directive is present in a response received by
a cache, that cache MUST NOT use the entry after it becomes stale
to respond to a subsequent request without first revalidating it with
the origin server. (I.e., the! cache must do an end-to-end revalidation
every time, if, based solely on the origin server's Expires or
max-age value, the cached response is stale.)

--- 5834,5848 ---- forwarded within that group of caches.

must-revalidate! Because a cache MAY be configured to
ignore a server's specified! expiration time, and because a client
request MAY include a max-stale directive (which has a similar effect),
the protocol also includes a mechanism for the origin server
to require revalidation of a cache entry on any subsequent use. When
the must-revalidate directive is present in a response received by
a cache, that cache MUST NOT use the entry after it becomes stale
to respond to a subsequent request without first revalidating it with
the origin server. (I.e., the! cache MUST do an end-to-end revalidation
every time, if, based solely on the origin server's Expires or
max-age value, the cached response is stale.)

***************Reason:

Upcase keywords; normative.

---------------** issue MMS_AUDIT_ITEM_153:*** 5850,5856 **** particular, if the cache cannot
reach the origin server for any reason, it MUST generate a 504 (Gateway
Timeout) response.

! Servers should send the must-revalidate
directive if and only if failure to revalidate a request
on the entity could result in incorrect operation, such as a silently
unexecuted financial transaction. Recipients MUST NOT
take any automated action that--- 5852,5858 ---- particular, if the cache cannot
reach the origin server for any reason, it MUST generate a 504 (Gateway
Timeout) response.

! Servers SHOULD send the must-revalidate
directive if and only if failure to revalidate a request
on the entity could result in incorrect operation, such as a silently
unexecuted financial transaction. Recipients MUST NOT
take any automated action that***************Reason:

Although this is not recommended,
user agents operating under severe! connectivity constraints may violate
this directive but, if so, MUST explicitly warn the user that an
unvalidated response has been provided. The warning MUST be provided
on each unvalidated access, and SHOULD require explicit user
confirmation.--- 5865,5871 ---- unvalidated copy of the entity if
revalidation fails.

Although this is not recommended,
user agents operating under severe! connectivity constraints MAY violate
this directive but, if so, MUST explicitly warn the user that an
unvalidated response has been provided. The warning MUST be provided
on each unvalidated access, and SHOULD require explicit user
confirmation.***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_155:*** 5899,5905 **** Therefore, if a message includes
the no-transform directive, an intermediate cache or proxy MUST
NOT change those headers that are listed in section 13.5.2 as being
subject to the no-transform! directive. This implies that the cache
or proxy must not change any aspect of the entity-body that is
specified by these headers.

--- 5901,5907 ---- Therefore, if a message includes
the no-transform directive, an intermediate cache or proxy MUST
NOT change those headers that are listed in section 13.5.2 as being
subject to the no-transform! directive. This implies that the cache
or proxy MUST NOT change any aspect of the entity-body that is
specified by these headers.

***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_156:*** 5908,5914 **** The Cache-Control header field can be extended
through the use of one or more cache-extension tokens, each with an optional
assigned value. Informational extensions (those which do not
require a change in cache! behavior) may be added without changing the semantics
of other directives. Behavioral extensions are designed
to work by acting as modifiers to the existing base of cache directives.
Both the new directive and the standard directive are supplied,
such that--- 5910,5916 ---- The Cache-Control header field can be extended
through the use of one or more cache-extension tokens, each with an optional
assigned value. Informational extensions (those which do not
require a change in cache! behavior) MAY be added without changing the semantics
of other directives. Behavioral extensions are designed
to work by acting as modifiers to the existing base of cache directives.
Both the new directive and the standard directive are supplied,
such that***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_157:*** 5935,5941 **** any cache which is shared only by members of
the community named within its value may cache the response. An origin
server wishing to allow the UCI community to use an otherwise private response
in their shared! cache(s) may do so by including

Cache-Control:
private, community="UCI" A cache seeing this header field will act correctly
even if the cache--- 5937,5943 ---- any cache which is shared only by members of
the community named within its value may cache the response. An origin
server wishing to allow the UCI community to use an otherwise private response
in their shared! cache(s) could do so by including

Cache-Control:
private, community="UCI" A cache seeing this header field will act correctly
even if the cache***************Reason:

Rephrased to avoid keywords; not normative; this is advice, not
arequirement

in either the request or the response header
fields indicates that the! connection SHOULD NOT be considered `persistent'
(section 8.1) after the current request/response is complete.

HTTP/1.1 applications that do not support persistent
connections MUST***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_159:*** 6034,6040 ****

The Content-Language entity-header field describes
the natural language(s) of the intended audience for the
enclosed entity. Note that! this may not be equivalent to all the languages used
within the entity- body.

--- 6036,6042 ----

The Content-Language entity-header field describes
the natural language(s) of the intended audience for the
enclosed entity. Note that! this might not be equivalent to all the languages
used within the entity- body.

***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_160:*** 6051,6057 ****

Content-Language:
da If no Content-Language is specified, the default
is that the content is! intended for all language audiences. This may mean
that the sender does not consider it to be specific to any natural
language, or that the sender does not know for which language it is
intended.

--- 6053,6059 ----

Content-Language:
da If no Content-Language is specified, the default
is that the content is! intended for all language audiences. This might mean
that the sender does not consider it to be specific to any natural
language, or that the sender does not know for which language it is
intended.

***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_161:*** 6065,6073 **** does not mean that it is intended for multiple
linguistic audiences. An example would be a beginner's language primer,
such as "A First Lesson in Latin," which is clearly intended to be used
by an English-literate! audience. In this case, the Content-Language should
only include "en".

! Content-Language may be applied to any media type
-- it is not limited to textual documents.

--- 6067,6075 ---- does not mean that it is intended for multiple
linguistic audiences. An example would be a beginner's language primer,
such as "A First Lesson in Latin," which is clearly intended to be used
by an English-literate! audience. In this case, the Content-Language would
properly only include "en".

! Content-Language MAY be applied to any media type
-- it is not limited to textual documents.

Content-MD5 = "Content-MD5" ":" md5-digest
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>! The Content-MD5 header field may be generated by
an origin server to function as an integrity check of the entity-body.
Only origin servers may generate the Content-MD5 header field; proxies
and gateways MUST NOT generate it, as this would defeat its value
as an end-to-end integrity--- 6151,6157 ----

Content-MD5 = "Content-MD5" ":" md5-digest
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>! The Content-MD5 header field MAY be generated by
an origin server to function as an integrity check of the entity-body.
Only origin servers may generate the Content-MD5 header field; proxies
and gateways MUST NOT generate it, as this would defeat its value
as an end-to-end integrity***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_163:*** 6164,6170 ****

INTERNET-DRAFT
HTTP/1.1 Friday,
March 13, 1998

! any Transfer-Encoding that may have been applied to
the message-body. If! the message is received with a Transfer-Encoding,
that encoding must be removed prior to checking the Content-MD5 value
against the received entity.--- 6166,6172 ----

INTERNET-DRAFT
HTTP/1.1 Friday,
March 13, 1998

! any Transfer-Encoding applied to the message-body.
If! the message is received with a Transfer-Encoding,
that encoding MUST be removed prior to checking the Content-MD5 value
against the received entity.***************Reason:

Note: There are several consequences
of this. The entity-body for! composite types may contain many body-parts,
each with its own MIME and HTTP headers (including Content-MD5,
Content-Transfer-Encoding, and Content-Encoding headers). If
a body-part has a Content- Transfer-Encoding or Content-Encoding
header, it is assumed that--- 6181,6187 ---- paragraph.

Note: There are several consequences
of this. The entity-body for! composite types MAY contain many body-parts,
each with its own MIME and HTTP headers (including Content-MD5,
Content-Transfer-Encoding, and Content-Encoding headers). If
a body-part has a Content- Transfer-Encoding or Content-Encoding
header, it is assumed that***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_165:*** 6199,6207 **** digest is the transmission byte
order defined for the type. Lastly, HTTP allows transmission of text
types with any of several line break conventions and not just the
canonical form using CRLF.! Conversion of all line breaks to CRLF
should not be done before computing or checking the digest:
the line break convention used in! the text actually transmitted should
be left unaltered when computing the digest.

--- 6201,6209 ---- digest is the transmission byte
order defined for the type. Lastly, HTTP allows transmission of text
types with any of several line break conventions and not just the
canonical form using CRLF.! Conversion of all line breaks to CRLF
MUST NOT be done before computing or checking the digest:
the line break convention used in! the text actually transmitted MUST be
left unaltered when computing the digest.

***************Reason:

I actually changed 'should' to MUST here in two places - if it is
notalways done as specified here, it will not interoperate.

---------------** issue MMS_AUDIT_ITEM_166:*** 6209,6215 ****

The Content-Range entity-header is sent with
a partial entity-body to specify where in the full entity-body the partial
body should be! inserted. It SHOULD indicate the total length of
the full entity-body, unless this length is unknown or difficult to
determine.

The Content-Range entity-header is sent with
a partial entity-body to specify where in the full entity-body the partial
body should be! inserted **. It SHOULD indicate the total length
of the full entity-body, unless this length is unknown or difficult to
determine.

I flagged this one just to make a comment - the use of 'inserted'
hereis not really the general way to describe this, but I couldn't
thinkof a better one without rewriting the whole paragraph. Since
I'm notactually convinced that range requests are generally usefull I
didn'ttake that on.

---------------** issue MMS_AUDIT_ITEM_167:*** 6229,6236 **** The asterisk "*" character means that the instance-length
is unknown at the time when the response was generated.

! Unlike byte-ranges-specifier values, a byte-range-resp-spec
may only! specify one range, and must contain absolute byte
positions for both the first and last byte of the range.

A byte-content-range-spec with a byte-range-resp-spec
whose last-byte---- 6231,6238 ---- The asterisk "*" character means that the instance-length
is unknown at the time when the response was generated.

! Unlike byte-ranges-specifier values, a byte-range-resp-spec
MUST only! specify one range, and MUST contain absolute byte
positions for both the first and last byte of the range.

A byte-content-range-spec with a byte-range-resp-spec
whose last-byte-***************Reason:

Rephrased to use MUST rather than may; this seemed the intent to
me,and upcase the keywords.

---------------** issue MMS_AUDIT_ITEM_168:*** 6278,6284 **** multipart/byteranges media type. A reponse
to a request for multiple ranges, whose result is a single range, MAY
be sent as a multipart/byteranges media type with one part.
A client that cannot! decode a multipart/byteranges message should not
ask for multiple byte- ranges in a single request.

--- 6280,6286 ---- multipart/byteranges media type. A reponse
to a request for multiple ranges, whose result is a single range, MAY
be sent as a multipart/byteranges media type with one part.
A client that cannot! decode a multipart/byteranges message SHOULD NOT
ask for multiple byte- ranges in a single request.

***************Reason:

Upcase keyword; normative<aside>this would be stupid anyway - I don't really think this sort ofobvious stuff should even be in here, but... - SL</aside>

---------------** issue MMS_AUDIT_ITEM_169:*** 6290,6296 **** SHOULD return them in the order that they appeared
in the request.

If the server ignores a byte-range-spec because
it is syntactically! invalid, the server should treat the request as if
the invalid Range header field did not exist. (Normally, this
means return a 200 response containing the full entity).

--- 6292,6298 ---- SHOULD return them in the order that they appeared
in the request.

If the server ignores a byte-range-spec because
it is syntactically! invalid, the server SHOULD treat the request as if
the invalid Range header field did not exist. (Normally, this
means return a 200 response containing the full entity).

***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_170:*** 6377,6383 ****

14.18.1 Clockless Origin Server Operation

! Some origin server implementations may not have a
clock available. An origin server without a clock MUST NOT assign
Expires or Last-Modified values to a response, unless these values were
associated with the resource by a system or user with a reliable
clock. It MAY assign an--- 6379,6385 ----

14.18.1 Clockless Origin Server Operation

! Some origin server implementations might not have
a clock available. An origin server without a clock MUST NOT assign
Expires or Last-Modified values to a response, unless these values were
associated with the resource by a system or user with a reliable
clock. It MAY assign an***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_171:*** 6390,6396 ****

The ETag response-header field provides the current
value of the entity tag for the requested variant. The headers used
with entity tags are! described in sections 14.24, 14.26 and 14.44. The
entity tag may be used for comparison with other entities from the
same resource (see section 13.3.3).

--- 6392,6398 ----

The ETag response-header field provides the current
value of the entity tag for the requested variant. The headers used
with entity tags are! described in sections 14.24, 14.26 and 14.44. The
entity tag MAY be used for comparison with other entities from the
same resource (see section 13.3.3).

Note: Because of the presence of
older implementations, the! protocol allows ambiguous situations
in which a client may send "Expect: 100-continue" without receiving
either a 417 (Expectation Failed) status or a 100 (Continue)
status. Therefore, when a client sends this header field to an origin
server (possibly via a proxy)--- 6462,6468 ---- servers.

Note: Because of the presence of
older implementations, the! protocol allows ambiguous situations
in which a client MAY send "Expect: 100-continue" without receiving
either a 417 (Expectation Failed) status or a 100 (Continue)
status. Therefore, when a client sends this header field to an origin
server (possibly via a proxy)***************Reason:

from which it has never seen a 100
(Continue) status, the client! should not wait for an indefinite or
lengthy period before sending the request body.

14.21 Expires

The Expires entity-header field gives the date/time
after which the! response should be considered stale. A stale cache
entry may not normally be returned by a cache (either a proxy
cache or a user agent cache) unless it is first validated with the
origin server (or with an intermediate cache that has a fresh copy of
the entity). See section--- 6472,6485 ---- INTERNET-DRAFT
HTTP/1.1 Friday,
March 13, 1998

from which it has never seen a 100
(Continue) status, the client! need not wait for an indefinite or lengthy
period before sending the request body.

14.21 Expires

The Expires entity-header field gives the date/time
after which the! response is to be considered stale. A stale cache
entry MUST NOT normally be returned by a cache (either a proxy
cache or a user agent cache) unless it is first validated with the
origin server (or with an intermediate cache that has a fresh copy of
the entity). See section***************Reason:

(1) Rephrased to avoid keywords; not normative; this is advice, not a requirement.(2) Rephrased to avoid MAY; perhaps I should have used SHOULD though... the 'normally' confuses the intent,
I think

! To mark a response as "already expired," an origin
server should use an Expires date that is equal to the Date header
value. (See the rules for expiration calculations in section 13.2.4.)

! To mark a response as "never expires," an origin server
should use an Expires date approximately one year from the
time the response is sent.! HTTP/1.1 servers should not send Expires dates more
than one year in the future.

The presence of an Expires header field with
a date value of some time--- 6502,6514 ---- especially including the value "0", as in the
past (i.e., "already expired").

! To mark a response as "already expired," an origin
server sends an Expires date that is equal to the Date header
value. (See the rules for expiration calculations in section 13.2.4.)

! To mark a response as "never expires," an origin server
sends an Expires date approximately one year from the
time the response is sent.! HTTP/1.1 servers SHOULD NOT send Expires dates more
than one year in the future.

The presence of an Expires header field with
a date value of some time***************Reason:

These are explanatory; rephrased to avoid the keyword 'should'.

---------------** issue MMS_AUDIT_ITEM_175:*** 6545,6551 **** passed through a proxy the original issuer's
address SHOULD be used.

Note: The client SHOULD NOT send
the From header field without the! user's approval, as it may conflict with
the user's privacy interests or their site's security
policy. It is strongly recommended that the user be able
to disable, enable, and modify the value of this field at any time
prior to a request.--- 6547,6553 ---- passed through a proxy the original issuer's
address SHOULD be used.

Note: The client SHOULD NOT send
the From header field without the! user's approval, as it might conflict
with the user's privacy interests or their site's security
policy. It is strongly recommended that the user be able
to disable, enable, and modify the value of this field at any time
prior to a request.***************Reason:

Note that If-Modified-Since times
are interpreted by the server,! whose clock may not be synchronized with
the client.

Note: When handling an If-Modified-Since
header field, some servers will use an exact date comparison
function, rather than a less-than function, for deciding whether to
send a 304 (Not Modified) response. To get best results when
sending an If-Modified-Since! header field for cache validation, clients
should use the exact date string received in a previous
Last-Modified header field whenever possible.

--- 6684,6696 ---- If-Modified-Since; see section 14.35
for full details.

Note that If-Modified-Since times
are interpreted by the server,! whose clock might not be synchronized
with the client.

Note: When handling an If-Modified-Since
header field, some servers will use an exact date comparison
function, rather than a less-than function, for deciding whether to
send a 304 (Not Modified) response. To get best results when
sending an If-Modified-Since! header field for cache validation, clients
are advised to use the exact date string received in a previous
Last-Modified header field whenever possible.

***************Reason:

(1, 2) Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_178:*** 6776,6782 ****

cache, possibly using the Vary mechanism, see
section 14.44) exists, and SHOULD be performed if the representation does
not exist. This feature! may be useful in preventing races between PUT operations.

Examples:

--- 6778,6784 ----

cache, possibly using the Vary mechanism, see
section 14.44) exists, and SHOULD be performed if the representation does
not exist. This feature! is intended to be useful in preventing races between
PUT operations.

Examples:

***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_179:*** 6806,6815 ****

If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) If the client has no entity tag for an entity,
but does have a Last-! Modified date, it may use that date in a If-Range
header. (The server can distinguish between a valid HTTP-date and
any form of entity-tag by! examining no more than two characters.) The If-Range
header should only! be used together with a Range header, and must be
ignored if the request does not include a Range header, or if the server
does not support the sub-range operation.

--- 6808,6817 ----

If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) If the client has no entity tag for an entity,
but does have a Last-! Modified date, it MAY use that date in a If-Range
header. (The server can distinguish between a valid HTTP-date and
any form of entity-tag by! examining no more than two characters.) The If-Range
header SHOULD only! be used together with a Range header, and MUST be
ignored if the request does not include a Range header, or if the server
does not support the sub-range operation.

***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_180:*** 6824,6830 ****

The If-Unmodified-Since request-header field
is used with a method to make it conditional. If the requested resource
has not been modified! since the time specified in this field, the server
should perform the requested operation as if the If-Unmodified-Since
header were not present.

--- 6826,6832 ----

The If-Unmodified-Since request-header field
is used with a method to make it conditional. If the requested resource
has not been modified! since the time specified in this field, the server
SHOULD perform the requested operation as if the If-Unmodified-Since
header were not present.

***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_181:*** 6846,6852 ****

If the request normally (i.e., without the If-Unmodified-Since
header) would result in anything other than a 2xx or
412 status, the If-! Unmodified-Since header should be ignored.

If the specified date is invalid, the header
is ignored.

--- 6848,6854 ----

If the request normally (i.e., without the If-Unmodified-Since
header) would result in anything other than a 2xx or
412 status, the If-! Unmodified-Since header SHOULD be ignored.

If the specified date is invalid, the header
is ignored.

***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_182:*** 6872,6883 **** be the last-update time stamp of the record.
For virtual objects, it may be the last time the internal state changed.

An origin server MUST NOT send a Last-Modified
date which is later than the server's time of message origination. In
such cases, where the resource's last modification would indicate
some time in the future, the server MUST replace that date with the message
origination date.

! An origin server should obtain the Last-Modified value
of the entity as close as possible to the time that it generates
the Date value of its response. This allows a recipient to make an
accurate assessment of the entity's modification time, especially if the
entity changes near the--- 6874,6888 ---- be the last-update time stamp of the record.
For virtual objects, it may be the last time the internal state changed.

An origin server MUST NOT send a Last-Modified
date which is later than the server's time of message origination. In
such cases, where the resource's last modification would indicate
some time in the future, the server MUST replace that date with the message
origination date.

! An origin server SHOULD obtain the Last-Modified value
of the entity as close as possible to the time that it generates
the Date value of its response. This allows a recipient to make an
accurate assessment of the entity's modification time, especially if the
entity changes near the***************Reason:

Upcase keyword; normative.

The 'may's in the preceding paragraph seem to me to be descriptive,not normative, so I left them lower case.

---------------** issue MMS_AUDIT_ITEM_183:*** 6915,6921 ****

14.31 Max-Forwards

! The Max-Forwards request-header field MAY be used
with the TRACE (section 14.31) and OPTIONS (section 9.2) methods
to limit the number of proxies or gateways that can forward the request
to the next inbound server. This can be useful when the client is
attempting to trace a--- 6920,6926 ----

14.31 Max-Forwards

! The Max-Forwards request-header field provides a mechanism
with the TRACE (section 14.31) and OPTIONS (section 9.2) methods
to limit the number of proxies or gateways that can forward the request
to the next inbound server. This can be useful when the client is
attempting to trace a***************Reason:

Removed keyword - the sentence is descriptive, not normative

---------------** issue MMS_AUDIT_ITEM_184:*** 6926,6932 **** number of times this request message is to be
forwarded.

Each proxy or gateway recipient of a TRACE or
OPTIONS request containing! a Max-Forwards header field SHOULD check and update
its value prior to forwarding the request. If the received value
is zero (0), the recipient MUST NOT forward the request; instead, it MUST
respond as the final recipient. If the received Max-Forwards value
is greater than zero, then--- 6931,6937 ---- number of times this request message is to be
forwarded.

Each proxy or gateway recipient of a TRACE or
OPTIONS request containing! a Max-Forwards header field SHOULD check and update
its value prior to forwarding the request. If the received value
is zero (0), the recipient MUST NOT forward the request; instead, it MUST
respond as the final recipient. If the received Max-Forwards value
is greater than zero, then***************Reason:

I marked this one because I think it should be a MUST where thatSHOULD is.

The Pragma general-header field is used to include
implementation-! specific directives that may apply to any recipient
along the request/response chain. All pragma directives
specify optional behavior from the viewpoint of the protocol; however,
some systems MAY require that behavior be consistent with the directives.*** 6941,6947 **** 14.32 Pragma

The Pragma general-header field is used to include
implementation-! specific directives that might apply to any recipient
along the request/response chain. All pragma directives
specify optional behavior from the viewpoint of the protocol; however,
some systems MAY require that behavior be consistent with the directives.***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_186:--- 6969,6975 ----

Pragma directives MUST be passed through by a
proxy or gateway application, regardless of their significance
to that application, since! the directives may be applicable to all recipients
along the request/response chain. It is not possible to
specify a pragma for a specific recipient; however, any pragma directive
not relevant to a recipient SHOULD be ignored by that recipient.*** 6964,6970 ****

Pragma directives MUST be passed through by a
proxy or gateway application, regardless of their significance
to that application, since! the directives might be applicable to all recipients
along the request/response chain. It is not possible to
specify a pragma for a specific recipient; however, any pragma directive
not relevant to a recipient SHOULD be ignored by that recipient.***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_187:--- 6991,6997 ---- Authentication: Basic and Digest Access Authentication"
. Unlike WWW- Authenticate, the Proxy-Authenticate header
field applies only to the current connection and SHOULD NOT be passed
on to downstream clients.! However, an intermediate proxy may need to obtain
its own credentials by requesting them from the downstream client,
which in some circumstances will appear as if the proxy is forwarding the
Proxy-Authenticate header field.*** 6986,6992 **** Authentication: Basic and Digest Access Authentication"
. Unlike WWW- Authenticate, the Proxy-Authenticate header
field applies only to the current connection and SHOULD NOT be passed
on to downstream clients.! However, an intermediate proxy might need to obtain
its own credentials by requesting them from the downstream client,
which in some circumstances will appear as if the proxy is forwarding the
Proxy-Authenticate header field.***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_188:--- 7036,7042 ---- Byte range specifications in HTTP apply to the
sequence of bytes in the entity-body (not necessarily the same as the
message-body).

! A byte range operation may specify a single range
of bytes, or a set of ranges within a single entity.

ranges-specifier
= byte-ranges-specifier*** 7031,7037 **** Byte range specifications in HTTP apply to the
sequence of bytes in the entity-body (not necessarily the same as the
message-body).

! A byte range operation MAY specify a single range
of bytes, or a set of ranges within a single entity.

ranges-specifier
= byte-ranges-specifier***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_189:--- 7050,7056 ---- of the last byte in the range; that is, the
byte positions specified are inclusive. Byte offsets start at zero.

! If the last-byte-pos value is present, it must be
greater than or equal to the first-byte-pos in that byte-range-spec,
or the byte-range-spec is syntactically invalid. The recipient of a byte-range-set
that includes one or more syntactically invalid byte-range-spec
values MUST ignore the*** 7045,7051 **** of the last byte in the range; that is, the
byte positions specified are inclusive. Byte offsets start at zero.

! If the last-byte-pos value is present, it MUST be
greater than or equal to the first-byte-pos in that byte-range-spec,
or the byte-range-spec is syntactically invalid. The recipient of a byte-range-set
that includes one or more syntactically invalid byte-range-spec
values MUST ignore the***************Reason:

HTTP retrieval requests using conditional or
unconditional GET methods! may request one or more sub-ranges of the entity,
instead of the entire entity, using the Range request header, which
applies to the entity returned as the result of the request:

Range = "Range"
":" ranges-specifier A server MAY ignore the Range header. However,
HTTP/1.1 origin servers! and intermediate caches should support byte ranges
when possible, since Range supports efficient recovery from partially
failed transfers, and supports efficient partial retrieval of large
entities.

*** 7103,7115 **** 14.35.2 Range Retrieval Requests

HTTP retrieval requests using conditional or
unconditional GET methods! MAY request one or more sub-ranges of the entity,
instead of the entire entity, using the Range request header, which
applies to the entity returned as the result of the request:

Range = "Range"
":" ranges-specifier A server MAY ignore the Range header. However,
HTTP/1.1 origin servers! and intermediate caches SHOULD support byte ranges
when possible, since Range supports efficient recovery from partially
failed transfers, and supports efficient partial retrieval of large
entities.

***************Reason:

(1, 2) Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_191:--- 7131,7137 ---- if the GET is
otherwise successful and the condition is true. It does not affect
the 304 (Not Modified) response returned if the conditional is
false.! In some cases, it may be more appropriate to use
the If-Range header (see section 14.27) in addition to the Range
header.

If a proxy that supports ranges receives a Range
request, forwards the*** 7126,7132 **** if the GET is
otherwise successful and the condition is true. It does not affect
the 304 (Not Modified) response returned if the conditional is
false.! In some cases, it might be more appropriate to use
the If-Range header (see section 14.27) in addition to the Range
header.

If a proxy that supports ranges receives a Range
request, forwards the***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_192:--- 7172,7178 ---- Unavailable) response to indicate how long the
service is expected to be unavailable to the requesting client. This field
MAY also be used with any 3xx (Redirection) response to indicate the
minimum time the user-! agent should wait before issuing the redirected request.
The value of this field can be either an HTTP-date or an
integer number of seconds (in decimal) after the time of the response.

*** 7167,7173 **** Unavailable) response to indicate how long the
service is expected to be unavailable to the requesting client. This field
MAY also be used with any 3xx (Redirection) response to indicate the
minimum time the user-! agent is asked to wait before issuing the redirected
request. The value of this field can be either an HTTP-date or an
integer number of seconds (in decimal) after the time of the response.

***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_193:--- 7206,7212 ----

INTERNET-DRAFT
HTTP/1.1 Friday,
March 13, 1998

! Note: Revealing the specific software
version of the server may allow the server machine to become
more vulnerable to attacks against software that is known to
contain security holes. Server implementers are encouraged to make
this field a configurable*** 7201,7207 ****

INTERNET-DRAFT
HTTP/1.1 Friday,
March 13, 1998

! Note: Revealing the specific software
version of the server might allow the server machine to become
more vulnerable to attacks against software that is known to
contain security holes. Server implementers are encouraged to make
this field a configurable***************Reason:

The Vary field value indicates the set of request-header
fields that! fully determines, while the response is fresh, whether
a cache may use the response to reply to a subsequent request
without revalidation. For uncachable or stale responses, the Vary field
value advises the user agent about the criteria that were used to select
the representation. A*** 7397,7404 **** 14.44 Vary

The Vary field value indicates the set of request-header
fields that! fully determines, while the response is fresh, whether
a cache is! permitted to use the response to reply to a subsequent request
without revalidation. For uncachable or stale responses, the Vary field
value advises the user agent about the criteria that were used to select
the representation. A***************Reason:

The Warning response-header field is used to
carry additional! information about the status of a response which
may not be reflected by the response status code. This information is
typically, though not exclusively, used to warn about a possible lack
of semantic transparency from caching operations.*** 7519,7525 **** 14.46 Warning

The Warning response-header field is used to
carry additional! information about the status of a response which
might not be reflected by the response status code. This information is
typically, though not exclusively, used to warn about a possible lack
of semantic transparency from caching operations.***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_196:--- 7540,7550 ----
; the Warning header, for use in debugging warn-text
= quoted-string warn-date
= <"> HTTP-date <">! A response may carry more than one Warning header.

! The warn-text should be in a natural language and
character set that is most likely to be intelligible to the human
user receiving the response.! This decision may be based on any available knowledge,
such as the location of the cache or user, the Accept-Language
field in a request, the Content-Language field in a response, etc.
The default language is English and the default character set is ISO-8859-1.*** 7536,7546 ****
; the Warning header, for use in debugging warn-text
= quoted-string warn-date
= <"> HTTP-date <">! A response MAY carry more than one Warning header.

! The warn-text SHOULD be in a natural language and
character set that is most likely to be intelligible to the human
user receiving the response.! This decision MAY be based on any available knowledge,
such as the location of the cache or user, the Accept-Language
field in a request, the Content-Language field in a response, etc.
The default language is English and the default character set is ISO-8859-1.***************Reason:

(1, 2, 3) Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_197:--- 7552,7559 ---- If a character set other than ISO-8859-1 is
used, it MUST be encoded in the warn-text using the method described in
RFC 2047 [14].

! Any server or cache may add Warning headers to a response.
New Warning! headers should be added after any existing Warning
headers. A cache MUST NOT delete any Warning header that it received
with a response. However, if a cache successfully validates a cache entry,
it SHOULD remove any Warning headers previously attached to that
entry except as specified*** 7548,7555 **** If a character set other than ISO-8859-1 is
used, it MUST be encoded in the warn-text using the method described in
RFC 2047 [14].

! Any server or cache MAY add Warning headers to a response.
New Warning! headers SHOULD be added after any existing Warning
headers. A cache MUST NOT delete any Warning header that it received
with a response. However, if a cache successfully validates a cache entry,
it SHOULD remove any Warning headers previously attached to that
entry except as specified***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_198:--- 7564,7570 ---- When multiple Warning headers are attached to
a response, the user agent SHOULD display as many of them as possible,
in the order that they appear in the response. If it is not possible
to display all of the! warnings, the user agent should follow these heuristics:

*** 7560,7566 **** When multiple Warning headers are attached to
a response, the user agent SHOULD display as many of them as possible,
in the order that they appear in the response. If it is not possible
to display all of the! warnings, the user agent SHOULD follow these heuristics:

***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_199:--- 7577,7583 ---- . Warnings in the user's preferred
character set take priority over warnings in other
character sets but with identical warn-codes and warn-agents.! Systems that generate multiple Warning headers should
order them with this user agent behavior in mind.

The warn-code consists of three digits. The first
digit indicates*** 7573,7579 **** . Warnings in the user's preferred
character set take priority over warnings in other
character sets but with identical warn-codes and warn-agents.! Systems that generate multiple Warning headers SHOULD
order them with this user agent behavior in mind.

The warn-code consists of three digits. The first
digit indicates***************Reason:

199 Miscellaneous warning! The warning text may include arbitrary
information to be presented to a human user, or logged. A system
receiving this warning MUST NOT take any automated action, besides
presenting the warning to the user.*** 7608,7614 **** 24 hours.

199 Miscellaneous warning! The warning text MAY include arbitrary
information to be presented to a human user, or logged. A system
receiving this warning MUST NOT take any automated action, besides
presenting the warning to the user.***************Reason:

299 Miscellaneous persistent warning! The warning text may include arbitrary
information to be presented to a human user, or logged. A system
receiving this warning MUST NOT take any automated action.

*** 7621,7627 **** appears in the response.

299 Miscellaneous persistent warning! The warning text MAY include arbitrary
information to be presented to a human user, or logged. A system
receiving this warning MUST NOT take any automated action.

***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_202:--- 7657,7666 ---- WWW-Authenticate
= "WWW-Authenticate" ":" 1#challenge The HTTP access authentication process is described
in "HTTP Authentication: Basic and Digest Access Authentication"
. User agents! MUST take special care in parsing the WWW-Authenticate
field value if it! contains more than one challenge, or if more than
one WWW-Authenticate! header field is provided, since the contents of a
challenge may itself! contain a comma-separated list of authentication
parameters.

15 Security Considerations*** 7653,7663 **** WWW-Authenticate
= "WWW-Authenticate" ":" 1#challenge The HTTP access authentication process is described
in "HTTP Authentication: Basic and Digest Access Authentication"
. User agents! are advised to take special care in parsing the WWW-Authenticate
field! value as it might contain more than one challenge,
or if more than! one WWW-Authenticate header field is provided, since
the contents of! a challenge itself can contain a comma-separated
list of! authentication parameters.

A server is in the position to save personal
data about a user's! requests which may identify their reading patterns
or subjects of interest. This information is clearly confidential
in nature and its! handling may be constrained by law in certain countries.
People using the HTTP protocol to provide data are responsible
for ensuring that such material is not distributed without the permission
of any individuals that are identifiable by the published results.*** 7694,7702 **** 15.1.1 Abuse of Server Log Information

A server is in the position to save personal
data about a user's! requests which might identify their reading patterns
or subjects of interest. This information is clearly confidential
in nature and its! handling can be constrained by law in certain countries.
People using the HTTP protocol to provide data are responsible
for ensuring that such material is not distributed without the permission
of any individuals that are identifiable by the published results.***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_204:--- 7715,7721 ---- possible to the provider of that information.
Four header fields are worth special mention in this context: Server,
Via, Referer and From.

! Revealing the specific software version of the server
may allow the server machine to become more vulnerable to
attacks against software that is known to contain security holes. Implementers
SHOULD make the Server header field a configurable option.*** 7712,7718 **** possible to the provider of that information.
Four header fields are worth special mention in this context: Server,
Via, Referer and From.

! Revealing the specific software version of the server
might allow the server machine to become more vulnerable to
attacks against software that is known to contain security holes. Implementers
SHOULD make the Server header field a configurable option.***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_205:--- 7730,7736 ---- links drawn. Although it can be very useful,
its power can be abused if user details are not separated from the information
contained in the Referer. Even when the personal information
has been removed, the! Referer field may indicate a private document's URI
whose publication would be inappropriate.

The information sent in the From field might
conflict with the user's*** 7727,7733 **** links drawn. Although it can be very useful,
its power can be abused if user details are not separated from the information
contained in the Referer. Even when the personal information
has been removed, the! Referer field might indicate a private document's
URI whose publication would be inappropriate.

The information sent in the From field might
conflict with the user's***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_206:--- 7747,7753 ----

15.1.3 Encoding Sensitive Information in URL's

! Because the source of a link may be private information
or may reveal an otherwise private information source, it is
strongly recommended that the user be able to select whether or not the
Referer field is sent. For

*** 7744,7750 ****

15.1.3 Encoding Sensitive Information in URL's

! Because the source of a link might be private information
or may reveal an otherwise private information source, it is
strongly recommended that the user be able to select whether or not the
Referer field is sent. For

***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_207:--- 7765,7771 ---- Authors of services which use the HTTP protocol
SHOULD NOT use GET based forms for the submission of sensitive data,
because this will cause this data to be encoded in the request-URI. Many
existing servers, proxies,! and user agents will log the request URI in some
place where it may be visible to third parties. Servers can use POST-based
form submission instead

*** 7762,7768 **** Authors of services which use the HTTP protocol
SHOULD NOT use GET based forms for the submission of sensitive data,
because this will cause this data to be encoded in the request-URI. Many
existing servers, proxies,! and user agents will log the request URI in some
place where it might be visible to third parties. Servers can use POST-based
form submission instead

***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_208:--- 7784,7790 ----

An approach that limits the loss of privacy would
be for a user agent to omit the sending of Accept-Language headers
by default, and to ask the! user whether it should start sending Accept-Language
headers to a server if it detects, by looking for any Vary response-header
fields generated by the server, that such sending could improve
the quality of service.

*** 7781,7787 ****

An approach that limits the loss of privacy would
be for a user agent to omit the sending of Accept-Language headers
by default, and to ask the! user whether or not to start sending Accept-Language
headers to a server if it detects, by looking for any Vary response-header
fields generated by the server, that such sending could improve
the quality of service.

***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_209:--- 7797,7806 ---- users not behind a proxy, the network address
of the host running the user agent will also serve as a long-lived user
identifier. In environments where proxies are used to enhance
privacy, user agents! should be conservative in offering accept header
configuration options to end users. As an extreme privacy measure,
proxies could filter the accept headers in relayed requests. General
purpose user agents which! provide a high degree of header configurability should
warn users about the loss of privacy which can be involved.

*** 7794,7803 **** users not behind a proxy, the network address
of the host running the user agent will also serve as a long-lived user
identifier. In environments where proxies are used to enhance
privacy, user agents! SHOULD be conservative in offering accept header
configuration options to end users. As an extreme privacy measure,
proxies could filter the accept headers in relayed requests. General
purpose user agents which! provide a high degree of header configurability SHOULD
warn users about the loss of privacy which can be involved.

***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_210:--- 7840,7846 ---- confirmation of an IP number/DNS name association,
rather than caching the result of previous host name lookups. Many
platforms already can cache host name lookups locally when appropriate,
and they SHOULD be! configured to do so. These lookups should be cached,
however, only when the TTL (Time To Live) information reported
by the name server makes it likely that the cached information will remain
useful.

*** 7837,7844 **** confirmation of an IP number/DNS name association,
rather than caching the result of previous host name lookups. Many
platforms already can cache host name lookups locally when appropriate,
and they SHOULD be! configured to do so. It is proper for these
lookups to be cached,! however, only when the TTL (Time To Live) information reported
by the name server makes it likely that the cached information will remain
useful.

If a single server supports multiple organizations
that do not trust one! another, then it must check the values of Location
and Content-Location headers in responses that are generated under
control of said organizations to make sure that they do not
attempt to invalidate resources over which they have no authority.*** 7861,7867 **** 15.4 Location Headers and Spoofing

If a single server supports multiple organizations
that do not trust one! another, then it MUST check the values of Location
and Content-Location headers in responses that are generated under
control of said organizations to make sure that they do not
attempt to invalidate resources over which they have no authority.***************Reason:

. Clients which have been idle for an extended
period following which! the server may wish to cause the client
to reprompt the user for credentials.

. Applications which include a session termination
indication (such as*** 7894,7900 **** application's security model include but are
not limited to:

. Clients which have been idle for an extended
period following which! the server might wish to cause the client
to reprompt the user for credentials.

. Applications which include a session termination
indication (such as***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_213:--- 7915,7921 ----

15.7 Proxies and Caching

! By their very nature, HTTP proxies are men-in-the-middle,
and may represent an opportunity for man-in-the-middle
attacks. Compromise of the systems on which the proxies run can result
in serious security and privacy problems. Proxies have access to security-related
information,*** 7913,7919 ****

15.7 Proxies and Caching

! By their very nature, HTTP proxies are men-in-the-middle,
and represent an opportunity for man-in-the-middle
attacks. Compromise of the systems on which the proxies run can result
in serious security and privacy problems. Proxies have access to security-related
information,***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_214:--- 7941,7947 ---- Caching proxies provide additional potential
vulnerabilities, since the contents of the cache represent an attractive
target for malicious exploitation. Because cache contents persist
after an HTTP request is! complete, an attack on the cache may reveal information
long after a user believes that the information has been
removed from the network. Therefore, cache contents should be protected
as sensitive information.

*** 7939,7945 **** Caching proxies provide additional potential
vulnerabilities, since the contents of the cache represent an attractive
target for malicious exploitation. Because cache contents persist
after an HTTP request is! complete, an attack on the cache might reveal information
long after a user believes that the information has been
removed from the network. Therefore, cache contents should be protected
as sensitive information.

***************Reason:

Rephrased to avoid keywords; not normative.

---------------** issue MMS_AUDIT_ITEM_215:--- 8443,8449 ---- However, we recommend that applications, when
parsing such headers, recognize a single LF as a line terminator and
ignore the leading CR.

! The character set of an entity-body should be labeled
as the lowest common denominator of the character codes used
within that body, with the exception that not labeling the entity is
preferred over labeling the entity with the labels US-ASCII or ISO-8859-1.
See section 3.7.1 and*** 8441,8447 **** However, we recommend that applications, when
parsing such headers, recognize a single LF as a line terminator and
ignore the leading CR.

! The character set of an entity-body SHOULD be labeled
as the lowest common denominator of the character codes used
within that body, with the exception that not labeling the entity is
preferred over labeling the entity with the labels US-ASCII or ISO-8859-1.
See section 3.7.1 and***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_216:--- 8452,8469 ---- Additional rules for requirements on parsing
and encoding of dates and other potential problems with date encodings
include:

! . HTTP/1.1 clients and caches should
assume that an RFC-850 date which appears
to be more than 50 years in the future is in fact in the past (this
helps solve the "year 2000" problem).! . An HTTP/1.1 implementation may
internally represent a parsed Expires date as
earlier than the proper value, but MUST NOT internally represent
a parsed Expires date as later than the proper value.! . All expiration-related calculations
must be done in GMT. The local time zone MUST
NOT influence the calculation or comparison of an age or expiration
time. . If an HTTP header incorrectly
carries a date value with a time zone! other than GMT, it
must be converted into GMT using the most conservative possible
conversion.

19.4 Differences Between HTTP Entities and RFC
2045 Entities*** 8450,8467 **** Additional rules for requirements on parsing
and encoding of dates and other potential problems with date encodings
include:

! . HTTP/1.1 clients and caches SHOULD
assume that an RFC-850 date which appears
to be more than 50 years in the future is in fact in the past (this
helps solve the "year 2000" problem).! . An HTTP/1.1 implementation MAY
internally represent a parsed Expires date as
earlier than the proper value, but MUST NOT internally represent
a parsed Expires date as later than the proper value.! . All expiration-related calculations
MUST be done in GMT. The local time zone MUST
NOT influence the calculation or comparison of an age or expiration
time. . If an HTTP header incorrectly
carries a date value with a time zone! other than GMT, it
MUST be converted into GMT using the most conservative possible
conversion.

Actually, all this about how implementations MUST be done internallyis, I think, improper - all that matters is whether or not they
get itright on the wire... (I don't disagree that these are good ways
to getit right, just with whether or not the spec should say anything
abouthow an implementation is done beyond its external behaviour).

necessary. Proxies and gateways from MIME environments
to HTTP also need! to be aware of the differences because some conversions
may be required.

19.4.1 MIME-Version

HTTP is not a MIME-compliant protocol (see appendix
19.4). However,! HTTP/1.1 messages may include a single MIME-Version
general-header field to indicate what version of the MIME protocol
was used to construct the message. Use of the MIME-Version header field
indicates that the message is in full compliance with the MIME protocol
(as defined in RFC*** 8486,8498 **** INTERNET-DRAFT
HTTP/1.1 Friday,
March 13, 1998

necessary. Proxies and gateways from MIME environments
to HTTP also need! to be aware of the differences because some conversions
might be required.

19.4.1 MIME-Version

HTTP is not a MIME-compliant protocol (see appendix
19.4). However,! HTTP/1.1 messages MAY include a single MIME-Version
general-header field to indicate what version of the MIME protocol
was used to construct the message. Use of the MIME-Version header field
indicates that the message is in full compliance with the MIME protocol
(as defined in RFC***************Reason:

---------------** issue MMS_AUDIT_ITEM_218:--- 8522,8528 ---- Where it is possible, a proxy or gateway from
HTTP to a strict RFC 2045 environment SHOULD translate all line breaks
within the text media types described in section 3.7.1 of this document
to the RFC 2045 canonical! form of CRLF. Note, however, that this may be complicated
by the presence of a Content-Encoding and by the fact
that HTTP allows the use of some character sets which do not use octets
13 and 10 to represent CR and LF, as is the case for some multi-byte character
sets.*** 8520,8526 **** Where it is possible, a proxy or gateway from
HTTP to a strict RFC 2045 environment SHOULD translate all line breaks
within the text media types described in section 3.7.1 of this document
to the RFC 2045 canonical! form of CRLF. Note, however, that this might be complicated
by the presence of a Content-Encoding and by the fact
that HTTP allows the use of some character sets which do not use octets
13 and 10 to represent CR and LF, as is the case for some multi-byte character
sets.***************Reason:

HTTP implementations which share code with MHTML
[45] implementations! should be aware of MIME line length limitations.
Since HTTP does not have this limitation, HTTP does not fold long
lines. MHTML messages being transported by HTTP follow all conventions
of MHTML, including line length limitations and folding, canonicalization,
etc., since HTTP transports all message-bodies as payload (see
section 3.7.2) and does! not interpret the content or any MIME header lines
that may be contained therein.

*** 8610,8621 **** 19.4.7 MHTML and Line Length Limitations

HTTP implementations which share code with MHTML
[45] implementations! SHOULD be aware of MIME line length limitations.
Since HTTP does not have this limitation, HTTP does not fold long
lines. MHTML messages being transported by HTTP follow all conventions
of MHTML, including line length limitations and folding, canonicalization,
etc., since HTTP transports all message-bodies as payload (see
section 3.7.2) and does! not interpret the content or any MIME header lines
that might be contained therein.

RFC 1945 and RFC 2068 document protocol elements
used by some existing HTTP implementations, but not consistently and
correctly across most! HTTP/1.1 applications. Implementers should be aware
of these features, but cannot rely upon their presence in, or interoperability
with, other HTTP/1.1 applications. Some of these describe
proposed experimental features, and some describe features that experimental
deployment found*** 8623,8629 ****

RFC 1945 and RFC 2068 document protocol elements
used by some existing HTTP implementations, but not consistently and
correctly across most! HTTP/1.1 applications. Implementers are advised to
be aware of these features, but cannot rely upon their presence in, or interoperability
with, other HTTP/1.1 applications. Some of these describe
proposed experimental features, and some describe features that experimental
deployment found***************Reason:

Content-Disposition: attachment; filename="fname.ext"! The receiving user agent should not respect any directory
path! information that may seem to be present in the filename-parm
parameter, which is the only parameter believed to apply
to HTTP implementations at! this time. The filename should be treated as a terminal
component only.

! The implied suggestion is that the user agent should
not display the response, but directly enter a `save response
as...' dialog.

See section 15.5 for Content-Disposition security
issues.*** 8650,8661 **** An example is

Content-Disposition: attachment; filename="fname.ext"! The receiving user agent SHOULD NOT respect any directory
path! information present in the filename-parm parameter, which is the only parameter believed to apply
to HTTP implementations at! this time. The filename SHOULD be treated as a terminal
component only.

! The implied suggestion is that the user agent SHOULD
NOT display the response, but directly enter a `save response
as...' dialog.

. Servers MUST report a 400
(Bad Request) error if an HTTP/1.1 request does not
include a Host request-header.*** 8747,8753 ****

. Both clients and servers
MUST support the Host request-header.

! . A client that sends an HTTP/1.1
request MUST send a Host header.

. Servers MUST report a 400
(Bad Request) error if an HTTP/1.1 request does not
include a Host request-header.***************Reason:

Upcase keyword; normative.

---------------** issue MMS_AUDIT_ITEM_223:--- 8758,8766 ----

19.6.2 Compatibility with HTTP/1.0 Persistent
Connections

! Some clients and servers may wish to be compatible
with some previous implementations of persistent connections in
HTTP/1.0 clients and! servers. Persistent connections in HTTP/1.0 must
be explicitly negotiated as they are not the default behavior.
HTTP/1.0 experimental implementations of persistent connections are
faulty, and the new facilities in HTTP/1.1 are designed to rectify
these problems. The*** 8756,8764 ****

19.6.2 Compatibility with HTTP/1.0 Persistent
Connections

! Some clients and servers might wish to be compatible
with some previous implementations of persistent connections in
HTTP/1.0 clients and! servers. Persistent connections in HTTP/1.0 are explicitly negotiated as they are not the default behavior.
HTTP/1.0 experimental implementations of persistent connections are
faulty, and the new facilities in HTTP/1.1 are designed to rectify
these problems. The***************Reason: