OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Prelim Minutes of 1/25 Teleconf


Prelim minutes attached.

Please provide corrections to list before next monday morning.,

Tom Rutt

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133



Title: Minutes of OASIS WS-RX Teleconference 1/25/2007

Prelim Minutes of OASIS WS-RX Teleconference

Jan 25, 2007

 

Start Time:4:00 PM Eastern Daylight Time

 

Paul F acted as chair.

 

Textual Conventions

 

Ø  Action Item

Motion

§    Resolution

 

1         Roll Call

From Kavi:

 

meeting is quorate

 

Tom Rutt agreed to take minutes.

2         Agenda Approval

Agenda

Dial in: (Thanks to Microsoft)

(866) 500-6738 or (203) 480-8000

PC: 2365501

 

IRC/Q Mgmt(thanks to DougD): http://webconf.soaphub.org/conf/room/wsrx

1) Roll Call

 

2) Review and approval of the agenda

 

3) Approval of the Jan 18, 2007 meeting minutes

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21894/2007-01-18.html

reposted with attendance list as:

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21917/MinutesWSRX-011807.htm

4) AI Review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

 

5) New issues

 

6) Timetable

 

7) Discussion of PR Issues

 

a> PR035 Delivery Assurance

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i035

 

b> PR009 "Duplicate Elimination" and "Message Ordering"

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i009

 

c> PR020 Message ordering and duplication

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i020

 

d> PR037 Policy Assertions Must be Independent

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i038

 

e> PR038 Need to clarify relationship between the WS-RM specification and MakeConnection specification

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00064.html

 

8) Any other business

 

Bob asked to add a new item on addressing, after item number 6.

3         Approval of the 1/18 Minutes;

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21917/MinutesWSRX-011807.htm

 

Tom moved to approve 1/18 minutes, Doug D seconded.

 

§    No objections, minutes of 1/18 approved.

 

4         AI Review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

 

#0124: Chris F will present a proposal on policy assertions for WSRM Delivery assurances.

Owner: Christopher Ferris

Status: Still Open

Assigned: 2007-01-16

Due: ---

 

 

#0125: Matt to provide a final wordsmithed proposal for PR 0035.

Owner: Matt Lovett

Status: Done

Assigned: 2007-01-16

Due: ---

 

 

#0127: Doug to define WS-Policy assertion for MC so that a service can advertise that it supports MC

Owner: Doug Davis

Status: Done

Assigned: 2007-01-22

Due: ---

 

 

#0128: Doug to propose specific text to relax restriction on MS anon URI template

Owner: Doug Davis

Status: Done

Assigned: 2007-01-22

Due: ---

 

 

#0129: Gil to propose specific wording around PR0038 issue

Owner: Gilbert Pilz

Status: Done

Assigned: 2007-01-22

Due: ---

 

5         New Issues

Doug had new issue:

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00088.html

Title: Scope of CS/Offer/Endpoint

 

Description:

Current RM spec defines CS/Offer/Endpoint as:

 

/wsrm:CreateSequence/wsrm:Offer/wsrm:Endpoint

An RM Source MUST include this element, of type wsa:EndpointReferenceType (as specified byWS-Addressing). This element specifies the endpoint reference to which Sequence Lifecycle Messages,Sequence Traffic Messages, Acknowledgement Requests, and fault messages related to the offeredSequence are to be sent.

 

Implementations MUST NOT use an endpoint reference in the Endpoint element that would prevent the sending of Sequence Lifecycle Message, Sequence Traffic Message, etc. For example, using the WS-Addressing "http://www.w3.org/2005/08/addressing/none" IRI would make it impossible for the RM Destination to ever send Sequence Lifecycle Messages (e.g. TerminateSequence) to the RM Source for the Offered Sequence. Implementations MAY use the WS-MakeConnection anonymous URI template and doing so implies that messages will be retrieved using a mechanism such as the MakeConnection message.

 

