Subject: Re: I-D ACTION:draft-ietf-webdav-quota-07.txt

From: Julian Reschke <[email-masked]>
Date: Sun, 01 May 2005 20:48:52 +0200

Brian,

thanks for the fixes.

I'm still unhappy about two minor details (discussed earlier), but on 
the other hand this draft is definitively ready for a working group last 
call (during which we can discuss these and make a decision).

Lisa, Joe, please consider to start a WG last call (or alternatively, 
provide feedback on what's missing for that).

Best regards, Julian

---

From: Elias Sinderson <[email-masked]>
Date: Mon, 02 May 2005 10:50:48 -0700

[email-masked] wrote:

>A New Internet-Draft is available [...]
>  
>
Having reviewed the latest quota draft, as well as pertinent mailing 
list discussions over the last six months, I concur with Julias 
assessment of the draft. That is, what few issues remain can be 
addressed during last call and I am supportive of initiating this 
process using the existing process that Joe suggested for the last call 
on BIND.

I notice that there is no 'Product' entry for the quota spec in bugzilla 
- could we add this so that any remaining issues that are brought up may 
be tracked?

Cheers,
Elias

---

From: Julian Reschke <[email-masked]>
Date: Mon, 02 May 2005 21:57:21 +0200

> - could we add this so that any remaining issues that are brought up may 

Yes. We can do that. Lisa, Brian, is one of you two volunteering to 
become the "initial owner" for these bugs? (Brian, do you already have 
an accoung over at <http://ietf.cse.ucsc.edu:8080/bugzilla/>?)

Best regards, Julian

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

---

From: Brian Korver <[email-masked]>
Date: Wed, 04 May 2005 15:30:50 -0700

Julian,

I've already got an account there, so I can be the
"initial owner".

-brian
[email-masked]

Julian Reschke wrote:
>> process using the existing process that Joe suggested for the last 
>> call on BIND.
>>
>> I notice that there is no 'Product' entry for the quota spec in 
>> bugzilla - could we add this so that any remaining issues that are 
>> brought up may be tracked?
> 
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 05 May 2005 11:23:51 +0200

> I've already got an account there, so I can be the

Thanks Brian.

I have set up the BugZilla "product". As far as I am concerned, we've 
got all pieces in place to start a working group last call.

Lisa? Joe?

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 18 May 2005 18:53:48 -0700

> got all pieces in place to start a working group last call.

I am not sure about continuing with the bugzilla process if there's 
general agreement that it's broken.  Input is appreciated.

I do agree that quota is ready for last call, however it's not much use 
going through that if we can't pull together the reviews required by 
the new IESG processes.  Who is planning to implement quota?  Who can 
do a review of this draft during last call?

thanks,
Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 May 2005 09:23:18 +0200

Lisa Dusseault wrote:
> ...
> going through that if we can't pull together the reviews required by the 
> new IESG processes.  Who is planning to implement quota?  Who can do a 
> review of this draft during last call?
> ...

Please elaborate: what are the "new" IESG processes, and in which way do 
they pose new requirements on reviews? (Pointer?)

Best regards, Julian

---

From: Jim Luther <[email-masked]>
Date: Thu, 19 May 2005 07:30:24 -0700

On May 18, 2005, at 6:53 PM, Lisa Dusseault wrote:

> Who is planning to implement quota?

I plan to support the new quota properties in the Mac OS X WebDAV  
file system client.

- Jim

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 19 May 2005 07:33:41 -0700

A lot of it is described in here:
http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc- 
shepherding-05.txt

Other details depend on the AD.
Lisa

On May 19, 2005, at 12:23 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> ...
>> I do agree that quota is ready for last call, however it's not much  
>> use going through that if we can't pull together the reviews required  
>> by the new IESG processes.  Who is planning to implement quota?  Who  
>> can do a review of this draft during last call?
>> ...
>
> Please elaborate: what are the "new" IESG processes, and in which way  
> do they pose new requirements on reviews? (Pointer?)
>
> Best regards, Julian

---

From: Elias Sinderson <[email-masked]>
Date: Thu, 19 May 2005 23:35:24 -0700

> general agreement that it's broken.  Input is appreciated.

I found it to be very useful in that there was a single place to go to 
when I want to see the issues and their states for a given draft. Just 
out of curiosity, how many user accounts are there?

> can do a review of this draft during last call?

I will review QUOTA if there is a LC issued. The most recent draft looks 
quite good, although my latest reading was primarily wrt the resolution 
of issues that had been raised.

Best,
Elias

---

From: Julian Reschke <[email-masked]>
Date: Tue, 24 May 2005 13:59:19 +0200

> Other details depend on the AD.

OK,

I just read that draft. Questions:

a) Is this working group running under this process? If yes, since when?

b) Who are the document shepherds for the current working group 
documents that seem to be ready (BIND, REDIRECT, QUOTA)?

