Re: [Bug 12] Destination header "consistent"

I agree with all of Julian's points.

We have a large number of real issues to deal with.

Let's get those taken care of before we waste any more time on debating
whether it improves or damages the specification by adding in arbitrary
amounts of additional "explanatory" text to an already overly long 
specification.

Cheers,
Geoff


Julian wrote on 10/22/2005 02:42:35 PM:
> 
> Lisa Dusseault wrote:
> > 
> > On Oct 22, 2005, at 11:04 AM, Julian Reschke wrote:
> > 
> >>
> >> Lisa, it seems that whatever we discuss, you try to turn this into a 
> >> discussion about even more spec text. RFC2518bis doesn't need to say 
> >> anything about it. Whatever RFC2616 already says and a future WebDAV 
> >> REDIRECT spec will say is sufficient.
> > 
> > 
> > You say that as though it's a bad thing!  Whenever we discuss or 
> 
> Yes, as a matter of fact I think it's a bad thing. We are revising 
> RFC2518, which to me means
> 
> - fixing bugs (examples, typos)
> - removing stuff nobody does implement (such as DAV:propertybehaviour)
> - simplify things that were too complex in the first place (lock-null 
> resources come to mind)
> - removing stuff that's not need today anymore (XML namespace 
> explanations, UUID generation instructions...)
> - update references
> - add stuff that we agree was missing (DAV:lockroot...)
> 
> This may not be complete, but it should cover most cases.
> 
> Just adding prose without no actual need for it IMHO is a bad idea. Do 
> that in FAQs, Blogs, online resources, implementor guides, books, 
whatever.
> 
> > disagree on the mailing list, I find that's a good case for narrowing 
> > down what can be done in implementations of RFC2518bis; to reduce 
> > variety between implementations, improve interoperability and have a 
> > complete spec that doesn't send people running to the mailing list all 

> > too often.
> 
> "Narrowing down" means a change of the spec. As far as I can tell, there 

> is no need to change the spec. If you feel there is a need, please 
> explain way (interop problem???).
> 
> > We can at least think and talk about the issue -- if we *do* come to 
> > consensus that Location header is not appropriate in 207 responses (or 

> > other new response codes defined by WebDAV, or new methods defined by 
> > WebDAV) then any of that would be good information to add to the spec.
> 
> I disagree. RFC2616 defines what the "Location" header is for, and any 
> attempt to go further than that without practical reasons IMHO would be 
> the wrong thing to do.
> 
> > OTOH if we come to consensus that we shouldn't restrict Location 
header 
> > use but leave it undefined on most response types, I hope there's a 
good 
> > reason for that which would come out in a discussion.
> 
> We can (and will) discuss whatever is raised here. I just dont't see how 

> this discussion helps us in any way revising RFC2518. As a matter of 
> fact, it slows us down, because it distracts us from the things that 
> *are* on the issues list.
> 
> Best regards, Julian
> 
> 
> 
> 
> 
>