Comments on draft-ietf-ohto-ccpp-exchange-00

From: Koen Holtman (
Date: Fri, Jun 09 2000

  • Next message: Hidetaka Ohto: "Re: Comments on draft-ietf-ohto-ccpp-exchange-00"

    From: (Koen Holtman)
    Message-Id: <>
    Date: Fri, 9 Jun 2000 21:06:20 +0200 (MET DST)
    Cc: (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[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
    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
    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 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 ....). 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.