Subject: RE: Last Call: draft-ietf-webdav-rfc2518bis (HTTP Extensions for Distributed Authoring - WebDAV) to Proposed Standard

From: Ted Hardie <[email-masked]>
Date: Fri, 19 Jan 2007 14:16:26 -0800

At 1:36 PM -0800 1/19/07, Kevin Wiggen wrote:
>I think what the spec needs is some love and attention.  If enough of us (and I will volunteer to READ and COMMENT) spend time on this, I think we can come to some sort of resolution.  I would hate to see the work done by the working group, Geoff, Julian, Lisa, etc go to waste.
 
I would also hate to see the work of this working group go to waste.  But I do not
believe that an additional two months, starting with a document that is not
up to date or the product of working group discussion, is at all a practical
time estimate.  As its Area Advisor, I gave this working group a six month
time line to finish its work eighteen months ago.  The last three months of
that period saw more significant activity than the working group had had
in the previous year.  Close to the deadline, Cullen asked that the WG be
extended as there were a few final issues that needed resolution. 

We are now almost a year on from that point.  Suggesting that an additional
two months would resolve things is, bluntly, completely contrary to the
experience of this WG. 

The first draft of this document was issued  *five years ago*.  If it is better
than 2518, it is time to push it out the door and making a new line in the sand. 
Too much of what to do with webdav is now "lore" in the heads of the
current implementors and unavailable without sifting through the WG
archives.  I believe getting this document out will help, even if it does not solve
the problem completely or meet its original goal (to get to Draft Standard).

That doesn't preclude there ever being a 2518ter or a Draft Standard here.
But with the current inputs, we are well past the point of diminishing returns.
Getting this document out as a Proposed Standard seems to me, both personally
and as the working group's area advisor, the best balance of retaining the work
that has been done and setting the stage for eventual further work.

				Ted Hardie

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Julian Reschke <[email-masked]>
Date: Tue, 23 Jan 2007 14:46:02 +0100

> up to date or the product of working group discussion, is at all a practical

