Subject: Re: Protocol Operations

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 8 Feb 2005 11:49:18 -0800

Yes, I did the text you posted (data_path2.txt) and made the comments
based on that.

Having Flags in the PATH which define Operations, such as F_REPLACE,
F_CREATE, F_APPEND, F_PREPEND  seems quite inefficient to me. These
should be part of the top-level Operation itself, which defines the
Operation TLV. The protocol should not have to parse each PATH to figure
out what the operation is.

Also, another comment I made -> is this correct in the current grammar
->
DATA := [DATARAW] | <PATH-DATA>+ ?? 

Let me know,

Thanks
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim

> Having Operations as part of Flags, seems quite inefficient to me.
> We will have a single Operation TLV which could have multiple PATHs.
> It will be a lot simpler as well as efficient to have the Operation
> defined in the beginning of this TLV, rather than in each PATH Flag.
> Thus my preference. 

I think you meant having "flags as part of the operations" as opposed to
"operations as part of Flags"? Otherwise i am not sure which flags you
are refering to. Did you read the text i have been posting?

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 8 Feb 2005 15:06:33 -0500

> out what the operation is.

The operation actually comes before the path-data. DEL for example is an
operation; SET is another etc.
This is then followed by the stuff you are seeing posted around which
includes flags.
The flags do not define the operation perse; they may refine it.
Similarly, selectors may refine the path to the data.

> DATA := [DATARAW] | <PATH-DATA>+ ?? 

That hasnt changed as far as i am concerned; Joel posted another scheme
of collapsing things but does not change the grammar.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 8 Feb 2005 16:28:12 -0500

At the moment, in fact, the following are allowed in a SET operation inside 
a path-data TLV after the path and the optional selector:

IF there is no selector:
  (1)    one DATARAW or
  (2)    multiple PATH-DATA TLVs, each of which is to be interpretted in 
the context of the containing path-data

If there is a selector, and it selects one thing, then the above still applies.

If there is a selector, and it selects multiple things, then one is allowed 
to have
  (3)    one DATARAW, to be applied to all the items selected
  (4)    n DATARAW, equal to the number of items selected
  (5)    n PATH-DATA, one to be applied to each item selected
  (6)    one PATH-DATA to be mapped against each item selected.

The Selector is used for content keying (which selects a single item) or 
for BLK selection.
Note that if key's are not unique then it is not possible o know how many 
things will be selected by a content selection.  Please let us stay away 
from that.
Note further that at the moment we at least have the simplification that 
one can not do blocks and keys at the same time.

Note that all 6 of the cases above have been requested explicitly on the 
list.  I would be more than happy to see a reduction in the number of 
combinations we support.

And I am VERY happy to see any comments from someone other than me, 
Weiming, and Jamal.

Thank you,
Joel

PS: Successful GET responses look like SET requests.  GET requests can not 
have DATARAW elements, but can have nested PATH-DATA.  DELETE requests 
would parallel GETs.