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

From: Graham Klyne (GK@dial.pipex.com)
Date: Fri, Jun 09 2000

  • Next message: Koen Holtman: "Re: Comments on draft-ietf-ohto-ccpp-exchange-00"

    Message-Id: <4.3.1.2.20000609211056.00c4ea00@pop.dial.pipex.com>
    Date: Fri, 09 Jun 2000 21:19:08 +0100
    To: koen@win.tue.nl (Koen Holtman)
    From: Graham Klyne <GK@dial.pipex.com>
    Cc: www-ccpp-protocol@w3.org
    Subject: Re: Comments on draft-ietf-ohto-ccpp-exchange-00
    
    Hi Koen,
    
    At 09:06 PM 6/9/00 +0200, Koen Holtman wrote:
    >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.
    
    I didn't really appreciate what you meant before, but now I see your text 
    it looks very reasonable.
    
    >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.
    
    Broadly, I agree, but probably for different reasons.
    
    Did you see the proposal I made to not try and carry profile structuring 
    information as part of the protocol?
    
    >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.
    
    Interesting point... isn't this something that might be addressed more 
    generally in HTTP extensions?  (I'm tempted to say that Vary: might be made 
    extension-aware, but that's too tall an order.)
    
    #g
    
    ------------
    Graham Klyne
    (GK@ACM.ORG)