W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1998

RE: The meaning of life and death

From: Yaron Goland <yarong@microsoft.com>
Date: Wed, 22 Jul 1998 16:24:24 -0700
Message-ID: <3FF8121C9B6DD111812100805F31FC0D029716E9@red-msg-59.dns.microsoft.com>
To: "'Babich, Alan'" <ABabich@filenet.com>, w3c-dist-auth@w3.org
Yup.. definately a 412.

		Yaron

> -----Original Message-----
> From: Babich, Alan [mailto:ABabich@filenet.com]
> Sent: Wednesday, July 22, 1998 1:57 PM
> To: Yaron Goland; w3c-dist-auth@w3.org
> Subject: RE: The meaning of life and death
> 
> 
> > In the case of live properties it is up to the property's 
> > definition to
> > decide what transformations are allowed. So one could 
> imagine having a
> > property which states that if you submit a number in 
> > scientific notation
> > then it MUST be returned in scientific notation. There is no 
> > general rule,
> > it is up to each live property to decide what its behavior is.
> > 
> > 		Yaron
> 
> You're responding so fast that our e-mails are crossing
> on the wire. Thank you very much.
> 
> OK, so servers can make up any rules about live properties
> that they want to (or not). Good. But there is no way called out 
> by the spec. to publish such rules in WebDAV that I have 
> noticed. That would seem to make such rules out of band 
> vis a vis the spec.
> 
> What about a property based rule that says, "Live (a) property X
> must always be copied when you copy the underlying resource,
> and the copy must also be live (a)." Such a rule would
> seem to conflict with an "omit" tag for property X
> in the protocol when copying the underlying resource. Section
> 11.12.2 doesn't seem to address this conflict, so how is it 
> resolved -- the client proposes, the server disposes?
> (The destination server would have to enforce the rule, I 
> guess.) Any error codes, e.g., 412?
> 
> Alan Babich
> 
Received on Wednesday, 22 July 1998 19:34:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:47 GMT