From: firstname.lastname@example.org (Koen Holtman) Message-Id: <200006091906.VAA10193@wsooti09.win.tue.nl> To: email@example.com Date: Fri, 9 Jun 2000 21:06:20 +0200 (MET DST) Cc: firstname.lastname@example.org (Koen Holtman) Subject: Comments on draft-ietf-ohto-ccpp-exchange-00 Hi All, As promised at WWW9, I did a read-through of draft-ietf-ohto-ccpp-exchange-00. Here are some comments, text from the draft is quoted with "##". ## In this document we describe the CC/PP exchange protocol based on ## the HTTP Extension Framework. Note that the HTTP Extension Framework is bit controversial in the IETF: it is an open question if this should be used for (IETF or outside standards level) HTTP extensions in stead of just defining additional headers. I don't think there will be strong objections to you using HTTP-ext, but if you don't use it this will also be considered OK. Switching to my personal opinion: I believe that use of HTTP-ext might slow deployment: at least you should verify whether prospective cc/pp implementers are happy with doing the work of implementing (the necessary subset of) http-ext too. ## ##2. Basic requirements for CC/PP exchange protocol The basic requirements look really good, it is nice to have such a statement in the draft. ## The absoluteURI in the Profile header field addresses an entity of a ## CC/PP description which exists in the World Wide Web. As I indicated before at WWW9, I believe that some text on how to dereference these URIs would strengthen the protocol and make it more extensible. Below I will outline the protocol requirements I would like to see: [Here I use 'the client' for an entity which dereferences an URI to obtain a CC/PP description] 1. When an URI is dereferenced to obtain a CC/PP description 1.1 If the URI is not a http: scheme URI, this spec does not prescribe anything about the mechanism to dereference it. Baseline client implementations of this spec need not be able to reference non-http URIs. 1.2 if the URI is a http: URI, then 1.2.1 a conforming client should dereference it using a GET request in HTTP/1.0, HTTP/1.1, or a successor version of HTTP 1.2.2 if HTTP/1.0 is used, the client MUST include a Host: header in the request according to the requirements for Host: in the HTTP/1.1 specification 1.2.3 the client SHOULD include an Accept request-header with a single MIME type: Accept: [CC/PP description MIME type, to be defined] in its HTTP request, or the equivalent in a successor version of HTTP. This allows the server holding the CC/PP description to perform HTTP content negotiation on the request, so that alternative representations of the CC/PP description can be returned to end users with regular user agents, or future clients that implement a superset of this protocol. 1.2.4 The response can be cached according to the normal rules that apply to HTTP/1.x responses 22.214.171.124 The response can be re-used from a cache when it is still fresh in the sense of HTTP/1.1 or a successor version of that protocol, any MAY be re-used when stale if an appropriate warning about staleness in returned (see section ....). 126.96.36.199 If the response does not specify a freshness lifetime or other restrictions on caching, the client MAY use a heuristic to compute a freshness lifetime for the response, but this lifetime MUST NOT exceed 24 hours. [compare to section 13.2.4 of RFC 2616] Also, to ease the life of implementers of CC/PP profile caching systems, you might thinks about enumerating a subset of the HTTP/1.1 Cache-Control directives in this specification, with the comment that CC/PP repositories SHOULD NOT count on clients understanding any directives beyond these one. (see also draft-moore-using-http-00) ## ## The generation method of the profile-diff-name is as follows: ## ## 1. The MD5 algorithm is applied to the CC/PP description which is ## the value of the corresponding Profile-Diff header field. ## ## 2. The Base64 algorithm is applied to the output of step1. ## ## 3. Insert the profile-diff-number at the head of the output of ## step2. A am a bit concerned about this MD5-attaching mechanism. Its purpose seems to be to make life a bit easier for servers that want to send Vary, but this comes at the cost of implementation complexity and extra bytes on the wire for everybody. As an alternative, I suggest you specify: profile-diff-name = profile-diff-number [ "-" profile-diff-digest ] so that the digest can be left out if wanted. Also, if you are serious about making Vary more useful, you should also specify a 'preferred http-ext namespace number' (for example 50), which all user agents should use, if possible, when extending the request with a Profile http-ext header. If user agents always generate these numbers semi-randomly. then two xx-Profile: yyy headers on two different requests but with the same yyy will seldom match because they have a different xx number. But aside from that, unless there are strong indications that header length restrictions are really a problem, I'd rather see the whole profile-diff header system disappear, with all information in these headers put directly into the Profile header. ## The warn-code assignes three digits. The "1xx" indicates the status ## of the CC/PP description(e.g. it is fresh or stale). The "2xx" ## indicates the type of the content adaptation applied to the ## message(e.g. content selection, content transformation, or content ## generation). This decomposition into 1xx and 2xx is nice, but you are not very extensible in adding new warn codes yet, as the spec now is silent on how clients should interpret new warn codes unknown to them. There should be at least two classes (orthogonal to your 1xx and 2xx distinction now, so I guess you should add an extra number to the current codes): say a 1xx class for 'serious -- if you get a code in this class and don't understand it, inform the end user', and a 2xx 'non-serious -- if you get a code in this class and don't understand it, ignore it and keep silent'. That is all I have, I hope it is useful. Koen.