Comments on OPTIONS draft

Below are my comments on draft-ietf-http-options-01.txt.

1. As currently specified, the "RFC" compliance token is ambiguous.  For 
example, if a client discovers that an HTTP/1.1 server "unconditionally" 
supports RFC 2068, what can they assume from this?  I assume this means 
that all MUST behavior is supported, but what about MAY and SHOULD 
behavior?  Does "unconditional" mean that all features in Appendix 19.6 of 
RFC 2068 are supported (PATCH, LINK, UNLINK), or does "unconditional" apply 
only to the mainstream methods?  As for headers, if a server 
unconditionally supports RFC 2068, does this mean the server supports the 
Content-MD5 header (which is "MAY" functionality)?

I suspect that each RFC will have issues similar to these.  What would be 
helpful is to provide a document which describes *exactly* what it means to 
have unconditional compliance with each RFC, and to have this information 
be part of the registry maintained by IANA, much as each MIME type has an 
associated description of that type.

2. Similarly, the meaning of the "cond" option-param is completely 
ambiguous.  As near as I can tell, if a client receives a Compliance header 
which states "rfc=2068;cond" the client can assume absolutely nothing about 
the server's behavior beyond what is stated in the Public header, or in HDR 
compliance tokens.

I think the token space for option-params also needs to be controlled by 
IANA, and each token needs to have a description of what that token means. 
 In the WebDAV working group, it is likely that locking capability will be 
optional (MAY) capability, but will still be widely supported.  I'd like to 
have the option of defining an option-param to indicate that locking is (or 
is not) supported, for example, "rfc=nnnn;cond;nolock"

3. It is possible to express contradictory information between the Public 
and the Compliance header. For example, the Public header could list all 
RFC 2068 methods except PUT, and the Compliance header could state "rfc=  
2068;uncond".  I think there should be a sentence indicating that this is 
an error, or precedence rules should be created, such as, "the Compliance 
header takes precedence over the Public header."

4. I agree with Henrik that the "PEP" compliance token is premature.  If a 
registry is created to handle compliance tokens, and if PEP requires such a 
token (currently unclear), then the PEP RFC can have a PEP compliance token 
added to the registry.

5. BNF nits.  The production:

option-params = 1#(";" option-param)

Was intended to be:

option-params = 1*(";" option-param)

I don't think the intent was to have a comma then a semicolon for repeated 
options.  Similarly, the production:

Compliance = "Compliance" ":" ("*" | *(compliance-option))

should really be:

Compliance = "Compliance" ":" ("*" | 1#(compliance-option))

to be consistent with the examples.  Furthermore, I added the "1" since I 
don't believe the intent is to allow a Compliance header to be blank.

- Jim Whitehead <ejw@ics.uci.edu>

Received on Thursday, 7 August 1997 11:37:24 UTC