1. Peter Niblett William Vambenepe WS-Notification Face-to-Face 18-20 May 2005

2. 2 Agenda - 18 th May (times in PDT) 1:00 Roll Call Scribes (4 half days) Decision on group dinner Approval of minutes from May 9 th Time and Location for next F2F Proposal 12 Sep (or 19 Sep) @ Fujitsu UK 1:30 Action items review 1:45 Possible new issues Qualified elementFormDefault on inline schemas? 2:00Review status and plans for committee drafts 2:30 Editors for WS-Topics and the primer 3:30 WS-BaseNotification issues 2.6, 2.25, 2.36, 2.40, 2.42, 2.44 5:30 Adjourn

3. 3 Agenda - 19 th May (times in PDT) 08:30WS-Topics issue 4.2 09:30 WS-BrokeredNotification issues 12:00 Lunch 12:45 Pull Notification issue 1.4 3:00 Policy Specify policy Work through a specific example - useRaw 5:00 Decision on what we do on Friday 5:30 Adjourn

4. 4 Agenda - 20 th May (times in PDT) 09:00Revised Process document 09:15 Comeback on Issue 4.2 10:00Base issue 2.51 Broker issue 3.4 11:30 Status summary 12:00 End of Meeting - Lunch

5. 5 Action Items  AI 56 - Igor: Fix typos in WS-Topics as described in [3]  AI 74 - BaseN editors to correct problems in implementation of issue 2.34  AI 76 - BaseN editors to update spec to tighten semantics of send/deliver (issue 2.39)  AI 79 - Lily to propose new issue and solution outside BaseN to replace 2.26  AI 81 - Chairs to recruit editors for the primer  AI 82 - Spec editors to incorporate content from the white paper as described in [6]  AI 85 - WS-Topics editors to respond to questions raised in Kato-san's email [7] regarding use of terms TopicPath, TopicExpression, TopicPathExpression, and the names of the related Faults.  AI 90 - Lily to verify the approach proposed for WSN3.8. See [4]  AI 91 – Matt Roberts to verify whether [9]#5 is an issue  AI 92 - BaseN editors: address [9]#1-4  AI 93 – WS-Topics editors: Edits/improvements to WS-Topics raised by Ian Springer.  AI 94 – Sanjay to mark WSN 2.23 as Approach Agreed, see http://www.oasis- open.org/apps/org/workgroup/wsn/download.php/11939/issue%202.23.proposal.2.dochttp://www.oasis- open.org/apps/org/workgroup/wsn/download.php/11939/issue%202.23.proposal.2.doc  AI 95 – Sanjay to mark WSN 2.36 as Approach Agreed

6. 6 Reference [9]  Brokered Notification’s Subscribe Operation is different from BaseNotification’s. It has some extra Topic related Faults. Shouldn’t they be consistent?  Many of the operations in the NotificationBroker portType refer to messages using the wsnt prefix when they should be using the wsntw prefix. Similarly references to messages using the wsrl prefix that need to be changed since wsrl is the prefix for the WS-ResourceLifetime schema namespace not the wsdl one.  NotificationBroker’s ResourceProperties should include TopicExpression not Topics (issue 2.38 applied to BrokeredNotification)  The namespace for ws-addressing needs to be consistent across WSBrokeredNotification and WSBaseNotification  The BrokeredNotification wsdl defines a ResourceUnkownFaultType and ResourceUnkownFault. These duplicate what is defined in the WS- Resource xsd. Some places in the WSDL refer to the type defined BrokeredNotification version but the BrokeredNotification also refers to messages in WS-Resource which can in turn refer to the WS-Resource version of the type. WS-Notification should use the WS-Resource version to avoid problems.

7. 7 OASIS TC process  Committee draft an interim document approved by a TC –full majority vote of the TC required no notification to OASIS required we used to call these stable working drafts  Public Review Draft a Committee Draft that has been approved by the TC to go to public review –full majority vote of the TC required TC Administrator announces on the OASIS members email list TC Administrator issues a Call For IPR Disclosure. Public comments addressed to public wsrf-comment list If changes are required the specification must be withdrawn from review then resubmitted. –The TC may conduct any number of review cycles (i.e. approval to send a Committee Draft to Public Review, collecting comments, making edits to the specification, etc.). 1 st public review of a specification must take place for a minimum of 60 days; any subsequent reviews must be held for a minimum of 15 days.  Committee specification a Public Review Draft that has completed public review and achieved final approval by a Technical Committee The TC Administrator conducts a ballot to approve the Committee Specification.  OASIS standard a Committee Specification that has been submitted by a Technical Committee and reviewed and approved by OASIS membership

8. 8 Planning  WS-BaseNotificationPublic Review July 1st Resolve open issues –1.4 Pull-type notification –5 others –New issue on SOAP rendering of raw messages Execute on Approach Agreed issues Merge in the Whitepaper material Editorial improvements (as in WS-RF) Issue verification / proof reading Change WS-Addressing version  WS-TopicsPublic Review July 1st One open issue (4.2) Execute on Approach Agreed issues Several typographical issues (AI56, AI 85, AI 93)  WS-BrokeredNotification Committee draft target was May 2005  Policy specification Committee draft target was July 2005 Use cases and selection Getting started Embodiment dependency (not in July 2005 version)  Primer/Best Practices documentAugust 2005  Interop?

