Subject: RE: Comments on bind-08

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 1 Dec 2004 10:45:02 -0800

Geoff Clemm wrote:

	Jim: I'm OK with adding the paragraph, but what was the possible
misunderstanding 
	that this additional text was intended to clear up?  How else could
a Depth=infinity 
	COPY work? 

There are two possible confusions.

1) An implementer could implement the BINDDUP semantics (i.e., duplicate
bindings, but not resources), rather than the desired semantics of
duplicating resources and bindings. I agree that someone who reads and
understands the current specification and RFC 2518 should not come to this
misunderstanding. However, since the bind specification doesn't explicitly
address Depth infinity copies, there is no explicit information that would
clearly and definitively cause someone to stop thinking that BINDDUP
semantics are the intent.

2) It's not clear how to handle bindings that cause containment loops, since
in this case you do just want to only duplicate the binding, and not the
bound resource. This is enough different from the mainline COPY semantics
(duplicate binding and bound resource) that it's worth explicitly mentioning
it. For example, a reasonable interpretation of the current specification,
when copying loopback bindings, is to create a new binding to a new
collection, where the new collection's bindings point to the resources bound
by the collection originally pointed to by the loopback binding. This
preserves the "copy binding and duplicate destination resource" semantics
described for COPY.
	
Note that people, in general, do not go out of their way to seek
disconfirming evidence of positions they hold (see Reason's book on human
error), and hence the burden really is on the spec. writer to provide text
that clearly refutes alternate interpretations. 

	> > * Section 2.6 -- there needs to be some discussion on the
interactions of
	> > DAV:resource-id and versioning. As near as I can tell, the
intent is that
	> > every revision will have a unique DAV:resource-id value.
	> 
	> That's correct. I'm not sure why we would need to state this -- a 
	> version resource clearly is not the same resource as it's VCR, so
it 
	> seems clear they'll never have the same DAV:resource-id. 
	
	I agree with Julian.  A version is a new resource created by the
CHECKIN method. 
	According to section 2.6, a new resource must be assigned a new
resource-id, 
	so each new version needs to be assigned a new, distinct
resource-id.

Glad we're in agreement. It should be trivial to add a sentence to this
effect in the bind specification.

	> > * Section 6.2. I think it would be helpful to have an example
including
	> > REBIND and locks, showing submission of one or more lock tokens
in the If
	> > header.
	> 
	> Such as one involving locked source and destination collections?
That 
	> may be useful. What do others think? 
	
	I continue to believe that the right place for locking examples is
in a 
	locking spec, and that the binding spec just needs to make clear
which resources 
	and which URL mappings are being modified by an operation, since
this is all 
	you need to know which locks are required.  I believe this
information is 
	well-defined in the pre-conditions of the methods introduced by the
binding 
	spec.  So I'd vote not to add such an example, but I could live with
it, 
	if a majority is for it. 

I just wanted to clarify the use of the If header to pass lock tokens for
already locked resources, since there have been client implementation issues
concerning If implementation in this past. I agree that we should, for now,
avoid discussion of the interactions of LOCK and bindings.

- Jim

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 1 Dec 2004 14:47:39 -0500

> preserves the "copy binding and duplicate destination resource" 
semantics

OK, thanks, now I understand your concern.

I suggest that rather than adding additional text, that we add an 
additional
diagram showing what the result is of a copy in this case (I believe a
single example can illustrate both of these points).

Note: The reason I (and I believe Julian) push back on "just adding text"
is that there are various ways to clarify (text, pictures, examples), and
until we understand the specific problem, we cannot have a discussion 
about
the best way to address the concern.

> effect in the bind specification.

I'm OK with adding this as the form of an example, i.e., in section 2.6,
after the sentence stating that new resources get new resource-id's, we
could say that "for example, when a new version resource is created, it 
receives a new resource-id".

> avoid discussion of the interactions of LOCK and bindings.

I agree.  The last thing I want us to do is make a statement about
lock token marshalling in the binding specification.

Cheers,
Geoff

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 1 Dec 2004 12:16:02 -0800

Geoff writes:

	I suggest that rather than adding additional text, that we add an
additional 
	diagram showing what the result is of a copy in this case (I believe
a 
	single example can illustrate both of these points). 
	
This seems reasonable to me (depending on the example, of course).

	I'm OK with adding this as the form of an example, i.e., in section
2.6, 
	after the sentence stating that new resources get new resource-id's,
we 
	could say that "for example, when a new version resource is created,
it 
	receives a new resource-id". 

That's fine with me, and let's mention VCRs while we're at it.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Dec 2004 21:28:49 +0100

> single example can illustrate both of these points).