The inclusion of the "Sequence Traffic Messages" actually isn't correct.  Sequence Traffic Message (ie. app messages) go to other EPRs, like wsa:ReplyTo - just like RM was even being used.  CS/Offer/Endpoint is supposed to be for RM protocol messages (Close, Terminate, AckReq...).  I think when we switched over to the new RM terms we got a bit too excited  :-)  The old text used to say:

...This element specifies the endpoint reference to which WS-RM protocol messages related to the offered Sequence are to be sent.

 

Proposal:

Remove "Sequence Traffic Message" from the current definition of CS/Offer/Endpoint.  It appears in 2 spots.

 

thanks

-Doug

 

Paul F: is there anyone opposed to this proposal.

 

Doug D moved to accept new issue and close by accepting proposal, Gil Seconcded.

 

No objection, new issue accepted and closed by accepting proposal.

6         Timetable

Paul F: we need to agree to dates, if issues are not closed at this meeting.

 

Paul F: when can editors get a next draft CS

 

Doug D: a day or two after the issues are resolved.  We assume tables regarding changes something we can update later.

 

Paul F: after that we need to commit to review the document thouroughly.  We should have a short amount of time for this review for CS vote. Is one week enough, or do we need 1.5 weeks.

 

Doug D: if the editors get it done by Friday, we can do it by the next meeting.   If posted on Monday, we need to have it be another week.

 

Paul C: why do we have to wait to batch together all changes?  If we can clearly identify which issues are resolved why cannot we endorse the editor’s draft at that stage of issue resolution.

 

Discussion on total CD diff vs last ed Diff.

 

Paul F: ask editors to have a draft incorporating all agreed changes by today by Friday this week.  We can vote this as a CD for next week.

 

Martin: we also need a diff of this next CD against the last public review draft to be produced.

 

Tom: editors can use tools to generate a diff, even if the result is rather ugly.  They can also post the clean version.

 

7         Addressing

Bob F: addressing will have another last call review on the WSDL document, which is now called the metadata document.  Can this TC review this new document?.

 

Doug D: A week after receiving this note should be enough.

 

Bob F: I am looking for feedback within the next four weeks, as to the applicability of the new spec to this wsrm TC.

 

Paul F: agreed to consolidate comments from WG.  We can have a meeting to send the comment in after we receive them from members.

 

Bob F: I will post the document as of the 30th of this month.  I need the statement by the 20th of February.

 

Tom: they changed the policy for anonymous and non anonymous reply to.   This should be reviewed by this TC.

 

8         Discussion of PR Issues

 

8.1      a> PR035 Delivery Assurance

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i035

 

Matt email: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00098.html

Hi all,

 

Following on from the discussion about using "deliver" rather than

"process to conclusion", here are some definitions that Peter and I have

worked on. We believe these definitions help define the end-to-end DA, as

they include the RMS behaviour.

 

--

 

wsrmp:DeliveryAssurance

 

When applied to an RM Destination, this element defines a policy assertion

that identifies a requirement on RM Sources. Any RM Source that transmits

messages to this RM Destination SHOULD conform to the requirement

expressed by this assertion. Conversely, when it is applied to an RM

Source this assertion identifies a requirement on RM Destinations. Any RM

Destination that receives messages from this RM Source SHOULD conform to

the requirement expressed by this assertion.

 

wsrmp:AtLeastOnce

 

Each message is to be delivered at least once. The requirement on an RM

Source is that it SHOULD retry transmission of every message sent by the

Application Source until it receives an acknowledgement from the RM

Destination. The requirement on the RM Destination is that it SHOULD retry

delivery to the Application Destination of every message that it accepts

from the RM Source. There is no requirement for the RM Destination to

apply duplicate message filtering.

 

wsrmp:AtMostOnce

 

Each message is to be delivered at most once. The RM Source MAY retry

transmission of unacknowledged messages, but is NOT REQUIRED to do so. The

requirement on the RM Destination is that it MUST filter out duplicate

messages, i.e. that it MUST NOT redeliver any message.

 

wsrmp:ExactlyOnce

 

Each message is to be delivered exactly once. The requirement on an RM

Source is that it SHOULD retry transmission of every message sent by the

Application Source until it receives an acknowledgement from the RM

