Re: Why is [message id] required for requests but not for other messages?

Tom Rutt wrote:

> Mark Little wrote:
>
>>
>>
> MessageID can be in the message even if a reply is not expected.  If a 
> reply is expected then the MessageID must be present.  This is the status
> quo behaviour of the Last Call spec.

I know that. Sorry, you misunderstood. I was asking whether using 
RequestID might still cause confusion because the name implies (at least 
to me) that a response is expected. Since MessageID/RequestID is 
optional and MAY occur if ReplyTo/FaultTo aren't present, there's the 
potential for confusion.

Mark.

>
> Tom Rutt
>
>>
>> Conor P. Cahill wrote:
>>
>>> Mark Little wrote on 6/16/2005, 9:13 AM:
>>>
>>> >
>>> > I didn't mean to imply you'd said sessions explicitly and thought the
>>> > rest of my message made that clear. It's just that the term 
>>> correlation
>>> > id is often used when talking about sessions. If you're just talking
>>> > about simply tying together a request and a response (with subsequent
>>> > requests having different "ids") then I reiterate that I don't have a
>>> > problem with MessageID, or (going back to the mid 80's when RPCs were
>>> > the king) SequenceNumber. I think shifting to CorrelationID runs the
>>> > risk of increasing the confusion you mention.
>>>
>>> So, to summarize, I'm saying that MessageID has proven to be 
>>> *extremely*
>>> confusing to everybody, incuding most of the people in this group.  You
>>> are saying that choosing the name CorrelationID may also have some 
>>> level
>>> of confusing.
>>>  
>>>
>> Yes, that's a fair summary.
>>
>>> So, how about using RequestID.
>>>  
>>>
>> I think it more closely maps to the requirements, particularly since 
>> you can't have a MessageID/RequestID without a ReplyTo. However, what 
>> are the semantics if you have a RequestID and no ReplyTo? Doesn't the 
>> syntax of RequestID imply a response is also required and hence the 
>> name might still be confusing? (Just playing Devil's Advocate.)
>>
>> Mark.
>>
>>> Conor
>>>
>>>
>>>  
>>>
>>
>>
>
>

Received on Thursday, 16 June 2005 14:05:38 UTC