OK. Any proposed text/artwork for inclusion into the spec? (I'll work on 
the other issues in the meantime :-).

> until we understand the specific problem, we cannot have a discussion about

Agreed. In particular, when I myself read specs that (under my 
impression) repeat information that was already provided before/by 
reference, I start asking myself: "why are they repeating this? -- is 
this intended to *change* something that was said before?". So, if 
something's just intended to repeat something that was already specified 
somewhere else, it makes a lot of sense to say that, instead of leaving 
readers like myself confused :-)

> receives a new resource-id".

Sounds like a good compromise. Unless there are objections, I'll make 
that change right away.

> ...

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 1 Dec 2004 15:53:39 -0500

2.6, 
we 
it 
> That's fine with me, and let's mention VCRs while we're at it.

Now that's a more interesting topic (:-).

When you use the VERSION-CONTROL method with a specified Version,
one could interpret that as just restoring that resource, as opposed
to creating a new resource.  I can imagine repository vendors having 
strong
(contradictory :-) opinions on that topic, so I'd suggest maintaining
a discrete silence on that topic for now (and if it needs to be resolved,
do so in the RFC-3253bis, and not in the binding specification).

Cheers,
Geoff

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 1 Dec 2004 17:04:00 -0800

> OK. Any proposed text/artwork for inclusion into the spec? 
> (I'll work on the other issues in the meantime :-).

How about:

As an example of how COPY with Depth infinity would work in the presence of
bindings, consider the following collection:

+------------------+
| Root Collection  |
|  bindings:       |
|  CollX           |
+------------------+
    |
    |
    |
+-------------------------------+
| Collection C1                 |<-------+
| bindings:                     |        |
| x.gif      CollY              |        |
+-------------------------------+        |
    |          \                         |
    |           \         (creates loop) |
    |            \                       |
+-------------+   +------------------+   |
| Resource R1 |   | Collection C2    |   |
+-------------+   | bindings:        |   |
                  | y.gif     CollZ  |   |
                  +------------------+   |
                      |         |        |
                      |         +--------+
                      |
                  +-------------+
                  | Resource R2 | 
                  +-------------+

If a COPY with Depth inifinity is submitted to /CollX, with destination of
/CollA, the outcome of the copy operation is:

                                +-------------------------+
                                | Root Collection         |
                                |  bindings:              |
                                |  CollX          CollA   |
                                +-------------------------+
                                    /               \
                                   /                 \
                                  /                   \
                                 /                     \
+-------------------------------+
+-------------------------------+
| Collection C1                 |<-------+         | Collection C3
|<-------+
| bindings:                     |        |         | bindings:
|        |
| x.gif      CollY              |        |         | x.gif      CollY
|        |
+-------------------------------+        |
+-------------------------------+        |
    |          \                         |             |          \
|
    |           \         (creates loop) |             |           \
(creates loop) |
    |            \                       |             |            \
|  
+-------------+   +------------------+   |         +-------------+
+------------------+   |
| Resource R1 |   | Collection C2    |   |         | Resource R3 |   |
Collection C4    |   |
+-------------+   | bindings:        |   |         +-------------+   |
bindings:        |   |
                  | y.gif     CollZ  |   |                           | y.gif
CollZ  |   |
                  +------------------+   |
+------------------+   |
                      |         |        |                               |
|        |
                      |         +--------+                               |
+--------+
                      |                                                  | 
                  +-------------+
+-------------+
                  | Resource R2 |                                    |
Resource R4 | 
                  +-------------+
+-------------+

Unfortunately, this figure goes over the RFC column limit, so it'll need
some tweaking before its in final form.

- Jim

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 1 Dec 2004 17:36:01 -0800

> something's just intended to repeat something that was already 
> specified somewhere else, it makes a lot of sense to say that, instead 
> of leaving readers like myself confused :-)
>

This is confirming evidence for what I thought -- Julian, you have an 
extraordinarily good memory, even among this techie crowd!  I do not 
find repeated information to be confusing because with my poorer 
short-term memory I have forgotten the details of what was already 
said.  I also tend to read quickly and sometimes skip over details.  
Other readers fall along this range but I'm guessing Julian would be at 
nearly one extreme of fine memory/detail and me (I've always supposed) 
somewhere in the middle.

Repetition need not be in the same form.  I've noticed four different 
ways that functionality *should* be repeatedly described in a spec and 
there may be more:
  1) Explain the model.
  2) List the requirements, including those that follow from the model
  3) Show one or more examples that meet the requirements and illustrate 
the model
  4) Formal definition, schema (ABNF or DTD or other) of syntax