Destination. The requirement on the RM Destination is that it MUST filter

out duplicate messages, i.e. that it MUST NOT redeliver any message.

 

--

 

Some additional comments:

 

Doug pointed out that we talk about the RMS and RMD here, but that the

wsrmp spec doesn't quite call out where the RMS and RMD are. For example,

if a WSDL output message is decorated with the RM assertion + a DA, we

would expect the server-side RMS to exist and do it's part, and similarly

the client side RMD has a role to play. I think that this is a separate

issue, and needs a bit of discussion, but the text for the DAs should be

ok however we resolve that.

 

Jacques: I hoped to get this out to you earlier so you could see our

thought process, but I'm running out of time before the call. I'm sorry

that time got away from me!

 

Thanks

 

Matt

 

Matt: this version uses the word deliver.  This might require tweaking the definition of deliver in the spec.

 

Matt: we should find space for these defs in the main spec, then reference them from the policy document.

 

Jacques: Three reasons to move defs to core spec. (can be referred to by RM-policy spec)

1) what people look at first , they expect DA assurances

2) already mention of DA in section 2 of core spec, reader might require more formal mention in core.

3) to understand DA definitions need to understand messaging model, in section 2.  Deliver has special meaning in section 2 of core spec.

 

Tom: what about the def of ordered deliver, and the new def of Deliver off of the email list.  They seemed agreed.

 

Jacques: I send out a new def for ordered delivery.  We also have to redefine delivery as proposed by Chris.

 

Chris Note for delivery def: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00101.html

I think I am +1'ing Stefan's comments.

 

The problem, frankly, is with the definition and use of "deliver" in the context of these definitons:

 

        Deliver: The act of transferring a message from the RM Destination to the Application Destination.

 

If I have an RMD and AD that are using transactions to exchange messages, then there may in fact be

many "deliveries" of the message frm the RMD to the AD until one of them finally commits.

 

Possibly, if we changed the definition of "deliver" to be:

 

        Deliver: The act of transferring responsibility for a message from the RM Destination to the Application Destination.

 

Then these definitions would not be as problematic.

 

the reason that I tried to avoid the use of the word deliver in my definition of delivery assurance was to

avoid this very problem.

 

Cheers,

 

Christopher Ferris

 

Jacques Def of ordered delivery: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00103.html

Proposing for  InOrder delivery assurance, in same style as previous ones:

 

 

 

Messages from a same sequence are to be delivered in the same order they have been sent by the Application Source. The requirement on an RM Source is that it MUST annotate messages so that the order in which they have been sent from the Application Source, is manifest in the message.  The requirement on the RM Destination is that it MUST deliver received messages for this sequence in the order indicated by the annotation mechanism - e.g. sequence numbers. The RM Destination MAY decide to delay delivery of, or to not deliver messages that would violate these requirements.

 

 

 

Jacques

 

 

Also Jacques has extra proposed changes: http://www.oasis-open.org/archives/ws-rx/200701/msg00102.html

I am much more comfortable with these defs and - given minor tweaking started by  Stefan - I feel I can explain them to my reviewers.

I also believe we need to modify the Deliver definition as Chris suggested.

See below in line, proposed edits following up on Stefan remarks.

 

Jacques

 

-----Original Message-----

From: Stefan Batres [mailto:stefanba@microsoft.com]

Sent: Thursday, January 25, 2007 9:46 AM

To: Matthew Lovett; ws-rx@lists.oasis-open.org

Cc: Durand, Jacques R.

Subject: RE: [ws-rx] PR035, PR009, PR020: DA defs

 

Matt,

 

Thanks for putting this together. I've inlined a couple of comments.

 

--Stefan

 

 

-----Original Message-----

From: Matthew Lovett [mailto:MLOVETT@uk.ibm.com]

Sent: Thursday, January 25, 2007 5:36 AM

To: ws-rx@lists.oasis-open.org

Cc: Durand, Jacques R.

Subject: Re: [ws-rx] PR035, PR009, PR020: DA defs

 

Hi all,

 