9. 9 BaseNotification issues Open 2.51 - Provide choice for binding wsn headers to notify body, soap header or to neglect it (raw message)

10. 10 BaseNotification issues  Approach agreed – implemented in draft 01f 1.5 Term “Event” is not clearly defined 2.1 Topics are not optional in WS-BaseNotification 2.32 Dialect of TopicExpression in Subscribe MUST be specified 2.39 Tighten up semantics of send/deliver 2.43 Message generation and accumulation styles 2.45 Typing of Notification payload – xs:any vs xs:anyType 2.46 Should UseNotify be a policy utterance?

11. 11 BaseNotification issues  Approach agreed 1.4 Support for Pull-type notification 2.6 Third party subscriber can be a security concern 2.23 Is subscription a WS-Resource? 2.25 Indirection via WSRF-RP and WSRL 2.33 Message ordering/interleaving 2.34 Additional Fault definitions 2.36 Specify baseline Policy behaviour 2.41 Use of wsrf-rp:Dialect 2.42 Security section to include more specific advice 2.47 Open content on messages 2.48 - Define action URI for fault messages and update the spec text to use wsa:Action (instead of SOAPAction) 2.49 - Define faults exhaustively (no silent faults) 2.50 - Update non-normative examples 2.52 - TopicExpressionDialects to be singular (line 334 in version 1f) 2.53 - Use TopicExpression instead of TopicPathExpression 2.54 - Use WS-Resource defined ResourceUnknownFaultType

12. 12 BaseNotification issues  Resolved 1.7 Indirect Notification pattern 2.3: Duration for the initial termination time is not allowed 2.7 Updating resource properties 2.11 Consumer can not identify the subscription causing notifications 2.13 Bindings for sending messages to Consumer 2.14 Is EPR the right construct? 2.15 Reliance on WS-Addressing 2.17 Common set of Faults related to TopicExpressions 2.18 WS-BaseNotification should allow any garbage collection mechanism 2.19 Soften the wording for the Subscribe operation 2.20 QOS regarding change of subscription properties 2.21 NotificationProducer resource property declarations 2.22 Pause/Resume message types 2.24 Use of term “implied resource pattern” 2.29 SubscribeResponse to specify effective termination time 2.35 XML schema separated from the WSDL file 2.37 TopicExpression RP to have attribute extensibility 2.38 Topics RP to be renamed TopicExpression

13. 13 Issue 2.36 – Baseline policy Approach 1.Subscription Durability - change words in spec to the effect that, in absence of specified relevant policies, producer MAY drop messages. 2.Message Durability – covered by send/deliver – 2.39 3.Pull Notification - defer to later discussions. 4.Continuity - improve words in spec to the effect that baseline provides no guarantee of continuity, i.e. if you use Set to update subscription properties. 5.Flow Control – out of scope. Default behaviour is for producer to send everything that it can 6.Reliability – discussion similar to Durability 2; no change required in spec.

14. 14 WS-Topics Open –4.2: source document for FullTopicPathExpressions (the topic set is different from a topic space and not fully specified) Approach Agreed –4.3: XPath 1.0 as an additional dialect for FullTopicPathExpression –4.4: domain-specific extension to topic spaces (how can you extend if you don't have access to the domain name used by the initial topic space). –4.9: Specifying the Ad-hoc topic space is cumbersome –4.16: When are wildcards and aliases resolved? –4.20: SimpleTopicExpression type as xsd:token –4.21: TopicSpace location attribute –4.22: Finality of TopicSpace –4.23: Resolving XML Names in the TopicExpression content –4.24: Namespace prefix change may result into unbound QNames

15. 15 WS-Brokered Notification  Open Issues 3.4: Demand-Based Publisher is a light-weight NotificationProducer  Approach Agreed 3.1: Dependency of WS-BrokeredNotification on WS-Topics 3.5: Need additional Fault definitions 3.6 Need XSD separated from WSDL 3.7 Specify baseline policy behaviour 3.8 SubscriptionManager interface in BrokeredNotification 3.9: Separate endpoints for Producer, Consumer, etc. 3.10 Open content on Publisher Registration 3.11 - Define action URI for fault messages and update the spec text to use wsa:Action (instead of SOAPAction) 3.12 - Define faults exhaustively (no silent faults) 3.13 - Update non-normative examples of message formats 3.14 - Use TopicExpression instead of TopicPathExpression 3.15 - Use WS-Resource defined ResourceUnknownFaultType 3.16 - BrokeredN WSDL out of sync with BaseN WSDL regarding Subscribe faults etc 3.17 - Namespace prefix to be consistent with BaseN (wsntw instead of wsnt) 3.18 - Resource property Topics should be TopicExpression 3.19 - Use WS-Resource defined ResourceUnknownFaultType 3.20 - Bespoke method for publisher registration resource destruction