c) Section 1 asks...:

    1.b) Has the document had adequate review from both key WG members
         and key non-WG members?  Do you have any concerns about the
         depth or breadth of the reviews that have been performed?

How is adequateness determined? And are there any suggestions about how 
to get review by non-WG members? Speaking of which, how is it decided 
whether somebody doing a review is or is not a WG member? For instance, 
when Roy Fielding was giving feedback on specific BIND issues a few 
months ago, was he doing this as a WG member? (technically, anybody 
participating in this mailing list is a WG member after all)

Best regards,

Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 25 May 2005 10:17:13 -0700

> a) Is this working group running under this process? If yes, since 

I talk to Ted sometimes about his expectations.  We haven't had the 
need to discuss all the steps of the process, but it's my understanding 
that Ted expects chairs to sign off on the quality of WG drafts.  This 
kind of thing is also common discussion at IETF meetings so I guess 
I've kind of absorbed the new expectations without really having 
specific stuff to announce -- clearly we could have given the 
mailing-list-only people an earlier, if vague, warning of this.

> documents that seem to be ready (BIND, REDIRECT, QUOTA)?

I probably would be.

> How is adequateness determined? And are there any suggestions about 
> how to get review by non-WG members? Speaking of which, how is it 
> decided whether somebody doing a review is or is not a WG member? For 
> instance, when Roy Fielding was giving feedback on specific BIND 
> issues a few months ago, was he doing this as a WG member? 
> (technically, anybody participating in this mailing list is a WG 
> member after all)
>
The reason I've most commonly heard for review by non-WG members is to 
get people with broad experience (of different protocols, several 
standards, several WGs, and of Internet architecture as it relates to 
several standards) to review documents coming out of WGs, particularly 
small WGs.  If that's the only reason then somebody like Roy certainly 
qualifies as having broad experience and would be a great reviewer no 
matter how much they'd participated in the draft and the WG.

If, however, the intent is to get a document reviewed by somebody who 
wasn't involved in design "groupthink" then you'd want somebody fresh 
to the draft.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 May 2005 09:24:42 +0200

Lisa Dusseault wrote:
> I talk to Ted sometimes about his expectations.  We haven't had the need 
> to discuss all the steps of the process, but it's my understanding that 
> Ted expects chairs to sign off on the quality of WG drafts.  This kind 
> of thing is also common discussion at IETF meetings so I guess I've kind 
> of absorbed the new expectations without really having specific stuff to 
> announce -- clearly we could have given the mailing-list-only people an 
> earlier, if vague, warning of this.

So the answer is "yes, the WG runs under this process"?

>> documents that seem to be ready (BIND, REDIRECT, QUOTA)?

OK, let me rephrase this:

Will the working group chair(s) start shepherding some or all of these 
documents? If yes, which and when? If no, is there an expectation to the 
WG to do any specific additional work so they can?

Best regards,

Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 26 May 2005 10:51:51 -0700

> So the answer is "yes, the WG runs under this process"?

I'd say we're approaching this process, yes.  I didn't exactly shepherd 
the ACL draft -- at that time, the IESG wasn't yet including document 
shepherds in their group discussions -- but I did talk to IESG people 
directly about their "comment" issues on the ACL draft and found out 
what would resolve their issues, which is a big part of what a document 
shepherd is expected to do (rather than rely on the AD to do all the 
communication between IESG and WG as in the old model).

> documents? If yes, which and when? If no, is there an expectation to 
> the WG to do any specific additional work so they can?