Following on from the discussion about using "deliver" rather than "process to conclusion", here are some definitions that Peter and I have worked on. We believe these definitions help define the end-to-end DA, as they include the RMS behaviour.

 

--

 

wsrmp:DeliveryAssurance

 

When applied to an RM Destination, this element defines a policy assertion that identifies a requirement on RM Sources. Any RM Source that transmits messages to this RM Destination SHOULD conform to the requirement expressed by this assertion. Conversely, when it is applied to an RM Source this assertion identifies a requirement on RM Destinations. Any RM Destination that receives messages from this RM Source SHOULD conform to the requirement expressed by this assertion.

 

wsrmp:AtLeastOnce

 

Each message is to be delivered at least once. The requirement on an RM Source is that it SHOULD retry transmission of every message sent by the Application Source until it receives an acknowledgement from the RM Destination. The requirement on the RM Destination is that it SHOULD retry delivery to the Application Destination of every message that it accepts from the RM Source. There is no requirement for the RM Destination to apply duplicate message filtering.

 

[SB] I think there should be a requirement to indicate an error if the assurance can't be met.

 

<JD> Indeed. I believe the duty to notify error (whatever that means) is part of the DA, not something to do if DA is not met (DA MUST always be met !) We can do :

 

"Each message is to be delivered at least once, or else a "delivery error" MUST be made available to either Application Source or Application Destination. The requirement on an RM Source is that it SHOULD retry transmission of every message sent by the Application Source until it receives an acknowledgement from the RM Destination. The requirement on the RM Destination is that it SHOULD retry delivery to the Application Destination of every message that it accepts from the RM Source, in case of unsuccessful delivery. There is no requirement for the RM Destination to apply duplicate message filtering."

 

 

wsrmp:AtMostOnce

 

Each message is to be delivered at most once. The RM Source MAY retry transmission of unacknowledged messages, but is NOT REQUIRED to do so. The requirement on the RM Destination is that it MUST filter out duplicate messages, i.e. that it MUST NOT redeliver any message.

 

[SB] I find "that is MUST NOT redeliver any message" confusing. The requirement is to filter out duplicates that arrive on the wire. But we can't forbid redelivery of a message that arrived only once or for which duplicates have been eliminated.

e.g. RMD delivers message to AD in the context of a local atomic transaction that gets rolled back, this text seems to say that the message should not be redelivered.

 

<JD> Right - but the roll-back/retry  case can be taken care of by a better def of  "Deliver" (see previous mail). So I think Stefan means:

 

"Each message is to be delivered at most once. The RM Source MAY retry transmission of unacknowledged messages, but is NOT REQUIRED to do so. The requirement on the RM Destination is that it MUST filter out duplicate messages, i.e. that it MUST NOT deliver a duplicate of a message that has already been delivered."

 

(NOTE that this DA does NOT allow an RMD to let a duplicate slip out and get by with raising an error...)

 

wsrmp:ExactlyOnce

 

Each message is to be delivered exactly once. The requirement on an RM Source is that it SHOULD retry transmission of every message sent by the Application Source until it receives an acknowledgement from the RM Destination. The requirement on the RM Destination is that it MUST filter out duplicate messages, i.e. that it MUST NOT redeliver any message.

 

[SB] Same comments apply.

--

 

<JD> merging the hard part of each updated DA above:

 

"Each message is to be delivered at least once, or else a "delivery error" MUST be made available to either Application Source or Application Destination. A message also MUST NOT be delivered more than once. The requirement on an RM Source is that it SHOULD retry transmission of every message sent by the Application Source until it receives an acknowledgement from the RM Destination. The requirement on the RM Destination is that it SHOULD retry delivery to the Application Destination of every message that it accepts from the RM Source in case of unsuccessful delivery, and that it MUST NOT deliver a duplicate of a message that has already been delivered."

 

 

 

 

Some additional comments:

 

Doug pointed out that we talk about the RMS and RMD here, but that the wsrmp spec doesn't quite call out where the RMS and RMD are. For example, if a WSDL output message is decorated with the RM assertion + a DA, we would expect the server-side RMS to exist and do it's part, and similarly the client side RMD has a role to play. I think that this is a separate issue, and needs a bit of discussion, but the text for the DAs should be ok however we resolve that.

 

