RE: Adv Coll review

Comments below.

> -----Original Message-----
> From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com]
> Sent: Sunday, August 01, 1999 5:01 PM
> To: Slein, Judith A
> Subject: RE: Adv Coll review
> 
> 
> 
> 
> > The discussions that motivated defining "reference" have 
> been removed from
> > the spec, so I agree that we could also remove the 
> definition, except that
> > ...
> >
> >> Ordinary Resource - This term is poor because it doesn't say
> >> in what way the
> >> resource is ordinary.  Secondly, I think the definition might
> >> be wrong... but if
> >> it is right, then the ugly term "non-reference resourc" 
> would be more
> >> descriptive.
> >
> > There are some discussions that contrast "ordinary resources" with
> > "references".  I'm happy to replace "ordinary resource" 
> with "non-reference
> > resource", but then we do need to define "resource" in 
> order to understand
> > what a "non-reference resource" is.
> 
> It is important to understand what a resource is.  I already 
> understand what
> one is, so I don't have a good perspective on whether we need 
> to devote much
> space defining "resource".  The definition in an earlier RFC 
> that Jim often
> references works for me as long as we dedicate time defining 
> bindings...
> which I think we do.  I guess it's also important to be clear 
> if we feel
> references are attributes of resources or of URI's.  It looks 
> we have put
> this stake in the ground here.  We say they are 
> characteristics of resources.
> The next time I review the spec, I'll have to keep this in mind.
>

We say that references are resources (not attributes or properties of
resources).
 
> 
> > I like the definition of "reference" that is currently in 
> the spec: "A
> > resource whose purpose is to provide access to another 
> resource."  It has to
> > encompass redirect references and (in case we ever add them) direct
> > references, strong and weak references (in case we ever add 
> support for
> > referential integrity), and it has to exclude bindings.  I think the
> > definition does that.  If it is more restrictive than usage in other
> > contexts, I don't care about that.
> Interesting.  I don't even want to think about these other 
> reference types
> right now.  It makes my brain hurt trying to think how they might come
> back into the spec. :-) -- When I read this definition of 
> "reference" I
> have to admit it didn't occur to me that it excluded 
> bindings.  I don't
> know if knowing this is important enough to bring attention 
> to this there.
> Once again, when I review the spec again, I'll keep this in mind.

I agree it is worth calling attention to the fact that references exclude
bindings.  "Association" was supposed to be the general term that includes
both references and bindings.

