draft-ietf-http-negotiation-02.txt

Sirs,

I have recently read through 'draft-ietf-http-negotiation-02.txt' with an
interest in applying some aspects of the negotiation features to messaging
environments.

As a result of this I have a number of questions and comments regarding
this draft, which I would like to put to you...

* Section 1.2

Typo?: "To make it easier to future negotiation schemes..."

* Section 2.1

Description of "variant":  do you have any example of a resource variant
which is not subject to negotiation?

Description of "server": the description implies that sending back a
response is always the primary purpose of a server.  What about HTTP "POST"
operations or "mailto:..." URLs?

* Section 2.2

"transparently negotiable resource":  I was confused for a while by mention
of the "Alternates" header without reference to the fact that it is defined
later in the same draft.

"variant resource":  what constitutes a "simple" GET request?

* Section 3

Final paragraph:  I understood it was now normal practice to refer to RFC
2119 for meanings of MUST, SHOULD, etc.

* Section 4.9

I have the impression (but cannot remember from where) that there is a
character limit on the length of headers.  Is there any provision for
splitting long variant lists over multiple headers?

* Sections 4.9, 4.10

I find I am not clear how the negotiation scheme described might interact
with or be distinguished from other schemes, in view of the exhortation in
4.10.

I am particularly unnsure of the point number 2 in section 4.10:  does the
encouragement to re-use the "transport and caching protocol" extend to the
transparent negotiation header names?  If so, how might invocation of an
"other negotiation scheme" be distinguished from your transparent negotiation?

As an example, I was thinking of a hypothetical service which might be able
to offer a document in a very wide range of formats by performing
on-the-fly conversions on request.  It seems that this might be able to use
the transparent negotiation mechanism to select a file format to be
provided, but the comments in section 4.9 would seem to discourage this
kind of use.

* Section 5.6

Your reference to the "UTF-8 character set".  I understood UTF-8 to be an
*encoding scheme* for the *Unicode* and *ISO 10646* character set.

BTW, I have RFC 2044 as a reference for UTF-8.

* Section 6.2

1st para: typo: "and the and preferences".

* Sections 6.3, 6.4, 8.3, 8.4, 8.5:

It was not clear to me exactly how these sections are related.

For example section 6.3 defines 'fpred' but I did not note any explicit
reference to this in any header definition.  I notice that section 8.3
makes informal references to feature predicates without describing or
referencing how thay may arise.

This may be because I have missed something;  if so, I humbly suggest that
some cross-reference from the header description might be helpful.

* Section 8.3

How might feature extensions be used?  I assume this is somehow analagous
to MIME type parameters in 'Accept' headers, but it is not clear to me from
where the extension tokens might be derived.

* Section 8.3 (again)

Final example:  you suggest that 'Accept-Features: colordepth={5}'
satisfies the predicates 'colordepth=[4-]' and 'colordepth=[4-6]'.  But you
say that 'ftag={V}' implies that the tag is present with the value V and no
other value.   To me, 'colordepth=[4-6]' implies 'colordepth' is present
with values 4, 5 and 6.

Can you clarify what am I missing here?

* Section 8.5

I think more explanation is needed of the relationship between indicated
feature tags and the response given.

-----

Looking back over my comments, it seems they are all either trivial
drafting points or problems I am having in understanding the detail in the
draft.

The former, I hope you find helpful.  As to the latter, I offer the
suggestion that placing cross-references from the protocol header
descriptions (where the broad intent is fairly clear) to the relevant
descriptions in the preceding body of the document would make it easier to
follow for those of us who are not steeped in HTTP usage and lore.

Regarding the "Dimensions of negotiation" (section 4.7):
It seems to me that dimensions 1-3 are singled out by accident of history
(i.e. they are already present in HTTP) rather than that they have any
particular fundamental significance in the transparent negotiation
framework.  It would seem to me cleaner to define the feature negotiation
framework to encompass these "dimensions", then provide definitions of the
corresponding "Accept-" headers which make them equivalent to some
corresponding "feature-expr" in the "Accept-Feature" header.  In this way,
a path to a possible future single unified negotiation mechanism for HTTP
can be created, through future deprecation of the other "Accept-" headers.

Regards,

GK.
---

------------------------------------------------------
Graham Klyne,            GK@ACM.ORG
System Architect,        Graham.Klyne@Integralis.co.uk
Integralis Ltd.          tel: +44 1734 306060
UK                       fax: +44 1734 302143
------------------------------------------------------

Received on Friday, 6 June 1997 11:38:59 UTC