<JD> I suggest that these DA defs be inserted in the core spec: that is where users look first. They can be associated (referred to) with policy assertions in WS RM Policy spec. It is better that RM Policy doc refers to core RM spec, than the reverse.

 

Jacques: I hoped to get this out to you earlier so you could see our thought process, but I'm running out of time before the call. I'm sorry that time got away from me!

 

Thanks

 

Matt

 

Peter N: I am not sure of what Jacques means by made available to application destination.  What do you mean by delivery error to destination?

 

Jacques: Faulure is after receipt

 

Peter N: If it cannot deliver message, how can it delivery failure notification.

 

Jacques: in extreme cases, such as shutdown, it might not be able to deliver failure notification.

 

Peter N: that is going beyond what we should be talking about.  

 

Sanjay: We had agreed that RMS resends until acknowledged.  Is there a change in that invariant.  One of the DAs seems to relax this invariant (MAY decide to retry).

 

Jacques:  This means you might give up after some time doing the retransimission.  It is fairly permissive.

 

Sanjay: Giving up after some time makes sense, however without DAs the RMS MUST keep retrying.  Now we are introducing that with at most once DA is that the giving up might occur sooner.

 

Gil: I am confused about whether the RMD should not ack until delivery?

 

No so

 

Gil: from the application source perspective I gave message to rms, it sent fo RMD, and it gets the ack back.  I do not see context for sending delivery error message back to app source for a message it might have dumped from its resend cache.

 

Anish: this involves sequence failre.

 

Gil: do you have to be prepared to receive faults for messages which have also been acked?

 

Stefan: the error has to be raised somewhere,  It does not need to be always sent to sender.  The receiver might be enough to receive the fault.

 

Doug D: I am concerned about the MUST, when there might not be someone to receive the error.

 

Matt: the system log could receive the error.

 

Paul F: I think we need to reword this, “a delivery error must be raised”, either by rms or rmd.” We do not need to state where it goes.  Putting this text in the main spec is problematic.  The text about stopping retransmission earlier belongs only in the policy spec.

 

Jacques:  How rms and rmd are made aware of da is outside scope of definition.  Agree we can just state that RM layer raises a fault in this case.  It must be available to the application in some way.

 

Anish: I agree with need for error being raised.  From model perspective, assure DA is met or at least one app is made aware of error.  If we do not say that, the definition of DA is incomplete..

 

Peter: fault could be raised at either or both ends.

 

Peter Niblett: How about "Each message is to be delivered at least once, or else an error must be logged by RM Source and/or RM Destination" ?

 

Jacques: that is ok with me.  SHOULD only applies if you cannot deliver for whatever reason.

 

Paul F: I do not think we can incorporate these changes without some further wordsmithing.

 

Action: Peter N will incorporate consensus from 1/25 meeting into next proposal for PR035.

 

 

 

8.2      b> PR009 "Duplicate Elimination" and "Message Ordering"

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i009

 

skip

8.3      c> PR020 Message ordering and duplication

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i020

 

Skip

8.4      d> PR037 Policy Assertions Must be Independent

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i038

 

Ashok posted: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00057.html

Based on our discussions last week in which we decided that it would be desirable to remove the dependence of the RM policy assertions on one another, here is a proposal that attempts to accomplish this.

 

The RM assertion comes in 3 different flavors:

 

1. <wsrmp:RMAssertion [wsp:Optional="true"]? ... />

 

2. <wsrmp:RMAssertion [wsp:Optional="true"]? ... >

      <wsp:Policy>

                <wsrmp:SequenceSTR />

      </wsp:Policy>

   </wsrmp:RMAssertion>

 

3. <wsp:Policy>

  <wsp:ExactlyOne>

    <wsp:All>

      <wsrm:RMAssertion [wsp:Optional="true"]? ...>

       <wsp:Policy>

        <wsrmp:SequenceTransportSecurity  />

       <wsp:Policy>

      </wsrm:RMAssertion>

      <sp:TransportBinding ...>

        ...

      </sp:TransportBinding>

    </wsp:All>

  </wsp:ExactlyOne>

