W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1997

RE: questions and nits on version 3 spec.

From: Yaron Goland <yarong@microsoft.com>
Date: Tue, 14 Oct 1997 14:52:37 -0700
Message-ID: <11352BDEEB92CF119F3F00805F14F48503DFC7D0@RED-44-MSG.dns.microsoft.com>
To: "'Jim Davis'" <jdavis@parc.xerox.com>, w3c-dist-auth@w3.org
Why aren't State Tokens XML? - This is actually something we had looked
at and even came up with a syntax for. The real answer to the question
is that it turned out to be huge and hard to handle, for humans. We
could specify them as a URI in about ten lines of text or as XML in
three pages. Still, it is definitely worth looking at again.

If-None-State-Match - Because If-None-State-Match, by its very
definition, is an AND operations. It is defined as meaning "If none of
these state tokens match the current state of the resource then
execute." So what would an AND/OR switch determine?

Citing ACL draft - That is difficult because it doesn't currently exist.
However it will be released this week so we can put in a citation at
that point.

5.2.4 Interaction with other methods - Yup, typo. =) Thanks for pointing
it out, I will fix it. - The answer is that the reset can only be performed by the
lock owner. I will fix the language. - Will fix if not already fixed. - I suspect this is an error that occurred in turning off
automatic hyperlinking in Word. I will see that it is fixed.

DAV and the naming conventions for its XML tags - I absolutely agree. I
am actually preparing a new proposal to the authors about how to name
properties so that it looks more like XML and so that the naming is

	Thanks for the excellent comments,	

> -----Original Message-----
> From:	Jim Davis [SMTP:jdavis@parc.xerox.com]
> Sent:	Tuesday, October 14, 1997 11:38 AM
> To:	w3c-dist-auth@w3.org
> Subject:	questions and nits on version 3 spec.
> Apologies if these have already been discussed:
> 1. Why don't State Tokens and Lock Tokens use XML?  I see no reason
> one
> could not put XML into the header of an HTTP request (unless the
> length is
> an issue).  As is, this introduces a new, and somewhat odd syntax for
> encoding tagged data
> 2. Re If-None-State-Match (4.3.2) Could someone explain why there's no
> requirement for AND and OR keywords for this header?  It seems to me
> that
> the semantics defined in the spec are those of "OR" (if OR were
> allowed
> that is), and that "AND" also makes sense.  Even if no one has come up
> with
> an application that requires it now, surely it's possible that someone
> might in the future.  Is it very expensive to support AND?  If not,
> then I
> would think that symmetry alone would argue for allowing AND and OR.
> 3. Re 5.1 what is the "access control draft" referred to here.  A
> citation
> would help.
> 4. Re: 5.2.4 Interaction with other methods.  Says "Only two methods,
> and DELETE, have side effects..." and then goes on to discuss MOVE and
> *COPY*.  Is something wrong here?
> 5. Re: "Every time a method is executed on the resource the
> timer
> is reset".  Does that include methods executed by others, or only the
> principal?
> i.e. if A has a lock on the object, and B goes a GET (which should
> succeed,
> regardless of the lock) then is the timer reset?  Seems like a bad
> idea.
> But if it *does* include methods invoked by others, then perhaps
> 'executed' should be 'executed without error'.  Otherwise, if A holds
> a
> lock, goes away, and B tried to get the lock, and fails, the mere
> attempt
> to get the lock will reset the timer.  How ironic.
> 6. Re: Typo: "is used by the principal on arbitrary method".
> Probably missing an "an" before "arbitrary"
> 7. Re LOCKENTRY.  What's that "HYPERLINK" doing in the Schema?
> 8. In my opinion, DAV should use a consistent naming convention for
> its XML
> tags.  At present it's a mix of MixedCase and hyphen-tags and even
> some
> alllowercase.
> best regards
> Jim
> ------------------------------------
> http://www.parc.xerox.com/jdavis/
> 650-812-4301
Received on Tuesday, 14 October 1997 19:06:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:12 UTC