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

From: Hidetaka Ohto (
Date: Fri, Jun 09 2000

  • Next message: Graham Klyne: "Re: Comments on draft-ietf-ohto-ccpp-exchange-00"

    Message-ID: <014501bfd25e$9e0d6520$>
    From: "Hidetaka Ohto" <>
    To: "Koen Holtman" <>, <>
    Date: Fri, 9 Jun 2000 18:04:00 -0400
    Subject: Re: Comments on draft-ietf-ohto-ccpp-exchange-00
    Thank you very much for your comments.
    > 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.
    I know the controvercy. 
    I believe that HTTP Extension Framework provides the better way of 
    extending HTTP/1.1 but I also admit there may be concerns about deployment.
    (HTTP Extension Framework has been implemented in Jigsaw Web
    server though. )
    > ##   The absoluteURI in the Profile header field addresses an entity of at
    > ##   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.
    > 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.
    Right. I suppose mostly the dereferencing would be done by HTTP.
    In Section 6. Example in the spec, I use HTTP for dereferencing.
    Actually, I thought that how to dereference the URI is beyond the 
    scope of this protocol but I think I should try to explain it more.
    > 1.2 if the URI is a http: URI, then
    <snip />
    Those are valuable comments. Thanks.
    > ##   The generation method of the profile-diff-name is as follows: 
    > A am a bit concerned about this MD5-attaching mechanism. 
    > 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.
    That would be a good idea.
    > Also, if you are serious about making Vary more useful, you should
    > also specify a 'preferred http-ext namespace number' (for example 50),
    Right. I should have mentioned that.
    Actually, the first version of cc/pp exchange protocol spec has 
    similar notations. 
    Excerpted from
    "The header prefix might be generated dynamically when the name 
    space prefix is conflicted by another extension. 
    However the name space prefix should have a "preferred"
     name because of the cache efficiency. "
    > 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.
    I admit that's simpler.
    If you have further concerns, please make me know.
    > ##   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'.
    It makes sense to me a lot.
    > That is all I have, I hope it is useful.
    Thanks again for your thoughtful and valuable comments.
    It is definitely useful.
    Best Regards,
    -- Taka