Re: Initial proposal for Issue 4041

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 16:48:21 UTC