Minutes Sept. 13, 2005 PM

[David Snelling <David.Snelling@UK.Fujitsu.com>]

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)