draft-ietf-http-negotiate-scenario.00.txt

Mr Hardie,

I offer some comments on your negotiation scenarios draft ...

(1) You refer to the Holtman/Mutz draft as "Transport Content Negotiation
..." when it's title is actually "Transparent Content Negotiation ...".

(2) In section 4 you address the requirement to minimize bandwidth used,
but do not address the issue of round-trip delays which I understand are an
important consideration in the current HTTP negotiation design.

(3) From the HTTP discussion list I had understood that this was to be a
requirements document for HTTP negotiation, though I note your draft does
not make this claim.  Assuming we are working toward a statement of
requirements, I feel the requirements section of your draft is
insufficiently prominent and focused, and needs some development to become
a working statement of requirements.

>From an editorial point of view, I would suggest listing the requirements
as a list of brief bullet points, with subsections (where required) to
provide additional explanation.  I feel this would provide a focus for
specific discussion points.

>From a content point of view, maybe some more specific and even
controversial (?) requirements should be introduced, to provide a concrete
basis for debate; e.g.
(a) Define "negotiation" as an exchange of information ("negotiation
metadata") which may change the message data eventually transferred.
(b) The negotiation mechanisms should be easily accommodated within the
structure of the HTTP protocol.
(c) The negotiation mechanisms should be easily accommodated within the
structure of the extended SMTP protocol (?).
(d) The negotiation process must result in an agreed form of message data
to be transferred (?).
(e) A uniform mechanism for exchanging negotiation metadata should be
provided which can encompass all existing HTTP negotiation capabilities and
is extensible to future (unanticipated) negotiable features (?).
(f) Efficient negotiation should be possible in both 'pull' (e.g. HTTP
"GET") and 'push' (e.g. HTTP "PUT", "POST") message transfers (?).
(g) Negotiation metadata should be regarded as cacheable, and explicit
cache control mechanisms provided to forestall the introduction of ad-hoc
cache-busting techniques (?).
(h) The structure of the negotiation procedure should stand independently
of any particular message transfer protocol (generalizes (b), (c), (e)
above?).

I am sure that collectively we could pose many more requirements.

With regard to my point (e) I note that the Holtman/Mutz draft does not
meet this requirement, because the feature syntax does not allow the
specification of a fully qualified MIME content type, per the HTTP "Accept"
header.

Regards,

GK.
---

------------
Graham Klyne
GK@ACM.ORG

Received on Monday, 23 June 1997 03:07:27 UTC