</wsp:Policy>

 

The third form says that an endpoint may have RM as an option but always requires HTTPS to be used. All the SequenceTransportSecurity assertion indicates is that RM's rules for protecting the sequence over TLS are followed.

 

If we agree on these 3 assertions, the text in sections 2.5.1 and 2.5.2 would need to be changed to reflect assertion 2 and 3 above.  See attached Word Document.

 

 

 

 

All the best, Ashok

 

Marc G: We need to ensure that in section 2.2 we add the nested assertions into the main exemplar.  Also add wsp:policy element as required element within rm assertion to support nested policy expressions.

 

Paul F: can the editors take care of this.

 

Doug D: Is this required even if not using the inner assertion?

 

Marc G: yes it is a standard policy thing

 

Marc G: I move to accept Ashok proposal to close PR 037, seconded by Colleen.

 

No objection PR 037 closed with Ashok proposal.

 

 

8.5      e> PR038 Need to clarify relationship between the WS-RM specification and MakeConnection specification

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00064.html

 

Gill proposal: http://www.oasis-open.org/archives/ws-rx/200701/pdf00013.pdf

 

/wsrm:CreateSequence/wsrm:Offer/wsrm:Endpoint

An RM Source MUST include this element, of type wsa:EndpointReferenceType (as specified by

WS-Addressing). This element specifies the endpoint reference to which Sequence Lifecycle Messages,

Sequence Traffic Messages, Acknowledgement Requests, and fault messages related to the offered

Sequence are to be sent.

Implementations MUST NOT use an endpoint reference in the Endpoint element that would prevent the

sending of Sequence Lifecycle Message, Sequence Traffic Message, etc. For example, using the WSAddressing

"http://www.w3.org/2005/08/addressing/none" IRI would make it impossible for the RM

Destination to ever send Sequence Lifecycle Messages (e.g. TerminateSequence) to the RM Source

for the Offered Sequence.

 

Replace

Implementations MAY use the WS-MakeConnection anonymous URI template

and doing so implies that messages will be retrieved using a mechanism such as the MakeConnection

message.

 

with

The Offer of an Endpoint containing the "http://www.w3.org/2005/08/addressing/anonymous" IRI as its

address is problematic due to the inability of a source to connect to this address and retry

unacknowledged messages (as described in Section 2.3). In the absence of an extension that addresses

this issue, an RM Destination MUST NOT accept (via the

/wsrm:CreateSequenceResponse/wsrm:Accept element described below) an Offer that contains

the "http://www.w3.org/2005/08/addressing/anonymous" IRI as its address.

 

Discussion ensued on methods to attain agreements.

 

Marc G: can always refuse a create sequence or a make connection operation request.   Not every scenario can be defined within the scope of the specification.  The ws addressing has produced metadata to allow expression of anonymous or non anonymous.

 

Gil: Base spec has a hole in it in my opinion.  We are asking for interop problems.

 

Anish: Marc, re WS-addressing changes, that functionality exists now as policy rather than wsdl assertion.  Also I think this is general goodness.  Perhaps with tweaked wording it can say “if you want to support this kind of thing the spec does not say how to do it (you can use make connection or your own mechanism).  That would make it an extension.  Nobody is stopping you from doing what you want to.

 

Jacques: I am concerned with this wording.  It disallows some possible usages.

 

Tom: WS addressing new policy assertion “anonymous” means that the endpoint is willing to accept reply to with wsa: anonymous URI.  No implication of any more general “anonymous” mechanism (such as wsrm:anonymous).  We would need our own analogous policy assertion re wsrm:Anonymous.

 

Marc G: I agree with Tom.

 

Paul F: I have sympathy for Gil’s position.  However I would suggest change “extension” to “mechanism”.

 

Discussion on rewording.

 

Ran out of time.

 

Action: Gill will provide a new proposal for Pr038 by Monday.

 

Anish: this regards our third invariant.

9         Any other business

 

Meeting ended at 5:30 PM eastern time.

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]