Ted, could you please elaborate why you think the document is not "up to 
date"? It is based on draft 17, and during the past year, I've made sure 
that any change that has been applied to the WG draft has been applied 
to my document as well (see 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#changes.compared.to.rfc2518bis>).

Also, it *is* a result of working group discussion, in that it proposes 
resolutions to issues that the WG has brought up. No, it doesn't 
necessarily reflect *consensus*, but nor does the WG draft, I'd say.

> time line to finish its work eighteen months ago.  The last three months of

And you were right in doing so, as the WG had been making no noticeable 
progress for a very long time before; a fact that I complained about 
often enough.

Unfortunately, the first three months of that period were lost as well, 
and that's a shame (see for instance 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JulSep/0027.html>). 
To make things worse, after the WG last call eleven months ago most 
issues that were raised have been left unfixed, although resolutions for 
many of them were made.

> two months would resolve things is, bluntly, completely contrary to the

You are right, but just in the case as the WG continues to work the way 
it did before.

> the problem completely or meet its original goal (to get to Draft Standard).

Well, it's IMHO a bad idea to push out a document with known *bugs*, in 
particular if it's easy to fix them. I will start an errata list right 
away (just like I did for RFC3648/3744), but the *right* thing to do 
would be not to publish the document knowing about these problems.

> That doesn't preclude there ever being a 2518ter or a Draft Standard here.

I care a lot about a specification that is correct, and a bit less about 
it's status in the standards ladder. So it seems to me that work on a 
revision will have to start right away, no matter whether there's an 
IETF WG or not.

> that has been done and setting the stage for eventual further work.

I would agree if the current document wasn't fixable. But it is.

Best regards, Julian

---

From: Edward Lewis <[email-masked]>
Date: Tue, 23 Jan 2007 09:39:14 -0500

I have a question on section 3 of http://www.ietf.org/ietf/1id-guidelines.txt

There is this passage:

    "Copyright (C) The IETF Trust (YYYY).

    This document is subject to the rights, licenses and restrictions
    contained in BCP 78, and except as set forth therein, the authors
    retain all their rights."

    "This document and the information contained herein are provided on
    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
    IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
    WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
    WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
    RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
    PARTICULAR PURPOSE."

Should this be quoted like this:

    "Copyright (C) The IETF Trust (YYYY).

    "This document is subject to the rights, licenses and restrictions
    contained in BCP 78, and except as set forth therein, the authors
    retain all their rights.

    "This document and the information contained herein are provided on
    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
    IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
    WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
    WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
    RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
    PARTICULAR PURPOSE."

When I was in school, I was taught to quote multiple paragraphs with 
quotes at the start of each and a closing quote only at the end of 
the final paragraph.

Similar "errors" appear in section 5 of the document.  Or so I think.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jan 2007 16:43:54 +0100

> quotes at the start of each and a closing quote only at the end of the 
> final paragraph.

So was I, but whether or not this is a typo doesn't affect what you
put in an I-D, which doesn't have the quotation marks anyway,
except of course those in '"AS IS"'.

Use XML2RFC and you simply don't have to worry about this anyway.

    Brian

---

From: Edward Lewis <[email-masked]>
Date: Tue, 23 Jan 2007 16:46:50 -0500

>Use XML2RFC and you simply don't have to worry about this anyway.

In the spirit of trying follow a specification and not an implementation:

Referencing this, linked from the IETF main page via http://ietf.org/ID.html:

http://www.ietf.org/ietf/1id-guidelines.html

In the section on IPR it says:

# 9.  Intellectual Property Rights
# If you think that you, your company, or anyone else owns a patent or other
# IPR on the work described in the draft, you should read carefully RFC 3979
# (Bradner, S., "Intellectual Property Rights in IETF Technology," March 2005.)
# [RFC3979]. The first notice required in Internet-Drafts, described in
# Section 3 (IPR-Related Notices Required in Internet-Drafts) of this document,
# obligates you to send an IPR disclosure under certain circumstances. Before
# submitting the draft, it would be a good advice to talk to the working group
# chair or area directors about it.

Where in there is there a requirement to include the text mentioned below?

   * The document seems to lack an RFC 3979 Section 5, para 1 IPR Disclosure
     Acknowledgement.

   * The document seems to lack an RFC 3979 Section 5, para 2 IPR Disclosure
     Acknowledgement.

   * The document seems to lack an RFC 3979 Section 5, para 3 IPR Disclosure
     Invitation.

---

From: Tony Finch <[email-masked]>
Date: Tue, 23 Jan 2007 22:27:38 +0000

> Where in there is there a requirement to include the text mentioned below?

Try looking at sections 3 and 4 which are also about IPR.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
EAST FORTIES: NORTHERLY VEERING EASTERLY 4 OR 5. MODERATE OR ROUGH. WINTRY
SHOWERS. GOOD.

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 24 Jan 2007 00:06:32 +0100

Hi Edward,

on 2007-01-23 22:46 Edward Lewis said the following:
...
>    * The document seems to lack an RFC 3979 Section 5, para 3 IPR Disclosure

This appears to be an excerpt from the output of the idnits tool.

If you had included a few lines more of the output, you would have
seen a line above the ones you quote, saying:

"  Checking nits according to http://www.ietf.org/ID-Checklist.html:"

So the answer is that the requirements for this are in the ID-Checklist, which
applies to drafts that are submitted for IESG consideration, rather than in
the ID-Guidelines (http://www.ietf.org/ietf/1id-guidelines.html) which apply
to draft submitted to [email-masked] in general.

The ID-Checklist is referenced from the same page you referred to earlier,
http://www.ietf.org/ID.html, a couple of lines below the reference and link to
the ID-Guidelines.

Regards,

	Henrik

---

From: Edward Lewis <[email-masked]>
Date: Wed, 24 Jan 2007 09:14:14 -0500

>http://www.ietf.org/ID.html, a couple of lines below the reference and link to

You're right, and I noticed all of that.

What made this mysterious to me was why I failed to see my 
submissions get announced for some time.  I never got any official 
feedback so I began to assume that the nits tool was the official 
word.  After all, one recommendation was to just use the XML2RFC tool 
and not bother interpreting the requirements.

Apparently my draft did finally get announced - although I haven't 
checked to see which version came out.  (I.e., which -00, differing 
in boilerplates.)  What I'm trying to vent here is a plea to make the 
instructions for submitting a draft a bit clearer, for instance, 
recommend a run of the nits tool and also say whether or not the nits 
tool's assessment is binding or not.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 24 Jan 2007 09:24:06 -0500

>Try looking at sections 3 and 4 which are also about IPR.

Section 3 -
" Any submission which does not include these statements will be 
returned to the submitter."

Nothing was ever returned to me.

I have the section 3 boilerplate in there.  There is no mandatory 
boilerplate in section 4.

---

From: "Bill Fenner" <[email-masked]>
Date: Wed, 24 Jan 2007 11:21:16 -0800

On 1/24/07, Edward Lewis <[email-masked]> wrote:
> word.

When this happens, it's best to contact the secretariat to find out
the status of the I-D submission (see the last sentence of section 7
of 1id-guidelines).  Guessing is an ineffectual method of learning
what caused the delay.

  Bill

---

From: "Bill Fenner" <[email-masked]>
Date: Wed, 24 Jan 2007 11:18:12 -0800

> I have a question on section 3 of http://www.ietf.org/ietf/1id-guidelines.txt

The short answer is that it was copied directly out of RFC 3978 (plus
the modifications in RFC 4748).  When I was updating 1id-guidelines, I
erred on the side of exactly duplicating the text in the RFC, since
the RFC is really what defines the rules.

  Bill

---

From: "Bill Fenner" <[email-masked]>
Date: Wed, 24 Jan 2007 11:21:16 -0800

Bill

---

From: "Bill Fenner" <[email-masked]>
Date: Wed, 24 Jan 2007 11:18:12 -0800

Bill

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 24 Jan 2007 20:37:16 +0100

Hi Edward,

> and not bother interpreting the requirements.

Ah, I see.

> tool's assessment is binding or not.

Right.  This should improve when the web-based draft submission tool
(based on the RFC 4228 specification) comes online, which is planned
to happen in time for Prague.

Currently, the secretariat has a separate script to check ID-Guidelines
conformance, and its results aren't always identical with those of
idnits.  When the web-based submission tool comes online, it will
use idnits in an ID-Guidelines checking mode instead of a separate
script, so the results of the ID-Guidelines section of the idnits
check should always match the automated checking done by the submission
tool, and the submission tool should show clearly what was amiss if
a problem is found with a submission.

idnits will continue to indicate non-conformance with the ID-Checklist,
too, but errors reported in this section of the output only becomes a
show-stopper at the time the document is sent to the IESG.  ( That
doesn't mean that ID-Checklist nits can't be fixed earlier, of course ;-)

I hope that helps a bit.

Regards,

	Henrik