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

From: Hidetaka Ohto (ohto@w3.org)
Date: Fri, Jun 09 2000

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

    Message-ID: <014501bfd25e$9e0d6520$f6001d12@w3.org>
    From: "Hidetaka Ohto" <ohto@w3.org>
    To: "Koen Holtman" <koen@win.tue.nl>, <www-ccpp-protocol@w3.org>
    Date: Fri, 9 Jun 2000 18:04:00 -0400
    Subject: Re: Comments on draft-ietf-ohto-ccpp-exchange-00
    
    
    Koen:
    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. http://www.w3.org/Jigsaw )
    
    > ##   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 http://www.w3.org/TR/1999/NOTE-CCPPexchange-19990129
    
    "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