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

From: Cullen Jennings <[email-masked]>
Date: Tue, 20 Feb 2007 17:34:33 -0800

On Jan 22, 2007, at 4:49 AM, Julian Reschke wrote:

> Hi,
>
> RFC2518bis updates parts of RFC3253 (DAV:error below DAV:response)  
> in an
> incompatible way, and thus should note it in the front matter  
> ("Updates: 3253") and mention it as a change near the Changes  
> Appendix.
>
> (see <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi? 
> id=258>)
>
> Best regards, Julian

Sent with my behave chair hat on ...

This is always a complicated problem of does an update document  
update the documents that depend on the drafts it's updates. An  
extreme example is should TLS 1.2 update every document that uses TLS  
1.0. It's pretty unwieldy to take that path so I I think a better  
path is that 3253 depends on 2518 and when we update 3253, then it  
will be changed to depend on the RFC that comes out of the 2518bis  
draft.

The WG definitely considered the impact of the incompatibilities here  
and decided that this was an acceptable path - the only question we  
are trying to sort out here is if the id tracker shows this an up  
update on 3253 or not.

Cullen

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

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 20 Feb 2007 18:32:08 -0800

Without forcing me to read all the referenced documents, is there an easy
way to determine whether any IPR disclosures relating to these documents
need to be correlated and disclosed?

/Larry Rosen

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Tuesday, February 20, 2007 5:35 PM
> To: Julian Reschke
> Cc: [email-masked]
> Subject: Re: Last Call: draft-ietf-webdav-rfc2518bis (HTTP Extensions
> forDistributed Authoring - WebDAV) to Proposed Standard
> 
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 20 Feb 2007 20:44:53 -0800

>need to be correlated and disclosed?

Is the IPR search page, linked off of the IETF web page not working for you?
You can search there for draft names or RFC numbers.   If  you are asking
whether it is designed to recursively search all the dependencies in a document
as well, the answer is no.  We do expect people to read our documents.  If
you'd like to suggest it to the tools team as a convenience for those who do
not, I'm sure they'll consider it.  [email-masked] is the right venue
for that suggestion.
		regards,

				Ted Hardie

---

From: Julian Reschke <[email-masked]>
Date: Wed, 21 Feb 2007 14:22:07 +0100

Cullen Jennings schrieb:
>> RFC2518bis updates parts of RFC3253 (DAV:error below DAV:response) in an
>> ("Updates: 3253") and mention it as a change near the Changes Appendix.
>>
>> (see <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=258>)
>>
>> Best regards, Julian
> 
> 
> This is always a complicated problem of does an update document update 
> the documents that depend on the drafts it's updates. An extreme example 
> is should TLS 1.2 update every document that uses TLS 1.0. It's pretty 
> unwieldy to take that path so I I think a better path is that 3253 
> depends on 2518 and when we update 3253, then it will be changed to 
> depend on the RFC that comes out of the 2518bis draft.

Well, right now RFC3253 doesn't indicate that it updates RFC2518. For 
that matter, nor does RFC2518 indicate that it updates RFC2068, or 
draft-RFC2518bis that it updates RFC2616 (one could argue it should 
because it updates the set of methods, headers, and status codes).

Generally, the linkage using "obsoletes" and "updates" is really 
restricted and doesn't work well, except for simple cases such as 
"RFC2616 obsoletes RFC2068".

> and decided that this was an acceptable path - the only question we are 
> trying to sort out here is if the id tracker shows this an up update on 
> 3253 or not.

That's not the only question. The other question is whether it's wise to 
make an incompatible change and not to mention that at all. I strongly 
suggest we at least make it clear that this is a change, and that it was 
intentional.

Proposed Change (see also 
<http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=258> and 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz258>):

+++
Section 14.24., para. 4:
OLD:

     <!ELEMENT response (href, ((href*, status)|(propstat+)),
                         error?, responsedescription? , location?) >

NEW:

     <!ELEMENT response (href, ((href*, status)|(propstat+)),
                         error?, responsedescription?, location?) >

        Note: the usage of the 'error' element inside 'response' is an
        incompatible change to [RFC3253], Section 1.6, paragraph 2 (where
        'error' appeared as a child element of 'responsedescription').

+++

Best regards, Julian