RE: Using If and not failing

Previous conversation abridged: 

> > One of your proposals:
> > > 1) allow comma separated notation for tagged lists (to
> > > workaround proxy
> > > limitations)
> >
> > This completely breaks the syntax of the header for clients sending
> > requests to servers that don't immediately support 2518bis.  Clients
> > wouldn't actually be able to use commas for years because there is
> > currently no way to see if a server supports 2518bis.  I'm 
> pointing this
> > out because if we decide to do this, we have to be clear on
> > understanding it's not going to be very useful for a long time.
> 
> What you say is true and applies to *any* "new" feature in 
> RFC2518bis --
> therefore it makes sense to avoid them wherever possible 
> (thus the proposal
> to use the If header instead of inventing a new header).

I don't think my logic supports your conclusion.

Adding commas to the If header is *exactly* as disruptive as inventing a
new header.  
 - At first, clients will not support this, knowing that very few
servers support the new syntax or header, and having no easy way to
distinguish
 - Later, some clients may include logic to do both/either once many
servers support the new syntax or header
 - Finally, in a few years, most clients will move to the new paradigm,
*if* it adds value, once all servers are known to support the new syntax
or header.
 - If the change does not add sufficient value, clients will never
switch over.

Given that changing the syntax and adding a header are identical in
interoperability cost, if we rule out one solely because of the cost we
logically rule out the other.  

Lisa

Received on Sunday, 2 February 2003 09:38:15 UTC