Subject: RE: WebDAV Bindings - Issue Yaron.BindSyntax

From: Yaron Goland <[email-masked]>
Date: Mon, 17 Jan 2000 12:01:33 -0800

What I am specifically looking for is the ability to have the server handle
all conversations with the resource on my behalf but with the possibility of
dangling references.
 
For example, I want to be able to create a collection that contains a bunch
of weak links to random resources all over the planet. Then I want to issue
a depth infinity PROPFIND against that collection and get back a bunch of
properties. In the background what is happening is that the server is
actually going out and performing the PROPFIND on my behalf to the
destination resources. However my experience as a client is that I make a
single PROPFIND request and get back a single PROPFIND result. This sort of
behavior is very important when dealing with very limited clients (hand
helds for example) or when using a very high latency link (wireless).
 
I am NOT suggesting that this group adopt a weak link of this type. At least
not yet. What I am proposing is that the language I suggested be put into
the BIND spec so that if we WANT to create links of this type we are ABLE to
do so.
 
In other words, I am not asking for consensus that the type of link I want
to create is a good idea. I am just asking that we put in language in the
BIND spec that will allow us to create a link of this type at a later date
if we choose to do so. Since the proposed language would not cause ANY
change in the way a BIND client/server behaves I can't think of a good
reason to refuse my request.

-----Original Message-----
From: Eric Sedlar [mailto:[email-masked]]
Sent: Mon, January 17, 2000 11:39 AM
To: Yaron Goland; [email-masked]
Subject: Re: WebDAV Bindings - Issue Yaron.BindSyntax

It depends on the kind of weak binding you want.  If it's something like a
symbolic link, redirect references work reasonably well for that.  If you
want a weak binding (weak, in that it is not affecting the persistence of
the item being bound) that doesn't dangle, you have to notify the source, so
that it can send the destination an event when the source is deleted.
 
--Eric

----- Original Message ----- 
From: Yaron Goland <mailto:[email-masked]>  
To: [email-masked] <mailto:[email-masked]>  
Sent: Sunday, January 16, 2000 5:47 PM
Subject: WebDAV Bindings - Issue Yaron.BindSyntax

The BIND spec defines that a binding is created by sending a message to the
source and instructing it to create a binding at the destination. This is
completely consistent with how WebDAV normally operates in methods such as
COPY/MOVE where the source is instructed to make changes at the destination.
Unfortunately, in the case of BIND, it introduces a very serious problem
when (not if, but when) we introduce weak bindings. The problem is that the
current bind syntax requires the active participation of the source to
create a bind at the destination. In the case of a weak binding it is
expected that the source may not even be aware of the binding. This is one
of the main benefits of introducing weak bindings, it allows for bind like
behavior without requiring the participation of the source. This enables
many resources to have weak bindings against a resource without overloading
the resource.

An example may help here. Imagine a user wants to create a weak binding to
http://www.yahoo.com/foo/bar <http://www.yahoo.com/foo/bar> . Currently, to
create this weak binding, the user would have to issue the bind method to
http://www.yahoo.com/foo/bar <http://www.yahoo.com/foo/bar>  and ask the
Yahoo server to somehow communicate with the destination server and create a
weak binding. This is like telling people that before they can add a
hyperlink to their HTML document they have to first get the resource pointed
to by the hyperlink to somehow participate in the process. The ability to
link to resources without the knowledge of the source (as the term is used
in the BIND method) has been one of the key aspects of the scalability of
the Web.

In my mind the proper solution is to introduce a source header that, when
used on a BIND method, would mean that the request-URI specifies the
destination rather than the source.

That having been said I really have no desire to prolong the agony of the
BIND authors by asking them to add a new header and deal with all the
complexities it would introduce. As such I am happy to settle for the
following paragraph being added to section 5.1: "The BIND method MUST fail
if it does not include a destination header. Note, however, that future
specifications MAY introduce additional headers that resources could honor
in the place of the destination header and so allow the BIND method to
succeed in the absence of a destination header."

This would allow us, in the future, to introduce a weak binding spec that
could still use the BIND method without forcing us to use MAN or introduce a
new method.

---

From: "Eric Sedlar" <[email-masked]>
Date: Mon, 17 Jan 2000 12:17:00 -0800

WebDAV Bindings - Issue Yaron.BindSyntaxSounds like a good idea, and I'm in favor of it.  However, one of your statements was:

"Unfortunately, in the case of BIND, it introduces a very serious problem when (not if, but when) we introduce weak bindings."