Yes, I am willing to shepherd BIND, REDIRECT, QUOTA and/or RFC2518bis 
through this process -- provided they meet the bar.  For BIND, the 
document for which we have the most information, we still have 
underspecified areas and we haven't had the open and exploratory 
conversations to find out if we can firm those up, but the more 
difficult hurdle may well be the lack of reviews and implementors.  If 
we don't have the energy as a WG to finish that properly, it's my 
opinion that we could instead bring  BIND immediately to submission as 
an Informative RFC, where it would be an exemplary and high-quality 
example of that class.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 May 2005 20:50:00 +0200

> conversations to find out if we can firm those up, but the more 

If you think that, you really should either bring them up (if new), or 
follow-up on the discussions we had on the mailing list. Claiming that 
there are open issues but not participating in discussing them doesn't 
seem productive to me. See (for instance): 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005AprJun/0001.html>.

> difficult hurdle may well be the lack of reviews and implementors.  If 

We've got at least two implementations. How many do we need to for 
"Proposed"?

> an Informative RFC, where it would be an exemplary and high-quality 

That would indeed be preferrable to doing nothing at all (although, 
shouldn't it be "Experimental" instead???); however I personally think 
that the BIND spec really should be submitted for publication as 
"Proposed" (in contrast to REDIRECT which *currently* seems to only have 
one implementation).

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 26 May 2005 13:07:36 -0700

> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005AprJun/ 

At this point I'm willing to consider the Bind/DeltaV interaction  
issues to be closed, but I'm not satisfied with the latitude given to  
servers to behave entirely differently with respect to access control  
and certain key properties (getlastmodified and getetag), because I can  
foresee serious interoperability problems and burdens for client  
implementors.  I can keep repeating myself about this, and sometimes do  
so, but I see little point to get into "Yes it is" "no it isn't" "yes  
it is" conversations. I tend to simply leave the last email from me as  
a record of my continuing position.

> We've got at least two implementations. How many do we need to for  

That's an excellent question and we may find that there are different  
answers.  For peer-to-peer protocol I'd say 3 implementations in the  
works, because that means that it's not enough to simply have a  
bilateral agreement between two implementors -- with three you really  
need consensus and eventually can test three pairings of  
implementations.  For client/server standards like ours, I'd say two  
clients and two servers would ideally be in progress by the time you  
ask for a Proposed Standard.  If there's only one server in progress  
then the whole standard will be geared toward the architecture that one  
server happens to have.  Similarly if there's only one client in  
progress then there's serious risk that the standard will only reflect  
one set of use cases and environmental assumptions.  If you have no  
clients in progress then the standard will have a serious bias to  
reflect the needs of server implementors.

I note also that it seems to be difficult to get client implementations  
underway before an RFC is available (yet other WGs seem to do that) so  
sometimes it would be appropriate to settle for somewhat less -- e.g.  
thorough review by experienced client implementors who have considered  
what it would take to build an implementation and have some plans to do  
so later.

>> opinion that we could instead bring  BIND immediately to submission  
>> as an Informative RFC, where it would be an exemplary and  
>> high-quality example of that class.
>
> "Proposed" (in contrast to REDIRECT which *currently* seems to only  
> have one implementation).

Sorry; you're right, Experimental would probably be better.  REDIRECT  
could also go to experimental immediately.

Lisa

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 26 May 2005 22:09:25 +0200

Am 26.05.2005 um 19:51 schrieb Lisa Dusseault:
>> Will the working group chair(s) start shepherding some or all of 
>> these documents? If yes, which and when? If no, is there an 
>> expectation to the WG to do any specific additional work so they can?
>

I would like to express my extreme dissatisfaction with the WG chairs 
in handling the BIND spec. I perceive your behaviour during the last 
year as that of a total roadblock, not constructive and only paying lip 
service to installing and following any process which might bring 
progress to WebDAV and its goals.

If there is any way to bring this spec to "proposed" under the current 
chairs, it eludes me.

//Stefan

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 26 May 2005 13:30:01 -0700

On May 26, 2005, at 1:09 PM, Stefan Eissing wrote:
> year as that of a total roadblock, not constructive and only paying 
> lip service to installing and following any process which might bring 

Hi Stefan,

Believe me, I can fully understand your frustration here because I'm 
frustrated as well.  I wish I knew what to do.  I've tried several 
things over the past year to try to work through roadblocks, and 
dragged several other people into the process as well trying to solve 
problems.   It's clear to me as well as to others that those attempts 
have not worked.  I'm not sure what I can do besides assure you that 
I've made those attempts in good faith.  I'm sorry they've been 
failures and have tried to analyze whether they've been inherent 
failures, or failures in execution.

There may not be a way to bring this spec to proposed under the current 
arrangement.  One of the options I've discussed with Ted Hardie and 
others has been whether it would be possible to form a new WG from 
scratch to work on WebDAV extensions.  Sometimes with a new WG, there's 
a great opportunity to get commitments from new volunteers, all 
starting from the same position and not feeling like they have to work 
to come up to speed with an existing WG.  It's also an opportunity to 
remix roles, and to have fresh discussions about what the priorities 
are.

Lisa

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 26 May 2005 15:54:44 -0700

RFC 2026, which as near as I can tell is still the guiding process document
for the IETF (I am unable to find another RFC which explicitly obsoletes
2026), in Section 4.1.1 states:

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

It is my understanding that the BIND specification is "generally stable",
that it has indeed "resolved known design choices", is well-understood
within the community of activity WG participants, has received numerous
reviews over its 5+ year lifetime (and many reviews of its current, final
form), and is considered by many in the community to be a valuable
specification.

I will note that even though the IETF does not require implementation or
operational experience, it is my understanding that Julian Reschke has
implemented this specification. It would not surprise me if others have as
well.

I will also note that RFC 2026 explicitly states (section 4.1.1):

   Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.

I therefore request that the Chairs of this Working Group discharge their
duty, as described in Section 6.1.1 of RFC 2026:

   A standards action is initiated by a recommendation by the IETF
   Working group responsible for a specification to its Area Director,
   copied to the IETF Secretariat...

That is, please either recommend the specification to the Area Director, and
copy it to the Secretariat, or provide a detailed process specifying actions
that must be taken by the document editors and/or the Working Group (and
justification from RFC 2026 for these actions) for this to happen. 

- Jim

> There may not be a way to bring this spec to proposed under 
> the current arrangement.  One of the options I've discussed 
> with Ted Hardie and others has been whether it would be 
> possible to form a new WG from scratch to work on WebDAV 
> extensions.  Sometimes with a new WG, there's a great 
> opportunity to get commitments from new volunteers, all 
> starting from the same position and not feeling like they 
> have to work to come up to speed with an existing WG.  It's 
> also an opportunity to remix roles, and to have fresh 
> discussions about what the priorities are.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 May 2005 13:28:56 +0200

Jim,

thanks for reminding us about how the Standards Track is defined.

I completely agree that BIND should be submitted as "Proposed".

> implemented this specification. It would not surprise me if others have as

Let me add that it is also implemented in Apache Slide, see 
<http://jakarta.apache.org/slide/howto-bind.html>.

I'd also like to point out that the damage done in terms of lost 
interoperability will be far greater if the spec continues to be just 
another Internet Draft. If Lisa indeed is right in that there are 
underspecified areas that need fixing (I disagree), this is something 
that would need to be addressed in a future revision.

Let me also point out that one of the most important things for this WG 
to work on should be RFC2518bis, essentially publishing all the 
clarifications and simplications the people over here have worked on for 
many years. The ongoing fighting about specs that are essentially 
finished provably distracts us from that.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 May 2005 14:08:23 +0200

Lisa Dusseault wrote:
> 
> 
>>
>> If you think that, you really should either bring them up (if new), 
>> or  follow-up on the discussions we had on the mailing list. Claiming 
>> that  there are open issues but not participating in discussing them 
>> doesn't  seem productive to me. See (for instance):  

Lisa, this isn't helpful.

Jim W. and I had a long brainstorming on this issue; and I have written 
down what we talked about. Both Jim and I spent a considerable amount of 
time to get there. Again, this is in

It would be very nice if you could *read* that summary and follow up 
once you've done that. I'd also like to point out that you seem the be 
the single WG member who still has objections, so there *is* broad 
consensus on this issue.

> reflect the needs of server implementors.

Could you please clarify where the requirement for implementations 
actually comes from?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 May 2005 14:22:07 +0200

Lisa Dusseault wrote:
>> shouldn't it be "Experimental" instead???); however I personally 
>> think  that the BIND spec really should be submitted for publication 
>> as  "Proposed" (in contrast to REDIRECT which *currently* seems to 
>> only  have one implementation).
> 
> 

I'd prefer it to go to "Proposed" (that seems in line with the Standards 
Process). Anyway, if you feel it's done, why don't you start a WG last 
call for it?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 May 2005 15:25:02 +0200