> 
> I guess technically I'd like the term "reference resource" to contrast
> with "non-reference resource".   Of course the heat of active 
> discussions,
> I suspect the word "resource" will be elided... but as far as the spec
> goes, my preference is to include the word "resource".  -- I 
> can imagine
> (because I've already done it in a server that predates WebDAV)
> that as WebDAV evolves, we're going to see properties that have values
> that *reference* resources.  If we start typing values, we're going to
> be very tempted to use the word "reference" there too.  I'd like to
> keep the official wording distinctive for this reason.
> 

Agreed.

> 
> 
> > That said, if you have in mind a different definition that meets the
> > constraints I listed, we should consider it.  Geoff likes 
> to think of
> > references as resources that instantiate a relationship 
> between two URIs, so
> > maybe we could consider that as a definition.
> No.  The definition is fine for now.  I just never thought of 
> references as
> actually being associated with the resource.  I'll try that 
> model on for size
> when I next review the spec.
> 
> 
> >> 4.1 Shared Resources -- Overview
> >>
> >> "HTTP and WebDAV servers already provide URI mappings, so
> >> there is little extra
> >> work involved in allow clients to create them."  -- I don't
> >> understand this.
> >> How do HTTP and WebDAV do this?
> > HTTP and WebDAV servers do map absolute URIs to resources.  
> How they do this
> > is up to them.
> Yes, but how they do it now will determine how difficult it 
> will be to leverage
> their current mapping schemes to the new semantics.  Current 
> server's schemes
> tend to be trivial.  They aren't necessarily condusive to 
> BIND semantics.  Sure,
> GET processing will be able to reuse much of the existing code.  But
> UNBIND/DELETE and
> MOVE could pose a performance problem for those 
> implementations since they'll
> have to look for aliasing.    I just feel that saying what 
> we're saying will
> trivialize the task or perhaps encourage implementors to try 
> to leverage the
> existing implementation when that may not be optimal.
> 

Agreed. We'll take out the remark about servers already providing URI
mappings.

> 
> 
> >> 4.2 Bindings
> >>
> >> first sentence -  I believe that sentence needs the word URIs
> >> replaced with "URI
> >> segments".
> > I'm not seeing the sentence you reference.  Are you looking 
> at 03.4 revision
> > of the spec?  I think the first paragraph under 4.2 (which 
> Jim drafted)
> > gives an admirable explanation of the relationship between 
> bindings, URI
> > segments, resources, and internal member URIs that makes it 
> clear how what
> > we say about bindings relates to what rfc 2518 says about 
> internal member
> > URIs.
> I'm looking at draft-ietf-webdav-collection-protocol-04 which is what
> I think you meant.  It says...
> 
>    Bindings are part of the state of a collection. In general,
>    there is a one-to-one correspondence between a collection's
>    bindings and its internal member URIs.
> 
> This of course takes us back to look at our definition of "Internal
> member URI".  I think I am mistaken as I look at that.  I thought
> it was suggesting that a collections state (implementation) should
> consist of a set of internal member URI's.

Right. We are saying that it's the bindings, not the internal member URIs,
that are part of a collection's state.  It helps to read this paragraph in
the context of the definition of Internal Member URI in section 2.

> 
> As I read further I do see something that seems odd...
> 
>    The final segment of each internal
>    member URI identifies one of the bindings that is part of the
>    collection's state, unless the internal member URI is not 
> bound to a
>    resource.
> 
> Is it possible for an internal member URI not to be bound to
> a resource?   (BTW, it's interesting that we say "bound" here
> and not "mapped" since we are talking about URI's... not URI
> segments.)

Right, it should say "mapped", not "bound."  Maybe we can get Jim to
describe a case where an internal member URI is not mapped to a resource.

> 
> 
> 
> 
> > We're trying to distinguish between bindings and URI 
> mappings, and to show
> > how creating a single binding can result in multiple new 
> URI mappings.
> >
> > We can try to tighten up the description of the example.  
> Based on the
> > information given, we can only identify 2 URI mappings for 
> each resource,
> > but there might be others in addition.
> 
> Sounds fine.  I was being too picky.
> 
> 
> >> third paragraph - "For a resource implemented by a
> >> computer..." -- Ummm... if
> >> we're going to say "implemented by a computer" then we should
> >> explain what the
> >> alternative is.  As far as I know, all resources are
> >> "implemented by a computer"
> 
> > I'd be happy to get rid of the qualification, but Jim may 
> have something
> > particular in mind here.  That a resource doesn't have to 
> exist online?
> 
> If a tree falls in the forest...?   I think it's a 
> significant distraction.
> 

Let's wait and get Jim's two cents before deciding what to do about this
phrase.

> 
> > > paragraph after the diagram - The second sentence I believe
> > > talks about the
> > > previous paragraph and the first sentence is unrelated and
> > > actually is a new
> > > thought not even related to the diagram.
> >
> > We could get rid of the first sentence, which gives a 
> capsule definition of
> > "resource".  Since a resource appears in the diagram, it's 
> not altogether
> > irrelevant, but it might lead you to expect to see entities 
> in the diagram,
> > and we removed those.
> What got my attention was that the diagram shows many URI's mapping to
> a resource and my quick reading of that took it to talk about a single
> URI mapping to multiple resources... which is not what the 
> diagram shows.
> My reading of course was not strictly correct, but I don't 
> think that first
> sentence is not really helpful given the diagram doesn't show 
> entities and we
> don't talk about entities anywhere else.  If we want to 
> define resource,
> we can do that at the top of the document where all the other 
> definitions are.
> And if we do that, I think we should just reference the rfc 
> that's dedicated to
> that. Anyway, bringing entities into this here seems 
> distracting.  Especially
> for just a single sentence.

Agreed.

> 
> 
> >> paragraph beginning "The identity of a binding is determined
> >> by the URI segment
> >> (in it's collection) and the resource that the binding associates."
> >>    -- interesting definition.  Something makes me
> >> uncomfortable making this
> >> definition... but I haven't read whole spec so this
> >> definition might be
> >> necessary later.
> > A binding is a relationship between a URI segment in a 
> collection and a
> > resource.  We want to say that both the URI segment and the 
> resource are
> > essential to the relationship.  If you change either one of 
> them, the
> > relationship (binding) goes out of existence and is 
> replaced by a different
> > relationship (binding).
> Sounds fine.  I can't explain my nervousness.  This at least makes the
> definition clear.  When I review the spec again, I'll try to 
> notice if the rest
> of the document is consistant with this.
> 
> 
> > It also affects the way we talk about the integrity of 
> bindings. In a sense,
> > it is impossible for the integrity of a binding to be 
> compromised. It can't
> > happen that a binding that once associated /X/Y with 
> resource R comes to
> > associate /X/Y with a different resource R' or no resource 
> as a side effect
> > of some operation on another binding.  But what could 
> happen is for the
> > binding to be destroyed as a side effect of some operation 
> on another
> > binding.  So when we require that the integrity of bindings 
> be guaranteed,
> > we say that servers have to insure that bindings cannot be 
> destroyed as a
> > side effect of an operation on another binding.
> Sounds fine I guess.  I'm still uneasy though. My tendency is 
> to think of all
> this from a collection-centric implementation perspective 
> whereby the binding is
> identified by the collection and member URI segment.  And 
> that the value of the
> binding is the is a pointer to a resource via some 
> unspecified mechanism.  And
> integrity is a matter of a breakdown in that unspecified 
> mechanism.  As I said,
> your approach of saying the binding is the 3-ple sounds 
> simplier as far as the
> spec goes.  I'll try it on for size.
> 
> 
> >>   -- second sentence of this paragraph talks about the
> >> resource being destroyed.
> >> I don't like this.  The resource can't be destroyed within
> >> the protocol.  It can
> >> only be dereferenced... so saying this right here early in
> >> the document is a
> >> distraction.  If we want to talk about out of band
> >> destruction, we can talk
> >> about it as a caveat after we've established the basic
> >> concepts..    Just
> >> introducing the possibility here is distracting.
> > Let's say "If the resource goes out of existence, the 
> binding goes out of
> >existence."
> I remain uncomfortable with this... but I see what you are 
> trying to do and I
> don't have a suggestion at hand.

One thing we could do is move all the discussion related to integrity out of
4.2 into a separate section -- maybe following the DELETE and MOVE sections.
At that point it should make sense to talk about destroying a resource
because DELETE talks about when it is permissible for a server to reclaim
system resources for a resource.  However, there was strong resistance to a
separate section on integrity in the design team, and I personally think
that at least the paragraph on the identity of bindings belongs in the
general discussion of the nature of bindings.  We could say "If the resource
goes out of existence (as a result of some out-of-band operation), the
binding goes out of existence."

> 
> Some rewording also has to be done 2 paragraphs later.
> 
> 
> > I agree we should reword this, but I don't want to use the 
> expression
> > "referencing", since bindings are not references in our 
> usage of those
> > words.  Maybe "...notifying some server that manages a 
> binding to the
> > resource."
> I'm not sure about "some", but I think you've got the right idea. :-)
> 
> >> 4.2.2 Bindings to Collections
> >>
> >> paragraph one, last last sentence -- REally.  It must respond
> >> with 506 Loop
> >> Detected?  Even if they are benign subloops?
> >
> >I'm not seeing how a loop could be benign for a Depth: 
> infinity request.
> >The kind of case we had in mind was:
> >B1 is a binding to collection C1, which contains a binding 
> B2 to collection
> >C2, which contains a binding B3 to collection C1.
> >
> >What kind of case were you thinking about?
> The same but... where the root of the infinite tree 
> (specified by the request
> URI) is C4 and not involved in the loop.  C4 might have a C1 
> as a member for
> example and the loop lies entirely within the tree.  If the 
> server can deal with
> this, I don't see a reason for returning an error code.  But 
> perhaps I missed
> the purpose for returning an error code for loops.
> 

I don't really see why the case is different if the loop is at the top level
versus lower in the hierarchy.  But it seems right that if the server can
detect the loop, it can do the right thing for a DELETE, MOVE, or COPY.
What would we like the response element to be for a PROPFIND when it
encounters a loop?  A 506 might be appropriate for that one response
element.

> 
> > We currently define 2 compliance classes in this spec: one 
> for ordering, and
> > one for shared resources (bindings + redirect references).
> This satisfies my concerns.
> 
> 
> Jason.
> 
>

Received on Tuesday, 3 August 1999 14:54:09 UTC