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[1]. 

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

1.2.4.1 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 ....).

1.2.4.2 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 1[12]xx class for 'serious -- if you get a code
in this class and don't understand it, inform the end user', and a
2[12]xx '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.

Received on Friday, 9 June 2000 15:06:22 UTC