When exactly the same thing needs to be repeated (e.g. method FOO has 
the same error conditions as method BAR) we can consider cut-and-paste 
of small sections, or using a table or some other way to make the 
information obvious.  It's the silent or assumed references that scare 
me most.

Lisa

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 1 Dec 2004 23:09:54 -0500

Thanks, Jim!  Here's a reformatting which should avoid the column wrap 
problem.
Cheers,
Geoff

+------------------+
| Root Collection  |
|  bindings:       |
|  CollX           |
+------------------+
    |
    |
    |

+------------------+
| Root Collection  |
|  bindings:       |
|  CollX     CollA |
+------------------+
    |           |
    |           +--------------------------+
    |                                      |
+-------------------+                      |
| Collection C1     |<------------------+  |
| bindings:         |                   |  |
| x.gif      CollY  |                   |  |
+-------------------+                   |  |
    |          \                        |  |
    |           \        (creates loop) |  |
    |            \                      |  |
+-------------+   +-----------------+   |  |
| Resource R1 |   | Collection C2   |   |  |
+-------------+   | bindings:       |   |  |
                  | y.gif     CollZ |   |  |
                  +-----------------+   |  |
                      |         |       |  |
                      |         +-------+  |
                      |                    |
                  +-------------+          |
                  | Resource R2 |          |
                  +-------------+          |
                                           |
           +-------------------------------+
           |
           |
+-------------------+
| Collection C3     |<------------------+
| bindings:         |                   |
| x.gif      CollY  |                   |
+-------------------+                   |
    |          \                        |
    |           \        (creates loop) |
    |            \                      |
+-------------+   +-----------------+   |
| Resource R3 |   | Collection C4   |   |
+-------------+   | bindings:       |   |
                  | y.gif     CollZ |   |
                  +-----------------+   |
                      |         |       |
                      |         +-------+
                      |
                  +-------------+
                  | Resource R4 | 
                  +-------------+

[email-masked] wrote on 12/01/2004 08:04:00 PM:

>                   | y.gif     CollZ  |   |                           | 
y.gif
> [attachment "bind_fig.txt" deleted by Geoffrey M Clemm/Lexington/IBM]

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Dec 2004 09:47:27 +0100

> nearly one extreme of fine memory/detail and me (I've always supposed) 

Are you seriously proposing optimizing specs for readers who read 
quickly and skip over details? What makes you think that if stuff gets 
repeated this type of reader will get it?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Dec 2004 13:07:36 +0100

> Thanks, Jim!  Here's a reformatting which should avoid the column wrap 

OK (and thanks!), added in 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.2.3.1>. 
Note that I add to remove some vertical space because Geoff's 
reformatted version was too long for an RFC page.... :-)

Which of the open issues below can be closed now?

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.3_copy_depth_infinity>
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.3_copy_example>
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.3_copy_vs_loops>

It seems to me that this example covers all of them, not just the first...

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 2 Dec 2004 08:59:14 -0500

I share Julian's astonishment.

Gratuitous repetition is a significant source of potential
error for a careful reader, since after reading the same content for the
third time, a careful reader will often be driven in frustration to skim
over the repeated material, and risk missing some normative statement that
happened to only appear somewhere in that third repetition.

Given a choice of optimizing for the careful reader or optimizing for
the skimmer, I find it hard to believe we would chose to optimize for
the skimmer.

The question of whether to include different forms of specification
(i.e. text, pictures, examples) is very different.  Here I agree that
complementing text (which is essential and normative) with a few 
carefully selected pictures and examples is very desireable.  I am
sure everyone agrees with that.

Cheers,
Geoff

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 2 Dec 2004 08:41:53 -0800

Seems to me the crux of the matter is your model of the reader of
specifications. If your reader is very technically adept, detail-oriented,
and a careful reader, then you'll want minimal repetition. If your reader is
less technically skilled, and is more prone to deep reading of only portions
of a specification, then repetition is good. Yaron was of the opinion that
many implementers only ever read the examples (and he was never prone to
hyperbole :-).

- Jim

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 2 Dec 2004 12:10:25 -0500

Perhaps this explains why some of the 2518 semantics/syntax
can only be inferred from the examples (:-).

Cheers,
Geoff

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 2 Dec 2004 09:41:56 -0800

I'm proposing optimizing the spec for the average reader who reads 
carefully (even when I read as carefully as I can, I do not remember 
every detail of the specification).  I know that the reader eventually 
gets it when a spec is well-written because of experience, both with 
myself and with others, with well-written specs and badly-written 
specs.

