Re: "operation name" .. an alternate proposal

Hi Mark,

Mark Baker wrote:

>FWIW, I don't even think it's necessary to have the operation name in
>the message.  All I request is that there's some bit(s) in the message
>that can be mapped via public specification to the operation name.  For
>example, I could "say" via the IETF and IANA, that all messages arriving
>on TCP port 15555 are supposed to be stored onto disk.  There, the
>operation might be called "store", yet isn't in the message, but the TCP
>port is part of the extended envelope of the message, and therefore is
>sufficient to identify the operation.
>
I am sure we can device pretty creative and private means to identify 
the operation without it being in the message or
communicated other wise directly. But why try and address this in 
indirect and round about ways when we can make this
part of the message where  it is really useful to have address the issue 
the most direct way.

If I am invoking operation 'foo' I name that operation in my message by 
putting 'foo' in a well defined place.

>I think that's the minimally acceptable scenario.  IMO, receiving a
>message and not knowing what's being asked of you, is simply not an
>option and should be actively discouraged.
>
Agree 100%.

>Mark.
>
Regards, Prasad

>
>On Thu, Jul 08, 2004 at 04:21:34PM -0400, David Booth wrote:
>  
>
>>At 12:31 PM 7/8/2004 -0700, Prasad Yendluri wrote:
>>    
>>
>>>. . . My preference would be towards a mechanism that captures [the 
>>>operation name] in the message itself . . . .
>>>      
>>>
>>I agree that this would be conceptually cleaner layering, having the 
>>message body include all and only the information that is semantically 
>>relevant to the application (since the operation name is clearly 
>>semantically relevant if it is used to dispatch).  However, my perception 
>>is that this isn't the direction the industry winds are blowing.
>>    
>>
>
>  
>