Re: Comments on OPTIONS draft

Jim Whitehead writes:
    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.

Just to amplify what other people have already said: not only
does RFC2068 define what it means by MUST/SHOULD/MAY, but there
is another document, RFC2119 ("Key words for use in RFCs to
Indicate Requirement Levels", by Scott Bradner) that makes this
explicit for other RFCs, as well.  RFC2119 is a "Best Current
Practices", which means it is not obligatory, and it doesn't
explicitly use the terms "conditional" or "unconditional".

However, I think there is general agreement that Brader's
document is the appropriate way to define MUST/SHOULD/MAY,
and so in the next revision of the OPTIONS draft, I'll add,
after the existing text:

    The option-param is used to provide additional parameters.
    Unconditional compliance with a compliance-option is indicated
    using the "uncond" option-param; for example, "rfc=1945;uncond".
    Conditional compliance is indicated using the "cond" option-param;
    for example, "HDR=Authorization;uncond".  Additional option-param
    values might be defined as part of another specification.

language mostly stolen from RFC2068:

    For the purposes of this header field, an implementation that
    satisfies all the MUST and all the SHOULD requirements for its
    protocols is defined as "unconditionally compliant"; one that
    satisfies all the MUST requirements but not all the SHOULD
    requirements for its protocols is defined as "conditionally
    compliant."  See also RFC2119 for a discussion of the terms
    MUST and SHOULD.	

As for "MAY" functionality: the whole point of MAY is that it
allows something, but in no way requires (or bans) anything,
so I don't think it's worth including a compliance-option for
this.  Regarding your specific example of Content-MD5, one
could either use
	Compliance: HDR=Content-MD5
or one could (in principle, and only if this is really necesary)
write up an RFC describing exactly what we agree that it means to
comply with Content-MD5, and then use that RFC #.

    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"

I actually think it would be better to have an RFC mmmm that describes
locking, and then use:
	Compliance: rfc=nnnn,rfc=mmmm
rather than trying to get too fancy with parameters.  This is
especially true for anything that might involve the proxies.

It might still be worth having an IANA registry for the token
space.

    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."

Good point.

    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.
    
Your message says "comments on draft-ietf-http-options-01.txt",
but the PEP stuff was only in draft -00.txt, and had already
been removed when I submitted the draft -01.txt document.

    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. 

Right, my mistake (haste makes waste).

    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.
    
Almost.  The "*" should be a "#", but it isn't a "1#" because
it definitely is meaningful to have an emply Compliance header in
a response.

Digression: I considered using different header names for requests
and responses (e.g., meaning "Do-you-comply-with" and
"Yes-I-comply-with"); using just one header name ("Compliance")
was partly my laziness, and partly because I get flamed whenever
I suggest that we need more headers, rather than fewer.  But
maybe using two different names would help people to understand
this proposal more easily.

Anyway, in the context of the current proposal, it says in section
2:
      - A (new) Compliance header is proposed, which allows a
        client to specify exactly what options it is asking about,
        and which allows a server to specify exactly what subset of
        those options are supported.

but in the definition of the Compliance header, it says:
						    In a request
    message, this header lists the set of options that a client
    wishes to know about.  In a response message, this header
    lists the set of options that the server complies with.

I guess this should say "lists the subset of the requested
options", rather than "lists the set of options".

-Jeff

Received on Friday, 8 August 1997 16:32:16 UTC