Comments on 28 Jan 2003 "Chips"

Hi Olivier,

I just enjoyed a read-through of the 28 Jan 2003 "Chips" [1].
I have a couple of comments that I'll just sketch out here,
and if you plan to revise the document, we can talk about
them in more detail at that time.
 
Thanks!

  _Ian

[1] http://www.w3.org/TR/2003/NOTE-chips-20030128/
=============================================================

1) It would be good to harmonize some of the terminology with
   that used in the Architecture Document. For example, 
   "representation" rather than "instance of a resource". I think
   there may even be some errors due to mixing resource and
   representation. E.g., in section 1, "the HTTP Etag can be
   shared by idential resources that have different URIs." I'm not
   sure what that means.

   Similarly, in section 5.2, the expression "request a URI" is
   used; in the Arch Doc this would be "dereference a URI" (or
   "request a representation of a resource").

   Similarly, in 5.3.1, md5 sums are calculated on representations,
   not resources.

2) I think the analogy at the beginning of section 1 needs work.

3) 1.1.1: Change "Use short URIs as much as possible" to something
   like "Use short URIs" and then give the rationale as is done.
   I think "as much as possible" doesn't add anything.

4) In Guideline 7, does it make sense to include a reference to
   other negotiation specs such as CC/PP?

5) Guideline 8 feels out of place to me. This is guidance for
   content authors, and the links in question are not (in practice
   as far as I know) used by servers. Instead they are used by
   some rare user agents. Does this guideline belong in Chips?

6) 9.1.1. It might be useful to provide some guidance to content
   managers on when to use multiple choice v. when to pick one
   representation and serve it. Are there familiar scenarios that
   could be recounted?

7) 10.1.1. I think a reference to the Arch Doc here would be
   useful. See, for example:
    http://www.w3.org/TR/webarch/#metadata-inconsistencies

8) 10.2.II conflicts with the Architecture Document, which 
   says:
      
     "In general, a representation provider SHOULD NOT specify the 
      character encoding for XML data in protocol headers since the 
      data is self-describing."

   See http://www.w3.org/TR/webarch/#xml-media-types

9) 11.2.1: I can suggest another reason not to block indiscriminately:
   it is unlikely that a server manager knows every single agent that
   will be used to access the content, including some agents used by
   people with disabilities.

10) Add a reference to the Arch Doc in the References section.

-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447