Subject: RE: [Forces-protocol] RE: GET/SET in one msg ?

From: "Deleganes, Ellen M" <[email-masked]>
Date: Fri, 15 Oct 2004 20:39:35 -0700

The thing that is appealing about the proposal is not so much being able
to combine operations as the notion of being able to define new ones
without having to define new messages.

I presume that the "rules" (e.g. never combine operations X and Y) are
not something the protocol is expected to enforce. Otherwise, I think it
would add unnecessary complication to the protocol processing. 

It also sounded like Joel was suggesting that if operations happened to
be combined in a single message, the order shown in the protocol does
not imply the order in which the implementation has to execute them. Is
that right?

Regards,
Ellen

-----Original Message-----
From: Khosravi, Hormuzd M 
Sent: Friday, October 15, 2004 6:27 PM
To: Joel M. Halpern; [email-masked]
Cc: Yang, Lily L; [email-masked]; Steve Blake; Alan DeKok;
Deleganes, Ellen M; [email-masked]; [email-masked]
Subject: RE: [Forces-protocol] RE: GET/SET in one msg ?

Does anyone else have an opinion on this, especially if it is different
from what Joel suggested ?
Pls do let us know asap. 

I am fine with this, just want to make sure there are no contradicting
opinions in the Model team.

Thanks
Hormuzd 
P.s. BTW, I don't think I still got a real example on how this would be
useful.

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Friday, October 15, 2004 6:20 PM
To: [email-masked]
Cc: Khosravi, Hormuzd M; Yang, Lily L; [email-masked]; Steve
Blake; Alan DeKok; Deleganes, Ellen M; [email-masked];
[email-masked]
Subject: Re: [Forces-protocol] RE: GET/SET in one msg ?

That would be my suggestion.

To be specific, I would not have a Query and a Modify message, but
rather 
would have an Operation message which can carry whatever operations we 
decide we need.  We may make specific rules that say "for sanity, never 
combine X and Y".

I believe this will keep the protocol simpler.

Yours,
Joel

At 08:40 PM 10/15/2004 -0400, Jamal Hadi Salim wrote:
>Joel,
>We are sort of in a rush here to beat a deadline ;-> Give it to us in
>boolean logic please ;->
>
>Did i read correctly that since we may have multiple operations (we
have
>been discussing event un/subscribe as something that would appear as an
>operation for example) then the way to go forward is have GET as an
>operation?
>
>cheers,
>jamal
>
>On Fri, 2004-10-15 at 20:11, Joel M. Halpern wrote:
> > If we are sure that the only two operations we will ever need are
GET and
> > SET, then we could probably simply declare that a message was either
a GET
> > message or a SET message.
> > However, we have had suggestions of INSERT operations, and I would
hate to
> > design the protocol so that we could not add other operations later.
And
> > some combinations of operations may make sense together (insert item
> > A.  Add reference to A in item B.  Delete obsoleted item C.)
> > Thus, I tend to think that it makes sense to structure the protocol
so 
> that
> > a single emssage can carry multiple operations.
> > At the same time, as I said earlier, I would either prohibit or warn
> > against combining update and read operations in the same 
> request.  Requests
> > to read, for example to confirm the results of an update, ought to
be sent
> > separately so that the FE does not need to worry about the order of
> > application.
> >
> > Yours,
> > Joel
> >
> > At 03:55 PM 10/15/2004 -0700, Khosravi, Hormuzd M wrote:
> > >No, I don't that's why I asked...since this was coming from Joel's
> > >proposal.
> > >I didn't get a good reason from his email either, but it seems like
he
> > >would like to have it supported by the protocol anyway.
> > >
> > >Joel, do you have any examples for us ?
> > >
> > >
> > >Thanks
> > >Hormuzd
> > >
> > >-----Original Message-----
> > >From: Yang, Lily L
> > >Sent: Friday, October 15, 2004 3:52 PM
> > >To: Khosravi, Hormuzd M; 'Joel M. Halpern'; [email-masked]';
> > >'Steven Blake'; 'Alan DeKok'; Deleganes, Ellen M;
[email-masked]'
> > >Cc: [email-masked]'
> > >Subject: RE: GET/SET in one msg ?
> > >
> > >I don't understand why you would want to do such a thing. Do you
have
> > >any example in mind?
> > >
> > > > -----Original Message-----
> > > > From: Khosravi, Hormuzd M
> > > > Sent: Friday, October 15, 2004 2:04 PM
> > > > To: Joel M. Halpern; [email-masked]; Steven Blake;
> > > > Yang, Lily L; Alan DeKok; Deleganes, Ellen M;
[email-masked]
> > > > Cc: [email-masked]
> > > > Subject: GET/SET in one msg ?
> > > >
> > > > Hi Folks,
> > > >
> > > > We (protocol team) are finalizing some of the msgs and one of
> > > > the issues which is being discussed is whether GET/SET
> > > > operation need to be combined in a single msg...(currently we
> > > > have them as separate msgs). I have never seen this being
> > > > done in practice i.e. command bundling of GET/SET, but if you
> > > > guys have some experience/opinions on this, pls do let us know.
> > > >
> > > >
> > > > Thanks a lot,
> > > > Hormuzd
> > > >
> > > >
> >
> >
> > _______________________________________________
> > Forces-protocol mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/forces-protocol

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Oct 2004 23:56:30 -0400

I agree that rules about protocol combination are NOT for the protocol to 
enforce.  We would write them as ~the sender should not do X and Y, and 
receiver behavior if it receives such is indeterminant~.

I would agree that there should be no requirement on the order of 
application of operations in a message, although there probably is an 
atomicity requirement of the form ~either all of them will be done, or none 
of them will be done~.
Another way of putting this is that the protocol structures themselves 
should not mandate the presence of an order requirement, even if we as a 
working group were to decide that we wanted such ordering to be enforced.

Yours,
Joel