![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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:fluffy at cisco.com]
> Sent: Tuesday, February 20, 2007 5:35 PM
> To: Julian Reschke
> Cc: ietf at ietf.org
> Subject: Re: Last Call: draft-ietf-webdav-rfc2518bis (HTTP Extensions
> forDistributed Authoring - WebDAV) to Proposed Standard
>
>
> 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
> Ietf at ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.