Lisa Dusseault wrote:
> a great opportunity to get commitments from new volunteers, all starting 
> from the same position and not feeling like they have to work to come up 
> to speed with an existing WG.  It's also an opportunity to remix roles, 
> and to have fresh discussions about what the priorities are.
> 

I have trouble understanding how this could with those specs we have 
esentially finished. Are you seriously proposing to throw that stuff 
away and to restart from scratch?

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Sat, 28 May 2005 15:54:33 -0700

Were a new working group to be formed to work on WebDAV extensions, I 
personally wouldn't be making proposals for what to do with that stuff. 
  What would matter would be what the new WG decided was most important 
to work on, and if that had overlap with pre-existing work, then 
whether to work from pre-existing drafts.  If the bind, redirect and 
search features turn out to be important enough to garner sufficient 
support, then I expect those supporters would very likely want to work 
from the existing drafts and implementations.  Progress might then be 
very quick (again assuming sufficient support).

I'm still working with Ted to see if the current WG can be kept open 
and working, but if there's more support to shut down the WG than there 
is to keep it open, that would be good to know sooner rather than later 
-- it isn't too late for somebody to plan a BOF for Paris.

Lisa

On May 27, 2005, at 6:25 AM, Julian Reschke wrote:

>
> Lisa Dusseault wrote:
>> ...
>> There may not be a way to bring this spec to proposed under the 
>> current arrangement.  One of the options I've discussed with Ted 
>> Hardie and others has been whether it would be possible to form a new 
>> WG from scratch to work on WebDAV extensions.  Sometimes with a new 
>> WG, there's a great opportunity to get commitments from new 
>> volunteers, all starting from the same position and not feeling like 
>> they have to work to come up to speed with an existing WG.  It's also 
>> an opportunity to remix roles, and to have fresh discussions about 
>> what the priorities are.
>

