RE: multiple parents (Was 'last call' comment on draft-ietf-webdav-protocol-07.txt-- resource:URL 1:1?)

Consider two possibilities: "case insensitivity" and "host name aliasing",
and then allow for other aliasing which has similar semantics.

With "case insensitivity", you might treat "http://host.dom/PATH/x" the
same as "http://host.dom/Path/x" and "http://host.dom/PaTh/x". 

With "host name aliasing", you might treat "http://server.dom/path/x" the
same as "http://252.14.2.12/path/x" using the server's IP address instead
of the server name, or even "http://big.server2.dom/path/x" where 
big.server2.dom is an alias for server.dom.

> I'm not sure I agree there's a problem that needs fixing.  For one thing,
> since no one ever wrote a 'requirements document' for any  Web server that
> does aliasing, we don't know what the intended abstraction is, and hence
> can't tell whether WebDAV is breaking it.

There are many other forms of aliasing, but surely you will acknowledge
that for "case insensitivity", aliasing is widespread.

> I can think of at least four possible intentions:
> 
> 1 - a resource has one "true" URL, and may have additional synonyms.
> Deletion using the true name deletes the resource.  Future references using
> the synonyms return an error.  An attempt to delete using a synonym has no
> effect. (since there's no means in the protocol to create a synonym, why
> should there be one to remove it?)
> 2 - Same as 1, except that deletion of a synonym removes that name from the
> namespace but has no effect on other names.  This is like the semantics of
> a Unix symbolic link.
> 3 - All names are equally valid.  Deleting a resource under any of its
> names deletes it for all of them.
> 4 - All names are equally valid, but the resource only disappears when the
> last name is deleted.  This is like Unix hard links.

1 and 3 are similar, but I believe only "3" is consistent with the
common case above.

> Does anyone have any insight as to which was the intended purpose of
> aliasing?  Were the others considered and rejected for some reason?

There may be other forms of aliasing with other motivations, so it's not
clear that this question is relevant.

> >I think that it's simple to fix the protocol by adding a "parent" property
> 
> I'm not so sure it's simple.  I suggest you try it yourself, then send the
> appropriate language to the list.  For one thing, should it be parent,
> singular, or parent, plural?  If you want it to be singular, then you are
> introducing some concept of a "true" URL with the others being second-class.

No, only if you expect it to be determinable. Perhaps it could merely return
"a" parent.

> For another, I would claim that if you wanted this at all, what you'd want
> would be a property whose value was the set of all names by which the
> resource could be located (ie. the synonyms).  

That would be unwieldy in the case of case sensitivity, since there are
2^N synonyms for each URL, where N = number of instances of letters A-Z.

> Given this you can find the
> set of parents trivially (by chopping the last component off).  But given
> the parents only, you can't easily find the names.  This property is in
> fact _exactly_ what I proposed as the "references" property in recent mail
> apropos ACR.  It must of course be optional, as some servers will be
> disinclined to support it.

I don't think 'references' is appropriate for case sensitivity or host name
equivalence.

> As for the four semantics above, the ACR proposal provides semantics #2.
> 
> Why?  Because it does all that #1 does, plus more.  #3 is dreadful, as it
> allows anyone who can link to a resource to also delete it.  #4 is not as
> bad as #3, but I think many people like the idea of having full control
> over resources (they want to be sure they can really delete something and
> have it be gone.).
> 
> regards
> 
> Jim

Received on Wednesday, 2 September 1998 13:32:36 UTC