Besides, I've never advocated simple repetition.  Mostly we've been 
talking about making requirements explicit, rather than have them "fall 
out" of the model.  That's more than just repetition, it's more even 
than rephrasing -- it helps people with poor memories but also people 
who have different conscious or unconscious assumptions when they read 
the model description.

Lisa

On Dec 2, 2004, at 12:47 AM, Julian Reschke wrote:

>> Other readers fall along this range but I'm guessing Julian would be 
>> at nearly one extreme of fine memory/detail and me (I've always 
>> supposed) somewhere in the middle.
>> ...
>

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 2 Dec 2004 09:46:21 -0800

If you are truly astonished, it must be because you have not carefully 
been reading my previous emails and remembering the details.  Perhaps 
you have been skimming them?

I have never advocated gratuitous repetition or optimizing for the 
least careful reader. I have been advocating making requirements 
explicit, rather than leaving them to be deduced; and I have been 
advocating more examples, and I have pointed out that complementing 
text helps skimming readers as well as careful readers with different 
backgrounds and assumptions.

Lisa

On Dec 2, 2004, at 5:59 AM, Geoffrey M Clemm wrote:

> at

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 2 Dec 2004 11:27:45 -0800

> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-lates
> t.html#rfc.issue.2.3_copy_depth_infinity>

This can be closed.

> t.html#rfc.issue.2.3_copy_vs_loops>

This can be closed.

> t.html#rfc.issue.2.3_copy_example>

I'm still not 100% sure what cases this is intended to cover. My
interpretation is that it covers (a) the target of a loopback binding, as
well as (b) the case where there are multiple bindings to the same resource.
We currently have an example for (a) and not (b).

I'd like to see the following example added to address this shortcoming.

Given the following collection hierarchy:

+------------------+
| Root Collection  |
|  bindings:       |
|  CollX           
+------------------+
   |            
   |  
   |                 
+----------------+ 
| Collection C1  | 
| bindings:      | 
| x.gif    y.gif | 
+----------------+
   |         |        
   |         |    
 +-------------+   
 | Resource R1 |    
 +-------------+

A COPY of /CollX with Depth infinity to /CollY results in the following
collection hierarchy:

+------------------+
| Root Collection  |
|  bindings:       |
|  CollX     CollY |
+------------------+
   |              \
   |               \
   |                \           
+----------------+  +-----------------+
| Collection C1  |  | Collection C2   |
| bindings:      |  | bindings:       |
| x.gif    y.gif |  | x.gif     y.gif |
+----------------+  +-----------------+
   |         |          |         |
   |         |          |         |
 +-------------+      +-------------+
 | Resource R1 |      | Resource R2 |
 +-------------+      +-------------+

Assuming that those are the only two cases intended to be covered, the
addition of this example would close this issue.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Dec 2004 21:09:48 +0100

Jim Whitehead wrote:
>>t.html#rfc.issue.2.3_copy_vs_loops>
> 
> 
> This can be closed.

Thanks, done 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html> 
updated accordingly).

>>t.html#rfc.issue.2.3_copy_example>
> 
> 

I do agree that this the other case the text covers, and that our 
example currently doesn't show it explicitly (it does show it somehow 
for the collection resource binding structure being re-created, but 
people may be be aware because this also illustrates the bind loop 
behaviour).

Any objections to *not* adding a new example, but just adding a second 
binding to y.gif to the example in 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.2.3.1>?

Best regards, Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 2 Dec 2004 12:18:25 -0800

> Any objections to *not* adding a new example, but just adding 
> a second binding to y.gif to the example in 
> t.html#rfc.section.2.3.1>?

I thought about this, and lean towards having the second example because
(a) the first example is already complex
(b) it has a separate example for each of the two cases being considered

That said, I could live with a single example.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Dec 2004 21:39:16 +0100

> That said, I could live with a single example.

Fair enough, I added it as second example, see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.2.3.2>. 
Note I also updated the section title for the previous example.

Best regards, Julian

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 3 Dec 2004 09:12:49 +0100

One has to admit, it was quite boring on the list during the last 
months (apart from the issue tracking system issue - that was a great 
one). I therefore welcome any fighting, disagreements, ironic comments, 
shallow arguments, evasion tactics, finger pointing and eye poking.

//Stefan

---

From: Julian Reschke <[email-masked]>
Date: Fri, 03 Dec 2004 09:22:07 +0100

Geoffrey M Clemm wrote:
> to creating a new resource.  I can imagine repository vendors having strong

Checking 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#determining.whether.two.bindings.are.to.the.same.resource>...: 
can I close the issue after making the editorial changes and replacing 
MOVE by REBIND? That is, do we need to mention MOVE here? If yes, any 
suggested text?

Best regards, Julian