---

From: Lisa Dusseault <[email-masked]>
Date: Sat, 28 May 2005 16:10:37 -0700

Hi Julian,

In WG meeting notes posted March 9 2004   
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0083>:

"Redirect: No major issues -- but no recent activity.  OTOH, there may  
not be many implementors.  Perhaps we can last call and require a  
minimum # of reviews."

I didn't press the issue because I recalled it being your stated  
intention that you preferred to finish Binding first.   Then on April 8  
2004  
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/ 
0037.html> you sent revision 07 of Redirect and said:

"This draft reflects the current state and is work-in-progress."

Do you consider Redirect to not be a work-in-progress any more?  If so,  
do you have diffs (from 06, perhaps) handy so we can gauge the extent  
of changes?  Once we resolve the status of the WG, I'd support a  
last-call with a minimum # of reviews solicited.

Lisa

On May 27, 2005, at 5:22 AM, Julian Reschke wrote:

> I'd prefer it to go to "Proposed" (that seems in line with the  
> Standards Process). Anyway, if you feel it's done, why don't you start  
> a WG last call for it?
>
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Sun, 29 May 2005 11:59:41 +0200

> intention that you preferred to finish Binding first.   Then on April 8  

As far as I am concerned, BIND is finished (meaning that depending of 
how one judges the current situation, either all issues have indeed been 
resolved, or resolution of these issues is pending until those how 
raised the issues come back discussing them).

> 2004  <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/ 

You may have missed that since then four more drafts have been posted 
(<http://greenbytes.de/tech/webdav/#draft-ietf-webdav-redirectref-protocol>). 

> last-call with a minimum # of reviews solicited.

As far as I can tell, it's done, otherwise I wouldn't ask for Last Call. 
  Back in February I wrote 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0293.html>):

"B3. REDIRECT

As far as I can tell, we (greenbytes) are the only ones actively working
on this (both spec and implementation). I think the spec is very close
to be finished; but I would prefer to have it fully implemented before
proceeding."

The meeting minutes for the last meeting 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0326.html>) 
say:

"REDIRECT
Redirect draft: progress waiting on author's implementation (Netweaver
again) to push forward)"

...and this is what happened.

All changes are summarized in an appendix of the text version (see 
below); marked-up diffs with the changes between the individual drafts 
are available from our web site:

<http://greenbytes.de/tech/webdav/#draft-ietf-webdav-redirectref-protocol>

