Re: [provision] RequestType should require requestID.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Jeff Larson wrote:

> Gary P Cole wrote:
>
>> Well, I may be explaining this poorly, but the PSTC's resolution in 
>> the most recent Face-to-Face was that any requestID from the original 
>> request should also identify the asynchronously-executing operation. 
>> - if the original request specifies requestID, then the response must 
>> specify that same requestID.
>> - if the original request omits requestID, then the response must 
>> specify a requestID that the provider generates.
>> Either way, a requestor should specify the requestID from the 
>> original response as the value of the 'asyncRequestID' argument in a 
>> statusRequest (or a cancelRequest).
>
>
> Yes, I thought that was how we specified it in 1.0. 

It wasn't *specified* that way in 1.0, but everyone at the F2F told me 
that they had *understood* async requestIds to be something like what 
you said.

> 3) What's bad about requiring a requestID?  How big of a burden is this?
>
> I can understand why this would make the specification more concise, 
> and that
> may be reason enough to require them.   But I don't see where this makes
> things any easier for the requester or the provider.  It makes it 
> marginally
> harder for the requester that only wants to make sync requests.

I think you're right--especially if we exclude consideration of protocol 
errors. I don't have any truly compelling reason to require requestIds.  
At this point, I have only several weak reasons.  Jeff Bohren had 
another weak reason related to debugging message exchanges.

I suppose my main goal was to make the specification more crisp--it's so 
much simpler to say "must" than to explain all the "woulds" and 
"shoulds" and "depends".

Does anyone else have a strong feeling either way?