I'm just pointing out that you're only addressing a particular class of weak bindings, which weakens your "not if, but when" statement as it applies to your proposal.

--Eric
  ----- Original Message ----- 
  From: Yaron Goland 
  To: 'Eric Sedlar' ; [email-masked] 
  Sent: Monday, January 17, 2000 12:01 PM
  Subject: RE: WebDAV Bindings - Issue Yaron.BindSyntax

  What I am specifically looking for is the ability to have the server handle all conversations with the resource on my behalf but with the possibility of dangling references.
   
  For example, I want to be able to create a collection that contains a bunch of weak links to random resources all over the planet. Then I want to issue a depth infinity PROPFIND against that collection and get back a bunch of properties. In the background what is happening is that the server is actually going out and performing the PROPFIND on my behalf to the destination resources. However my experience as a client is that I make a single PROPFIND request and get back a single PROPFIND result. This sort of behavior is very important when dealing with very limited clients (hand helds for example) or when using a very high latency link (wireless).
   
  I am NOT suggesting that this group adopt a weak link of this type. At least not yet. What I am proposing is that the language I suggested be put into the BIND spec so that if we WANT to create links of this type we are ABLE to do so.
   
  In other words, I am not asking for consensus that the type of link I want to create is a good idea. I am just asking that we put in language in the BIND spec that will allow us to create a link of this type at a later date if we choose to do so. Since the proposed language would not cause ANY change in the way a BIND client/server behaves I can't think of a good reason to refuse my request.
    -----Original Message-----
    From: Eric Sedlar [mailto:[email-masked]]
    Sent: Mon, January 17, 2000 11:39 AM
    To: Yaron Goland; [email-masked]
    Subject: Re: WebDAV Bindings - Issue Yaron.BindSyntax

    It depends on the kind of weak binding you want.  If it's something like a symbolic link, redirect references work reasonably well for that.  If you want a weak binding (weak, in that it is not affecting the persistence of the item being bound) that doesn't dangle, you have to notify the source, so that it can send the destination an event when the source is deleted.

    --Eric
      ----- Original Message ----- 
      From: Yaron Goland 
      To: [email-masked] 
      Sent: Sunday, January 16, 2000 5:47 PM
      Subject: WebDAV Bindings - Issue Yaron.BindSyntax

      The BIND spec defines that a binding is created by sending a message to the source and instructing it to create a binding at the destination. This is completely consistent with how WebDAV normally operates in methods such as COPY/MOVE where the source is instructed to make changes at the destination. Unfortunately, in the case of BIND, it introduces a very serious problem when (not if, but when) we introduce weak bindings. The problem is that the current bind syntax requires the active participation of the source to create a bind at the destination. In the case of a weak binding it is expected that the source may not even be aware of the binding. This is one of the main benefits of introducing weak bindings, it allows for bind like behavior without requiring the participation of the source. This enables many resources to have weak bindings against a resource without overloading the resource.

      An example may help here. Imagine a user wants to create a weak binding to http://www.yahoo.com/foo/bar. Currently, to create this weak binding, the user would have to issue the bind method to http://www.yahoo.com/foo/bar and ask the Yahoo server to somehow communicate with the destination server and create a weak binding. This is like telling people that before they can add a hyperlink to their HTML document they have to first get the resource pointed to by the hyperlink to somehow participate in the process. The ability to link to resources without the knowledge of the source (as the term is used in the BIND method) has been one of the key aspects of the scalability of the Web.

      In my mind the proper solution is to introduce a source header that, when used on a BIND method, would mean that the request-URI specifies the destination rather than the source.

      That having been said I really have no desire to prolong the agony of the BIND authors by asking them to add a new header and deal with all the complexities it would introduce. As such I am happy to settle for the following paragraph being added to section 5.1: "The BIND method MUST fail if it does not include a destination header. Note, however, that future specifications MAY introduce additional headers that resources could honor in the place of the destination header and so allow the BIND method to succeed in the absence of a destination header."

      This would allow us, in the future, to introduce a weak binding spec that could still use the BIND method without forcing us to use MAN or introduce a new method.

---

From: "Eric Sedlar" <[email-masked]>
Date: Mon, 17 Jan 2000 12:17:03 -0800

--Eric

   
   
    -----Original Message-----
    From: Eric Sedlar [mailto:[email-masked]]
    Sent: Mon, January 17, 2000 11:39 AM
    To: Yaron Goland; [email-masked]
    Subject: Re: WebDAV Bindings - Issue Yaron.BindSyntax

    --Eric