Re: ISSUE 3564: Optional Assertions may not be usable in all cir cumstances

Hi Frederick

>
> No, because it is meaningless to "ignore" an assertion that is always  applied by the provider, even if it is advisory to the 
> client. In  other words, it is not ignored in associated impact, even if client  chooses to treat as advisory and "ignore" it.

Would you agree that it would be useful to think of any assertion listed in a given policy as something which is always supported by 
their provider  ? In other words they're guaranteed to be supported.
Irrespectively of how assertions are marked they're supported by their provider and not ignored...

Thanks, Sergey

>
> No, because it is meaningless to "ignore" an assertion that is always  applied by the provider, even if it is advisory to the 
> client. In  other words, it is not ignored in associated impact, even if client  chooses to treat as advisory and "ignore" it.
>
> -- non-wire assertion states something will be done (e.g. logging) -  this happens, so is not optional.
> -- client views this as advisory, so ignores in making request, but  this is not the same as assertion being ignored in entire 
> process.
>
> The issue here is that optional has a much different meaning than  advisory.
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
> On Sep 27, 2006, at 12:45 PM, ext Glen Daniels wrote:
>
>>
>> Hi Frederick:
>>
>>> It is difficult to combine the concept of optional with its
>>> normalization implications with flagging items that can be ignored
>>> without implication of actual impact.
>>
>> Why is that?  Optional means that there is both an acceptable
>> alternative without this assertion, and one with this assertion.   Isn't
>> that the same thing as saying that the item can be ignored at the whim
>> of the consumer?
>>
>> This seems true regardless of whether the given assertion has an
>> "impact" vis. the wire messages.
>>
>> --Glen
>>
>>
>
>

Received on Wednesday, 27 September 2006 17:30:54 UTC