Re: draft-toomim-httpbis-versions HTTP mapping (and WebDAV Versioning)

On 01.11.2024 22:57, Michael Toomim wrote:
> Thanks, Julian for your thorough feedback here! I appreciate your
> pushback where my understanding of WebDAV was overly-complex.
>
> I believe you and I are now converging to the underlying semantic
> question of how *versions* and *resources* relate, that you identified
> in the other thread.
>
> I'll follow up there, but ask a few clarifying questions here, to pluck
> some knowledge from your brain and close off any dangling threads:
>
> On 10/30/24 3:20 AM, Julian Reschke wrote:
>> Yes, WebDAV Version Control uses a centralized model. If you want a
>> distributed system, it's not for you. Note that this is an issue WebDAV
>> Versioning, not WebDAV in general.
>
>
> Oh, the distinction that "WebDAV is not centralized, but WebDAV
> versioning *is* centralized" is new to me, and curious. Could you
> explain where you see this distinction?

That's not exactly what I meant. WebDAV (the base protocol, as defined
by RFC4918) is a system to edit/author HTTP(s) resources. So it is
distributed or not just as the web built on top of HTTP.

> It is true that the CHECKIN/CHECKOUT methods are specified in the
> Versioning doc, but the LOCK/UNLOCK methods are in the core WebDAV spec:
> http://www.webdav.org/specs/rfc4918.html#locking.

Yes, that's for collaborative authoring. It is truly optional.

>>> 2. WebDAV takes up URL space by requiring each version of a resource to
>>> have a URL.
>>
>> I'd argue that this is a feature. If versions are different resources,
>> they should have their own URIs. I don't think that content negotiation
>> is the right approach; in particular as it does not work when different
>> versions sit on different servers.
>
>
> Just so I know I'm understanding you— when you say "content negotiation
> is [not] the right approach", am I correct in mentally expanding this to
> the sentence: "using content negotiation (specifying which version you
> want from a server using a Version: header) is not the right approach to
> requesting a specific version"?

Not necessarily. It could be used to discover a version, but that
version should also (in general) have a URL. See Content-Location
(<https://www.rfc-editor.org/rfc/rfc9110.html#identifying-content>).

> If so, then I think I understand your concern, and will pick it up in
> the other thread.

+1!

>>>     This was how we differentiate WebDAV in the spec:
>>>
>>>         1.1.3.  Versioning encoded within URLs
>>>
>>>             In practice, application programmers tend to encode versions
>>>         within
>>>             URLs:
>>>
>>>         https://unpkg.com/braid-text@0.0.18/index.js
>>
>> Why is that a problem? (and no, they don't have to)
>
> It's not a problem in itself. I'm sorry that was confusing.
>
> You've correctly identified a number of advantages to encoding versions
> in URIs. I accept these advantages, and create a lot of "Version URIs"
> myself!

We need to be careful here. It is a common approach to put a version
identifier into the URL of a version, but it's certainly not the only
way to do it.

> My argument is to have a separation of concerns between "Versioned
> Resources" and "Resources for Versions of a Resource." I want a robust
> spec for how HTTP Resources are versioned that does not talk about
> creating new URIs. Then we specify how to map new URIs to those versions
> as a separate concern with a separate spec— reusing link relations and
> friends where we can.
>
> And this segways to the Deep Question™ in the other thread!
> ...

Ok. I believe you really can't avoid the question: if the version has a
different URI then the version-controlled resource, is it a resource on
its own? And the answer is: of course. Note that this even is true for
URIs that do not have locator properties, such as most URNs.

Best regards, Julian

Received on Friday, 1 November 2024 23:05:10 UTC