Re: comments on draft-ietf-http-ext-mandatory-00.txt

At 20:01 3/26/98 +0100, Koen Holtman wrote:

>In general, I think that the draft is very clear, and nicely
>delineates its scope.  One exception to this is the `passed to upper
>layers' thing in section 3 which Dave already noted: this seems to be
>a requirement on the internals of an agent, and I do not know what to
>make of it exactly anyway.

Yes, I have removed it now.

>Specific comments:
>
>- Section 3:
>
>   `Relative extension identifiers are
>     interpreted relative to the IANA registry (see RFC 1808[4]).'
>
>  I can't find in 1808 how to `interpreted relative to the IANA
>  registry', and in general I am at a loss as to what you mean here.
>  Could you give an example?

The IANA "root" is not to be taken literally exactly for the reason that we
don't know what the root is. The meaning is that "anything that it not an
absolute URI" MUST be a registered IANA token.

I will reformulate this to make it clearer.

>- 3.1 Header Field Prefixes
>
>  BNF problem: what is called `header-Prefix' here was simply called
>  `prefix' earlier.

Good point - fixed.

>- also in 3.1:
>
>      `Agents SHOULD NOT reuse header-prefix values in the same message
>       unless explicitly allowed by the extension (see section 4.1 for a
>       discussion of the ultimate recipient of an extension declaration).'
>
>  The parenthetical remark is a bit strange (why is that discussion
>  relevant to that rule?), but the rule itself is clear.

The idea is that repeated extensions like a hit-metering type extension may
modify header field values or add new header fields within the same space
as it is to be considered as a single instance. I will clarify this point. 

>However, I
>  realised yesterday that this rule alone will not prevent all
>  possible clashes of header-prefix values.  A case where it can still
>  go wrong:

You are right that header field prefixes don't prevent conflicts in cases
where a non-mandatory aware proxy inserts a header using an already used
prefix.This can happen in any request as well as any response and the only
way around this is to use parameters in the extension declaration instead
of header fields.

>   Overall however (and I have said this before), I think the whole
>   dynamic header allocation stuff is just useless cruft which should
>   be removed rather than fixed.  It is both easier to code and more
>   efficient to use ext-extensions if one needs to convey extension
>   parameters.

This is difficult ground as we are seeing a lot of religion. I have sent
out a mail probing how people are likely to actually use the specification.

>- section 5:
>
>   `...by performing the following actions in the order they occur:'
>
>   I think you mean `in the order they are listed below'.

fixed.

>- 7. 510 Not Extended
>
>   It is not immediately clear from context that this section defines
>   a status code.
>
>   Also:
>
>    `The server SHOULD send back all the information necessary for the
>     client to issue an extended request. It is outside the scope of
>     this specification to specify how the extensions inform the client.'
>
>   Either delete this SHOULD or specify the information sending mechanism.

It should be a lowercase should and maybe with an explanation of why this
is the case. Added as an issue.

Thanks for your comments!

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Saturday, 11 April 1998 04:40:03 UTC