- From: Lisa Dusseault <lisa@xythos.com>
- Date: Sun, 2 Feb 2003 06:38:14 -0800
- To: "'Julian Reschke'" <julian.reschke@gmx.de>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
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