[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: draft minutes 18 may
may need a spell check.
WS-N F2F Minutes 18th May 2005
Roll: on kavi
Meeting is quorate
Scribe: Martin Chapman, Oracle
Minutes 9th May:
http://www.oasis-open.org/apps/org/workgroup/wsn/download.php/12536/WSN%20Minutes%20-%209%20May%202005.htm
approved
Next F2F: proposal for noon 12 sep 2005 thru noon 14 Sep 2005 at Fujitsu, Hayes, UK
Agreed
Action: chairs to create calender event for sep 05 f2f.
Agenda:
http://www.oasis-open.org/apps/org/workgroup/wsn/download.php/12765/ws-notification%20f2f%20May.ppt
invert pull and brokered notification discusion on thursday
Action Items:
-------------------
AI 56 - Igor: Fix typos in WS-Topics as described in [3]
pending
AI 74 - BaseN editors to correct problems in implementation of issue 2.34
pending
AI 76 - BaseN editors to update spec to tighten semantics of send/deliver (issue 2.39)
some work done, but needs to be verified. ongoing
AI 79 - Lily to propose new issue and solution outside BaseN to replace 2.26
pending
AI 81 - Chairs to recruit editors for the primer
on aganda
AI 82 - Spec editors to incorporate content from the white paper as described in [6]
pending
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.
TC to look at this email and clarify this action.
AI 90 - Lily to verify the approach proposed for WSN3.8. See [4]
verified at the meeting. Closed
AI 91 – Matt Roberts to verify whether [9]#5 is an issue
Done
AI 92 - BaseN editors: address [9]#1-4
this is for brokered notification so discuss under there.
Close
AI 93 – WS-Topics editors: Edits/improvements to WS-Topics raised by Ian Springer.
pending
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.doc
pending
AI 95 – Sanjay to mark WSN 2.36 as Approach Agreed
pending
New Issues
----------------
Qualified elementFormDefault on inline schemas?
http://www.oasis-open.org/apps/org/workgroup/wsn/email/archives/200505/msg00010.html
issue 3.6 on brokered notification should resolve this so no need for new issue.
Steve Graham wants issue/action open to make sure specs are updated with correct boilerplates/housekeeping:
1) change status section to update process for sending in comments
Action: ian to send ws-rf text on status section
Action: editors to incorporate rf status text into documents
2) need to execute on setting the precedent on document vs schema
looking at previous minutes - come back to
3) WS-RF adotped terse proposal for action/namespace uri, ws-n is not as eloquent. Result is a much cleaner schema. For notification would look like
http://www.oasis-open.org/.../wsn/
b for base
br for brokered
t for topics
plus a number for the version - the version only has to change when the namespace has a backwards incompatible change. see ws-rf for full pattern
This affects our process document.
Action: editors to change docs to adopt this namespace pattern
Action: peter to update process document with new namespace pattern
4) clarify in base and brokered the action uri wrt fault messages along the lines of ws-rf plus update the message exchanges to use ws-a action (see ws-rf).
Create issue each for base and brokered on the above with approach agreed
Sanjay asks about soap action on its own. The assumption is that the same rules should be followed but its not clear. RF decided it did not need to mention soap action.
Action: Sanjay to check on soap action in absence of ws-a action.
5) clarify the nature of faults on message exchanges. there is an opportinity for a silent fault and ws-rf agreed to not allow this i.e. that a reponse message or a fault message must be sent, plus the list of fault messages is not exhausted e.g. there could be other system faults.
create two new issues, one for base and one for brokered, to incoporate the above clarification on faults - mark as approach agreed.
6) which version of soap for the examples. The version is irrelevant, but current examples use 1.2 and are not basic profile compliant. Steve suggests getting rid of headers and making example neutral to soap.
Proposal to change namespace prefix to s and in table to say that s maps to either soap 1.1. and 1.2
and to change examples to use s prefix.
open issue one for base and brokered with approach agreed to change namespace prefix and example.
7) simplify the examples by removing all soap headers other than action and to only use prefixes.
open issue for base and brokered with approach agreed to remove all headers in the examples that are not relevant. also change ref props to ref params in examples to make ws-a migration easier.
8) remove references to specs that are not in an "open" body.
open issues with apprach agreed on base, brokered and topics to remove refreneces to specs that are not in an open body. all soap references are non-normative.
note action 82 might bring back some references.
9) update list of acknowledgements
Action item for chairs to send list of acknowledgements and ask if people want to be added/removed.
Potential New issue from martin to give more flexibility to where notification parts can be placed. e.g. allow some notification data in soap headers.
Agreed to raise new issue.
Peter: sec 4.1 of base, line 335 changedialects to dialect (singular) and change min occurs on topicexpressiondialet to zero. Raise new issue with approach agreed and review implementation of issue 2.1
Action on base editors to update dialect while implementing issue 2.1
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.
http://www.oasis-open.org/apps/org/workgroup/wsn/email/archives/200504/msg00018.html
Open issue on base and brokered to consitently use TopicExpression instead of TopicPathExpression (and related uses such as dialect etc)
AI 92 - BaseN editors: address [9]#1-4:
1.) Brokered Notification’s Subscribe Operation is different from BaseNotification’s. It has some extra Topic related Faults. Shouldn’t they be consistent?
they should be identical. This is a wsdl inconsitency issue.
Open new issue on brokered wsdl to ensure subscribe operation has same signature as subscribe in base.
2) 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.
Open issue on the above.
3) NotificationBroker’s ResourceProperties should include TopicExpression not Topics (issue 2.38 applied to BrokeredNotification)
open issue on the above for brokered.
4) 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.
Open issue on base and brokered with approach agreed to use faults defined in ws-resource.
New Process and planning
----------------------------------
New process has changed terminology wrt drafts and becoming a standard:
http://www.oasis-open.org/committees/process.php
WS base notification - aim for public review draft 1st July
ws topics - aim for public review draft 1st July
ws brokered notification - cd may
notification policy - cd july 05
issue wsn1.8 is listed as open but was probably agreed to close as being a next version issue.
Steve motions for this to be the case, so wsn1.8 is closed and moved to futures category.
June 6th deadline for new drafts containing all approach agreed at that point in time.
Members to inform chairs if they wish to review a particular issue that has been incorporated.
Chairs will seek reviewers for all other List to be produced by 6th.
By 13th reviewers to check/confirm issues have been edited correctly.
aim for CD/PRD vote on mon 27th (may need special meeting for this)
meeting on 6th will be one hour as being shared with ws-rf
was also agreed to share the meeting on 13th
Action: chairs to add celendar event for meeting on 13th june after ws-rf
Editors for topics and primer
----------------------------------------
One additional person is required on ws-topics. any volunteers?
Sid Askary volunteers and is accepted by the group.
There is no editor for the primer, but this is not as important in the current timeframe.
WS-Basenotification issues
---------------------------------------
WSN2.36: Specify baseline policy behavior:
from minutes 9th, need to verify.
1. subscription durability: wording needed
2. message durability: agreed
3. pull - defered
4. continuity - wording needed
5. flow control - no change required
6. reliability - no change required
editors claim to have already executed on this issue so needs to be verified.
can be marked as approach agreed.
WSN2.6: Third party subscriber can be a security concern:
Text needed for the security considerations section to address the new risks
introduced by third party subscriptions.
There will be no normative mechanisms/strategies for this,
just examples of how these risks may be averted.
marked as approach agreed.
WSN2.25: Indirection via WSRP and WSRL
Add new issue on broker to remove ws-rdependancy, make it optional and add a bespoke destroy method.
What remains are properties on notification producer.
Currently notification producer must be a ws-resource.
The lifetime aspect of issue has been addressed.
Resolution of 2.23 also helps this.
Steve motions to change a notification producer to be an optional ws-resource and if it is, it must support the appropriate properties.
2nd by Martin.
No objections so approach agreed.
WSN2.40: Use of wsa:RelatesTo in WSN
Proposal from william:
http://www.oasis-open.org/apps/org/workgroup/wsn/email/archives/200502/msg00051.html
seems to be a layer above base.
Steve motions to close no action. Agreed.
WSN2.42: Security section to include more specific advice.
this is a duplicate of 2.6
WSN2.44: Filters based on headers
current text talks about notification message payload which implies a body.
could add a new filter that can evaluate over the whole (xml) message/envelope.
dave motions to close no action
steve 2nds
no objections. 2 abstains
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]