Re: Initial proposal for Issue 4041

Hi Frederick

This sounds good but I don't understand how

> 2. Client is concerned about privacy and would prefer that there is  no logging

actually works. How does the client knows that that the logging is done in the server and that server even exposes the assertion ?
Why would the consumer even do the intersection ? To ensure the provider does whatever is expected by the client. I find it
difficult to imagine how the intersection works to ensure the providers do not do *specific* features. The client has its set of 
requirements, this is what the client can do/expects, in a strict more the intersection just works if those requirements are met. It 
doesn't really matter, does it, in the strict mode, whether the intersection fails because the unknown assertion which causes the 
intersection failure happens to have ignorable attribure or not ?

Do you disagree with the proposed text ? If yes, then what you disagree with ? I don't mind updating the actual scenario described, 
as you suggested below...

Thanks, Sergey


> Sergey
>
> I think the following additional explanation could help:
>
> 1. Provider always logs, so states it, but as ignorable. Logs may not  be exposed to client, but they exist.
> 2. Client is concerned about privacy and would prefer that there is  no logging
> 3. Hence client uses strict mode, does not include assertion in  client policy, incompatible policies, which is desired outcome
>
> Client B couldn't care less, uses lax mode, no problem, compatible  policies.
>
> Hence ignorable allows a client decisions based on policy.
>
> Does this make sense? I agree that if we could find a better example,  it might be an improvement.
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
> On Feb 21, 2007, at 5:56 AM, ext Sergey Beryozkin wrote:
>
>> Hi Frederick
>>
>> Many thanks for your comments...
>>
>> > The intent is to provide a logging assertion to allow those who care
>> > to know about it, but to allow others to ignore it. Do you disagree
>> > with that?
>> No I don't. It just that the section does not say that directly. It  says the reason a logging assertion is marked as
>> wsp:ignorable is  to address the concerns of the requesters which might not be  comfortable with the provider doing logging.
>> To be honest I don't understand how a requester can express in its  requirements that it does not want a provider to do logging.
>> If it  wants something to happen then it lists the assertions it's aware  of in its requirements.
>>
>> I believe the following is true : provider does the logging. It  wants to express this fact through the assertion. The reason
>> provider exposes whatever it can do through the assertion is for  someone to note it. Now the provider is also concerned that not
>> all  requesters may understand what logging is about hence the provider  wishes those requesters to ignore it. This is is the
>> primary  motivation.
>>
>>  Now we have consumers. Some consumers may work in the strict mode.  They choose from a start to fail at the intersection stage
>> if the  encounter ignorable assertions which are not part of their  requirements.
>>  Likewise, some consumers don't mind ignoring such assertions which  are not part of their requirements.
>> Different consumers, different reasons for ignoring such  assertions. This is what a strict vs lax modes section is all  about,
>> which is a consumer's world.
>>
>> So my proposal is to update the first section something like this  (perhaps a bit verbose, can be edited later) :
>>
>> "Suppose Contoso decides that it will log all SOAP messages sent  and received in an exchange so that consumers can analyse
>> logging  statistics through the management interface Contoso provides. This  behavior has no direct impact on the messages sent
>> on the wire, and  therefore does not affect on the wire interoperability.
>> However Contoso would like the consumers of its service be aware of  Contoso doing logging as it may of interest to those
>> consumers who  are aware of the semantics of this logging. Contoso includes a  Logging assertion in its policy to enable such
>> parties to be aware  of logging.
>> For example, some consumers might choose to talk to the Contose  service only if they can later see themselves the logging
>> statistics in which case they'll add the logging assertion to its  set of requirements.
>>
>> Contoso is also would like to ensure that this assertion does not  prevent requesters who are either unaware of it or do not set
>> it  explicitly in its set of requirements, from consuming the service  as it does not affect messages on the wire.
>> So it marks the Logging assertion with the wsp:Ignorable attribute  with a value of "true".
>>
>> Thus Contoso indicates that a requester may choose to either ignore  such assertions or to consider them as part of policy
>> intersection."""
>>
>> Would you like me to comment on the issue 4041 with this proposed  text ?
>>
>>
>> Please note that with the proposed text it's now clearer IMHO why  would requesters may want to "consider them as part of policy
>> intersection" - because they want a service to tell them that it  actually has that very capability they're expecting. If they're
>> concerned about ignorable assertion then they would not consider  them, they would just switch to strict mode and fail if they
>> encounter unrecognized ones. They don't consider in this case in a  sense they're expecting them, they choose the positive
>> outcome be  affected by (unknown) them...
>>
>> But the section then in the last sentence warns the policy authors  that ignorableness is at the discretion of the consumer (I
>> submitted a seperetae issue) with the link to the strict/lax mode  discussion, hence they need to be aware of possible
>> side-effects.  So no ambiguity.
>>
>> > what do you propose instead of logging, can you please provide a
>> > proposal? I think logging makes sense since it is an example of
>> > useful information that not all clients care about.
>>
>> I agree. If possible, I'd prefer to update the text slightly,  possibly similar to the way I suggested above, to highlight that
>> the reason the logging assertion being there in the first place is  that it may be of useful interest to some consumers. If it
>> can not  be of any (genuine) ineterst to at least one consumer then it's not  a good ws-polciy assertion...so it's worth
>> highlighting this too
>>
>> Thanks, Sergey
>>
>>
>> > comments inline
>> >
>> > regards, Frederick
>> >
>> > Frederick Hirsch
>> > Nokia
>> >
>> >
>> > On Feb 20, 2007, at 6:07 AM, ext Sergey Beryozkin wrote:
>> >
>> >> Hi
>> >>
>> >> Here's some comments on the section 2.7 "Ignorable assertions" in
>> >> the primer.
>> >>
>> >> I disagree with the way this section introduces ignorable
>> >> assertions. Specifically it states that Contoso marks the Logging
>> >> assertion as wsp:ignorable in order to address the concerns of the
>> >> customers who might be concerned about Contoso doing logging. I
>> >> feel that this is not a right message.
>> >
>> > The intent is to provide a logging assertion to allow those who care
>> > to know about it, but to allow others to ignore it. Do you disagree
>> > with that?
>> >
>> >> What this section actually does in the introduction is it explains
>> >> what a strict mode can be used for, but not why providers would
>> >> mark their assertions as wsp:ignorable. It's requesters who are
>> >> selecting strict mode if they're uncomfotable with ignoring the
>> >> unrecognized assertions.
>> >>
>> >
>> > Ignorable and strict go together, so it is about use of ignorable
>> and
>> > then explains the distinction of strict and lax
>> >
>> >> Providers mark their assertion as wsp:ignorable not because they're
>> >> concerned about some requesters be uneasy about the semantics of
>> >> this (possibly unknown to them) assertion and hence choosing the
>> >> intersection to fail.
>> >>
>> >> Providers do so in order to widen the reach of such the assertion.
>> >> First of all, by including such the assertion in their policy,
>> >> providers obviously want this assertion be of useful info to
>> >> someone out there who understands what it's all about. At the same
>> >> time, they want those requesters who unaware what it's about to be
>> >> able to ignore it.
>> >
>> > agreed, that was the intent of the provided text.
>> >
>> >> I propose for this section' first paragraph be rewritten. I also
>> >> suggest to present wsp:ignorable as informational assertions in the
>> >> second paragraph, this would mark a clearer border between
>> >> wsp:ignorable and wsp:optional. Additionally, I would propose to
>> >> use a more realistic assertion example instead of <logging/>
>> >>
>> >
>> > Can you please propose a revision?
>> >
>> > what do you propose instead of logging, can you please provide a
>> > proposal? I think logging makes sense since it is an example of
>> > useful information that not all clients care about.
>> >
>> >
>> >> Thanks, Sergey
>> >>
>> >> > Attached is Word version as well.
>> >> >
>> >> > regards, Frederick
>> >> >
>> >> > Frederick Hirsch
>> >> > Nokia
>> >> >
>> >> >
>> >> > On Jan 15, 2007, at 10:26 AM, Frederick Hirsch wrote:
>> >> >
>> >> >> Attached are both clean and red-lined versions (PDF)
>> >> >>
>> >> >> regards, Frederick
>> >> >>
>> >> >> Frederick Hirsch
>> >> >> Nokia
>> >> >>
>> >> >>
>> >> >> On Jan 11, 2007, at 11:57 AM, ext Prasad Yendluri wrote:
>> >> >>
>> >> >>> Frederick,
>> >> >>>
>> >> >>> Thanks for the updated version that accounted for my comments.
>> >> >>> I am good with your changes.
>> >> >>>
>> >> >>> Could you please send a version that does not have the change
>> >> marks?
>> >> >>>
>> >> >>> Regards,
>> >> >>> Prasad
>> >> >>>
>> >> >>> -----Original Message-----
>> >> >>> From: public-ws-policy-request@w3.org
>> >> >>> [mailto:public-ws-policy-request@w3.org] On Behalf Of Frederick
>> >> >>> Hirsch
>> >> >>> Sent: Thursday, January 11, 2007 6:52 AM
>> >> >>> To: ext Prasad Yendluri
>> >> >>> Cc: Hirsch Frederick; public-ws-policy@w3.org
>> >> >>> Subject: Re: Initial proposal for Issue 4041
>> >> >>>
>> >> >>> [removing editors from cc list since this is on the work group
>> >> thread
>> >> >>> now which includes all editors]
>> >> >>>
>> >> >>> Prasad
>> >> >>>
>> >> >>> comments in line, but I agree with your concerns and attach a
>> >> >>> concrete amendment to the draft.
>> >> >>>
>> >> >>> This message contains 4 proposed amendments to the draft
>> >> distributed
>> >> >>> to the work group
>> >> >>> (ignorable-proposal-v3.pdf). I've attached a red-line to
>> show in
>> >> >>> context the proposed amendments.
>> >> >>>
>> >> >>> Amendment #1
>> >> >>> Replace 2nd paragraph lines 16-24 with the following text:
>> >> >>>
>> >> >>> "The use of the Ignorable attribute allows providers to clearly
>> >> >>> indicate which policy assertions indicate behaviors that don't
>> >> always
>> >> >>> manifest on the wire and may not necessarily be of concern to a
>> >> >>> requestor. Using the Optional attribute would be incorrect
>> in this
>> >> >>> scenario, since it would indicate that the behavior would not
>> >> occur
>> >> >>> if the alternative without the assertion were selected. "
>> >> >>>
>> >> >>> Amendment #2
>> >> >>> Remove 3rd paragraph entirely (lines 26-29).
>> >> >>>
>> >> >>> Amendment #3
>> >> >>>
>> >> >>> Add following text to follow second paragraph (at line 25)
>> >> >>> "It is incumbent of Providers to declare the behaviors that
>> >> will be
>> >> >>> engaged using policies although those behaviors may not exhibit
>> >> wire
>> >> >>> level manifestations. The Ignorable attribute allows them
>> (policy
>> >> >>> providers) to do so."
>> >> >>>
>> >> >>> Amendment #4
>> >> >>>
>> >> >>> Since the material around proposed 2.7 is written in terms of
>> >> XML, I
>> >> >>> propose we uniformly refer to ignorable in terms of the
>> Ignorable
>> >> >>> attribute. Please see the red-line for details of this change.
>> >> >>>
>> >> >>> Thanks Prasad for the useful review.
>> >> >>>
>> >> >>>
>> >> >>> Frederick Hirsch
>> >> >>> Nokia
>> >> >>>
>> >> >>>
>> >> >>> On Jan 10, 2007, at 7:02 PM, ext Prasad Yendluri wrote:
>> >> >>>
>> >> >>>> Hi Frederick,
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> Again thanks for the detailed work on this.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> I have a few comments as enumerated below:
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> 1.       Lines 29-31 state
>> >> >>>>
>> >> >>>>   "To mark an assertion as "Ignorable" the policy assertion
>> >> >>>> definition must be examined to determine that it has no wire
>> >> >>>> behavior and that it is allowed to be marked as Ignorable"
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> This is not true. We discussed this aspect during the
>> discussion
>> >> >>>> that added the "ignorable" marker but, the current WS-
>> Policy 1.5
>> >> >>>> Framework specification does not impose any such
>> restrictions on
>> >> >>>> assertions that can be marked "Ignorable". All assertions that
>> >> have
>> >> >>>> wire manifestation or not can be marked "Ignorable". I raised
>> >> this
>> >> >>>> aspect myself at the Boston F2F and I was overruled J
>> >> >>>
>> >> >>> I agree and believe we should remove this restriction. I
>> propose
>> >> >>> amendment #1 to fix this.
>> >> >>>
>> >> >>> (Note that if there is a wire manifestation then I'm not sure I
>> >> >>> understand how it can be ignored)
>> >> >>>> 2.  The sentence that follows the above text "Assertion
>> authors
>> >> >>>> need to clarify that assertions may be marked as "Ignorable".
>> >> >>>>
>> >> >>>> Not sure what this is conveying? Or how it follows the no wire
>> >> >>>> manifestation aspect of ignorable assertions stated above.
>> >> >>>>
>> >> >>>> Need more clarity on what this is saying.
>> >> >>>
>> >> >>> Along with your first point, if we adjust that, then this
>> can be
>> >> >>> removed.
>> >> >>>
>> >> >>>>
>> >> >>>>
>> >> >>>> The famous one (editor's special :):  "The Ignorable marker
>> >> allows
>> >> >>>> them (policy providers) to be truthful."
>> >> >>>>
>> >> >>>>
>> >> >>>> The Ignorable marker does not make the policy providers
>> truthful.
>> >> >>>>
>> >> >>>> A simple "to do so" is enough, as the previous statements
>> clearly
>> >> >>>> articulate the need to declare all behaviors that will be
>> >> engaged.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> I suggest a rephrase as follows:
>> >> >>>>
>> >> >>>> "It is incumbent of Providers to declare the behaviors that
>> >> will be
>> >> >>>> engaged using policies although those behaviors may not
>> exhibit
>> >> >>>> wire level manifestations.
>> >> >>>>
>> >> >>>> The Ignorable marker allows them (policy providers) to do so."
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>> I prefer this.
>> >> >>>
>> >> >>>> 4.      The "Ignorable" is referred to as different things
>> >> >>>> throughout the description.
>> >> >>>>
>> >> >>>> "The Ignorable marker allows them." , "when Ignorable flag
>> is set
>> >> >>>> to "true", "the Ignorable property does not impact",
>> "..Ignorable
>> >> >>>> attribute"
>> >> >>>>
>> >> >>>>      I suggest we stick a consistent of way characterizing it.
>> >> >>>
>> >> >>>
>> >> >>> Agree, thanks for reminding me of this one.
>> >> >>>>
>> >> >>>>
>> >> >>>> Thanks,
>> >> >>>> Prasad
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> -----Original Message-----
>> >> >>>> From: public-ws-policy-eds-request@w3.org [mailto:public-ws-
>> >> policy-
>> >> >>>> eds-request@w3.org] On Behalf Of Frederick Hirsch
>> >> >>>> Sent: Wednesday, January 10, 2007 12:27 PM
>> >> >>>> To: public-ws-policy@w3.org
>> >> >>>> Cc: Hirsch Frederick; WS-Policy Editors W3C
>> >> >>>> Subject: Initial proposal for Issue 4041
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> Attached is an initial draft proposal for issue 4041 [1],
>> adding
>> >> >>>>
>> >> >>>> ignorable in the Primer. Note that this issue did not include
>> >> adding
>> >> >>>>
>> >> >>>> material on ignorable to the Guidelines, which would be
>> related.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> This draft does not reflect the full consensus of the editors,
>> >> since
>> >> >>>>
>> >> >>>> not every editor had a chance to review it. However we felt
>> >> that it
>> >> >>>>
>> >> >>>> would be useful to provide to the committee in advance of the
>> >> F2F to
>> >> >>>>
>> >> >>>> show the direction of this work. Additional changes may be
>> >> needed.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> Thanks
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> regards, Frederick
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> Frederick Hirsch
>> >> >>>>
>> >> >>>> Nokia
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> [1] <http://www.w3.org/Bugs/Public/show_bug.cgi?id=4041
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>
>> >> >> <ignorable-proposal-v3-FH-clean.pdf>
>> >> >> <ignorable-proposal-v3-FH-red-line.pdf>
>> >> >
>> >> >
>> >
>

Received on Wednesday, 21 February 2007 17:48:35 UTC