Subject: Re: Protocol Operations

From: "Putzolu, David" <[email-masked]>
Date: Tue, 8 Feb 2005 13:46:30 -0800

Thanks for the nice clear explanation Joel.

I believe I understand the use of (1) and (2).

It seems to me that (3), (4), (5), and (6) are achievable
using multiple (1)s and (2)s, perhaps in combination with
the transactional flags.  Is that true? 

If it is true, I guess the question I would have is how
common do we expect situations to arise where we need (3-6)?
If it is a rare thing, then I would urge getting rid of
the complexity and just paying a few extra bytes in encoding
by doing multiple (1)s and (2s) in the rare cases where 
multiple similar operations are actually needed.

-David

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, February 08, 2005 1:28 PM
To: [email-masked]
Subject: Re: [FORCES] Protocol Operations

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.

At 02:49 PM 2/8/2005, Khosravi, Hormuzd M wrote:
>Also, another comment I made -> is this correct in the current grammar
>->
>DATA := [DATARAW] | <PATH-DATA>+ ??

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 8 Feb 2005 20:45:19 -0500

Yes, at what I consider a modest cost in bytes, all of cases (3), (4), (5), 
and (6) can be covered by (1) and (2).
(In fact, at a somewhat larger cost in bytes (2) could be covered by (1).)
Doing just (1) and (2) would be a reasonable tradeoff that would produce 
what I would consider a clearer and more robust structure.

Thank you,
Joel