Subject: Re: [ACL] Re: Last minute ACL stuff (was DAV:unauthenticated usage)

From: Julian Reschke <[email-masked]>
Date: Sun, 18 Apr 2004 21:06:23 +0200

Geoffrey M Clemm wrote:

> I agree that it makes sense to remove the "protected" qualifier.
> Julian: Can you take care of this?
> 
> Cheers,
> Geoff

We're talking about ... 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.html#PROPERTY_inherited-acl-set> 
and Eric's request on the ACL mailing list 
(<http://mailman.webdav.org/pipermail/acl/2004-April/001815.html>).

I agree that servers should be allowed not to protect that property. I'm 
not so sure about the best wording, how about saying...:

To stay consistent with other property descriptions, I'd prefer to 
remove the word "protected" but also to add...:

"Servers MAY implement DAV:inherited-acl-set as protected property."

I'll make that change for now; if people feel we shouldn't make that 
change they need to speak up *now*, as we are currently doing the last 
edits on the *RFC* document which then will be published Really Soon.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Ted Hardie <[email-masked]>
Date: Mon, 19 Apr 2004 10:06:44 -0700

Are you talking about making this change during AUTH 48?

This is not a time at which substantive changes are allowed.

You will note that this draft has been significantly delayed in
publication because of the changes which were included during
the last round, including a need to return the whole document
to the IESG agenda for re-approval and a restart in the
RFC Editor's queue.  Doing this again will raise very serious
questions about the extent to which this working group has
reviewed specs sent to the IESG/RFC Editor.

			Ted Hardie
			co-AD, Applications Area

At 9:06 PM +0200 04/18/2004, Julian Reschke wrote:
>I agree that servers should be allowed not to protect that property. 
>I'm not so sure about the best wording, how about saying...:
>
>change they need to speak up *now*, as we are currently doing the 
>last edits on the *RFC* document which then will be published Really 
>Soon.
>
>Regards, Julian
>
>
>--

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Apr 2004 19:28:21 +0200

> reviewed specs sent to the IESG/RFC Editor.

Yes, I indeed was talking about AUTH48, and I'm aware of the implications.

In this case a property that everybody thought was optionally changeable 
indeed wasn't. Removing the requirement that it's indeed non-writeable 
(= protected) doesn't change anything for clients and servers that don't 
want to support authoring; but it makes it legal for those who wish to 
do so. As a matter of fact, people that need the ability to change that 
property will likely support that in their servers no matter what the 
specs says about it, and thus this would end up on a future issue/errata 
list anyway. Therefore I think this is a good change that won't have any 
negative side effects.

On the other hand, I've been announcing that change because it *is* a 
change, and because we need feedback and full consensus on it. If you or 
the RFC-Editor feel this one is problematic, I'll be happy to roll back 
that change (= remove it from the issues list sent back to the RFC Editor).

For the record: I fully support the statement that drafts submitted for 
publication need to be of high quality; and I'm trying to enhance that 
quality by using the best tools available (rfc2629 format instead of 
Word, and complete change and issue tracking on everything we do between 
drafts).

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 19 Apr 2004 10:50:41 -0700

I reviewed the changes and I don't consider them substantive.  The 
sentence added that the property can be changed is on the borderline 
between "clarification" and "insubstantive change", as it doesn't 
change either client or server behavior.

There is a concern that this WG doesn't have as many active members as 
it needs to do careful review of new specs, but the ACL specification 
is actually quite mature (having been reviewed by quite a few people 
over a period of years) and has been implemented by more than one 
group, with some interoperability testing.

Lisa

On Apr 19, 2004, at 10:28 AM, Julian Reschke wrote:

> In this case a property that everybody thought was optionally 
> changeable indeed wasn't. Removing the requirement that it's indeed 
> non-writeable (= protected) doesn't change anything for clients and 
> servers that don't want to support authoring; but it makes it legal 
> for those who wish to do so. As a matter of fact, people that need the 
> ability to change that property will likely support that in their 
> servers no matter what the specs says about it, and thus this would 
> end up on a future issue/errata list anyway. Therefore I think this is 
> a good change that won't have any negative side effects.
>
> change, and because we need feedback and full consensus on it. If you 
> or the RFC-Editor feel this one is problematic, I'll be happy to roll 
> back that change (= remove it from the issues list sent back to the 
> RFC Editor).
>
> For the record: I fully support the statement that drafts submitted 
> for publication need to be of high quality; and I'm trying to enhance 
> that quality by using the best tools available (rfc2629 format instead 
> of Word, and complete change and issue tracking on everything we do 
> between drafts).
>
> Best regards, Julian
>
> -- 
> _______________________________________________
> acl mailing list
> [email-masked]
> http://mailman.webdav.org/mailman/listinfo/acl

---

From: Ted Hardie <[email-masked]>
Date: Mon, 19 Apr 2004 10:51:40 -0700

At 7:28 PM +0200 04/19/2004, Julian Reschke wrote:
>for those who wish to do so. As a matter of fact, people that need 
>the ability to change that property will likely support that in 
>their servers no matter what the specs says about it, and thus this 
>would end up on a future issue/errata list anyway. Therefore I think 
>this is a good change that won't have any negative side effects.
>
>On the other hand, I've been announcing that change because it *is* 
>a change, and because we need feedback and full consensus on it. If 
>you or the RFC-Editor feel this one is problematic, I'll be happy to 
>roll back that change (= remove it from the issues list sent back to 
>the RFC Editor).

It is not appropriate to make substantive changes to the document at this stage
of processing.  If this is a showstopper issue, you can ask the RFC Editor
to stop processing the document, and get the WG chairs to call for consensus
on the changes.  The draft will then have to go back through at least
IESG processing and possibly IETF last call.

Continuing to tweak the documents after they have completed processing
is hindering this group's ability to get a stable specification.  It is normal
to find things as people implement and deploy, but if you never issue
a final spec the number of people actually working with the documents
will remain low.

		regards,
			Ted Hardie

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Apr 2004 20:03:19 +0200

> IESG processing and possibly IETF last call.

IMHO, it's not a substantive change, and it's also not a showstopper. So 
if there's any doubt, let's not make it.

> a final spec the number of people actually working with the documents

Agreed. That's why we want to get the spec published (finally). So if 
there's any doubt about a particular change, let's not do it. Note that 
this is the only change that I'm aware that isn't a case of bug fixing 
or updating references.

Eric, would you agree not to do it (after all, you did ask for it), and 
just add it to a future errata document?

Regards, Julian

---

From: "Stanley Guan" <[email-masked]>
Date: Tue, 20 Apr 2004 14:39:49 -0700

Just curious why Element "property" instead of "prop" is 
used in the definition of Element principal:
   5.5.1 ACE Principal
   <!ELEMENT principal (href | all | authenticated | unauthenticated 
          | property | self)>

The content of Element "prop" is defined to be ANY with further
clarafication (RFC 2518):
   "The prop XML element is a generic container for
   properties defined on resources.  All elements inside a prop XML
   element MUST define properties related to the resource.  No other
   elements may be used inside of a prop element."

It seems to me that "prop" can be very well suited for Element
principal's definition.  Besides, Element "prop" is also referenced
in the definitions of REPORT's sub-elements.

Will appreciate your inputs!

-Stanley