Best regards, Julian

- snip -

Appendix A.  Change Log (to be removed by RFC Editor before publication)

A.1  Since draft-ietf-webdav-redirectref-protocol-02

    Julian Reschke takes editorial role (added to authors list).  Cleanup
    XML indentation.  Start adding all unresolved last call issues.
    Update some author's contact information.  Update references, split
    into "normative" and "informational".  Remove non-RFC2616 headers
    ("Public") from examples.  Fixed width problems in artwork.  Start
    resolving editorial issues.

A.2  Since draft-ietf-webdav-redirectref-protocol-03

    Added Joe Orton and Juergen Reuter to Acknowledgements section.
    Close more editorial issues.  Remove dependencies on BIND spec.

A.3  Since draft-ietf-webdav-redirectref-protocol-04

    More editorial fixes.  Clarify that MKRESOURCE can only be used to
    create redirect references (switch to new method in a future draft).
    Clarify that redirect references do not have bodies.

A.4  Since draft-ietf-webdav-redirectref-protocol-05

    Close (accept) issue "lc-79-accesscontrol".  Add issue "rfc2606-
    compliance".  Close issues "lc-50-blindredirect", "lc-71-relative",
    "lc-74-terminology".  Update contact info for Geoff Clemm.  Moved
    some of the original authors names to new Contributors section.  Add
    and close issue "9-MKRESOURCE-vs-relative-URI".  Close issue "lc-72-
    trailingslash".  Close issue "lc-60-ex".  Update issue "lc-85-301"
    with proposal.  Close issue "lc-06-reftarget-relative" (9-MKRESOURCE-
    vs-relative-URI was a duplicate of this one).  Also remove section
    9.1 (example for MKRESOURCE vs relative URIs).  Add and resolve issue
    "11.2-apply-to-redirect-ref-syntax" (header now has values "T" and
    "F").  Also some cleanup for "rfc2606-compliance".  Typo fixes.  Add
    and resolve "15.1-options-response".

A.5  Since draft-ietf-webdav-redirectref-protocol-06

    Resolve issues "lc-19-direct-ref", "lc-28-lang", "lc-29-lang", "lc-
    44-pseudo", "lc-53-s10", "lc-61-pseudo", "lc-63-move", "lc-80-i18n"
    and "rfc2606-compliance".  Start work on index.  Add new issue
    "old_clients".

A.6  Since draft-ietf-webdav-redirectref-protocol-07

    Closed issue "lc-38-not-hierarchical".  Cleaned up DTD fragments in
    appendix.  Close (reject) issues "lc-55-iana" and "lc-41-no-webdav".
    Add issue "5_mkresource" and start work on MKREDIRECTREF (issue
    closed, but more work on MKREDIRECTREF needs to be done for updates
    and status codes other than 302).  Start resolution of "lc-85-301",
    replacing "302" by more generic language.  Update issue "lc-57-
    noautoupdate".  Close issue "lc-37-integrity" (duplicate of "lc-57-
    autoupdate").  Started work on "lc-85-301".  Add L. Dusseault and S.
    Eissing to Acknowledgments section.

A.7  Since draft-ietf-webdav-redirectref-protocol-08

    Fix index entries for conditions.  Open and resolve issue
    "specify_safeness".  Rewrite editorial section and parts of intro.
    Add more clarifications for issue "lc-85-301" and close it.

A.8  Since draft-ietf-webdav-redirectref-protocol-09

    Resolve issues "lc-33-forwarding", "lc-36-server" and "lc-57-
    noautoupdate".  Close issues "lc-48-s6", "12.1-property-name",
    "3-terminology-redirectref" and "lc-58-update".  Rearrange section 5
    and 6.  Add some more terms to index (no change tracking).

A.9  Since draft-ietf-webdav-redirectref-protocol-10

    Add and resolve issues "13_allprop" and "rfc2396bis".  Use the term
    "Request-URI" throughout (this is what RFC2616 defines).  Center some
    of the artwork.  Add and resolve issue "abnf".

A.10  Since draft-ietf-webdav-redirectref-protocol-11

    Re-open and close issue "anbf" (implied LWS).  Raise and close issue
    "frag_in_target".  Add precondition name for legal reftarget element
    contents.  Enhance index.  Add and close issue "dtd-changes".