[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes Sept. 13, 2005 PM
Folks, Here are some minutes: Attendees: Peter N, Steve G, Bryan M, Martin C, Dave S, Dave H, Kirk W. Review of Morning: - To be Verified: 4.2 - Verified OK: 4.3, 4.5, 4.9, 4.16, 4.20, 4.22, 4.25, 4.26, 4. 27, AI-85 - Further work required: 4.4, 4.21, 4.23, 4.24, 4.28 * Possible new issue on all specs "Notational Conventions". It appears that by referencing [XML Infoset] we multiply define the use of []s. The recommendation is to delete this paragraph. SGG: One is with reference to usage in text and the other is only in pesudo-schema. Dave: [action] usage may be a third usage from WS-Addressing Core. Peter: There are 4 usages possible. Infoset, references, pseudo-schema, WS-addressing (using Infoset indirectly). Dave S: Move to resolve with no change. - Second: Steve G. Agreed! Peter N: Italics should be removed, but left to editors. * Possible new issue: What is the {} around {any} for in pseudo schema? There was some discussion that the @ in attributes was part of the spelling of the attribute and therefore the {} are part of the spelling of "any". Steve G. Moved to do nothing, Martin C. Seconded. Agreed! * Missed editor action: Issue 4.2 logged against Topics, but a piece went missing in Base Notification. Need minOccurs=0/maxOccurs=1 on the Topic Set resource property in BaseN. Action: BaseN Editors add Topic Set RP to BaseN, i.e. Item 4 of Issue 4.2. * Issue 3.28, With reference to the need for a "all operations in" portType for Brokers. Approach agreed was to have a single PT (NB) with NC, NP, PR as well as all three independently. Now we have the Pull Point Creator. Do we have it separately and/or combined into NB? Dave H: The concept of PP is just enough different that we should only leave it separately. Dave H: Moved to leave PP as a separate PT only and remove the special fault. Seconded Dave S. Agreed! * Issue 2.58: Review of approach agreed. [Short interval while Peter fights with Kavi.] Susan M Joins the meeting in person. Is this what we agreed yesterday? Yes. * Issue 2.59: See Dvae H mail: 13 September 2005 4:26:58 BST This says that he did: Deleted any reference I saw to "raw" format. I think I got them all. Added a paragraph at the bottom of the "CreatePullPoint" operation, which basically makes very explicit that the PullPoint accumulates precisely what it chooses to accumulate, no more, no less: Proposed text: It is expected that some NotificationProducer implementations may choose to optimize the accumulation of messages in a pull point by bypassing physical transport mechanisms and placing Notification messages in the pull point directly. In such cases, PullPoints created by the CreatePullPoint operation may or may not accumulate Notify messages sent to the given address, instead serving only as an indication for the NotificationProducer to accumulate Notifications for retrieval by the GetMessages operation at that address. Some tidy up discussion followed. Does specifying a specific case rule out other cases? - Remove "In such cases," This seems OK A fault issue, which is not an problem for s one way MEP. This is consistent with the current interpretation in WS-Addressing, faultTo. - No action. Ditto with the Notify fault issue. - No action. Should we mention that NPs may refuse to allow subscriptions for pull points they didn't create? Also no problem. Just examined as just a check. - No action. Do we need something like "In the absence of policy assertions or other indications, Subscribers SHOULD NOT assume that a pull point is valid for subscriptions by NPs other than the one that created it." This is probably a good idea, but it seem not possible to say normatively. - No actions. Do we need something like "Pull point factories SHOULD indicate through policy assertions or other indications whether their pull points support the Notify operation."? Lily has joined on the phone. There was a discussion about the architecture of Pull Points covering some of the same ground from the last F2F. Followed by an on screen editing session. The final result was the following text. A PullPoint created by the CreatePullPoint operation MAY choose to ignore Notifications received through the NotificationConsumer interface. A Pull Point MAY accumulate Notifications through other, implementation-defined mechanisms. Pull point factories SHOULD indicate through policy assertions whether pull points they create will ignore Notifications received through the NotificationConsumer interface. Action: Editor to use the above text. Action: Add the Notify operation to the Pull Point PT. -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]