Prelim Minutes WSRM TC Conference Call – October 14, 2003

The meeting of the WSRM TC took place by teleconference

Tuesday October, 2003, from 5:30 to 7:30 PM Eastern Daylight Time

(UTC - 4)

The call in details were as follows :

Dial-in numbers:

----------------

Toll Free - : 1-800-605-5167

International - : 1-719-457-0339

Passcode: 732072

0 Draft Agenda:

Draft Agenda to WSRM TC Conference Call – Sept 30, 2003

1 Roll Call (late arrival no longer counts by OASIS rules)

2 Minutes Discussion

2.1 Appointment of Minute Taker

2.2 Approval of previous meeting minutes

3 Discussion of Interop Demo at XML show, and status of Subgroup

4 Discussion of Issues

5 Discussion of F2F meeting document distribution policy and agenda(Oct 28 - 30) in CA

1 Roll Call

First Name	Last Name	Email	Role	Company
Joseph	Chiusano	chiusano_joseph@bah.com	Member	Booz Allen Hamilton
Jeff	Turpin	jturpin@cyclonecommerce.com	Member	Cyclone Commerce
Pramila	Mullan	pramila.mullan@rd.francetelecom.com	Member	France Telecom
J	Durand	jdurand@fsw.fujitsu.com	Member	Fujitsu
Kazunori	Iwasa	kiwasa@jp.fujitsu.com	Secretary	Fujitsu
Tom	Rutt	tom@coastin.com	TC Chair	Fujitsu
Robert	Freund	bob.freund@hitachisoftware.com	Member	Hitachi
Eisaku	Nishiyama	nishiy_e@itg.hitachi.co.jp	Member	Hitachi
Nobuyuki	Yamamoto	no_yama@bisd.hitachi.co.jp	Member	Hitachi
Ben	Bloch	ben_b54@hotmail.com	Member	Individual
John	Fuller	jfuller@wernervas.com	Observer	Individual
Dock	Allen	Dock@mitre.org	Member	Mitre Corporation
Junichi	Tatemura	tatemura@ccrl.sj.nec.com	Member	NEC Corporation
Sumit	Gupta			Oracle
jeff	mischkinsky	jeff.mischkinsky@oracle.com	Member	Oracle
marc	goodner	marc.andrue.goodner@sap.com	Secretary	SAP
Doug	Bunting	doug.bunting@Sun.com	Secretary	Sun Microsystems
Tony	Graham	Tony.Graham@Sun.com	ProspMem	Sun Microsystems
Chi-Yuen	Ng	cyng@csis.hku.hk	Member	University of Hong Kong
Scott	Werden	scottw@wrq.com	Secretary	WRQ, Inc.

Meeting is quorate.

2 Minutes Discussion

2.1 Appointment of Minute Taker

Tom Rutt will take minutes.

Mark Goodner agreed to take issue resolutions.

2.2 Approval of previous meeting minutes

Sept 30, 2003: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/3677/wsrm-reqm-issues-2003-09-30.html

Bob F moved to accept the minutes.  Jeff Turpin seconded.

No opposition minutes approved.

3 Discussion of Interop subgroup Activities

Bob F posted the minutes of their first meeting. They made quite a bit of progress, and Sun has agreed to join. A revised abstract has been sent in.

The updated for the admin things for the conference have been completed. They are in the process of electing an application to more clearly demonstrate the advantage of the protocol.

Transaction or banking app is being looked at. Jacques is chasing real payloads from the demo, from Jamie Clark.

Demo in San Jose in November, and Morristown NJ in Dec. Demo at XML 2003 is Dec 10, but this is not yet confirmed.

They do not have enough resources to do full demo at the f2f meeting in October. However, there could be a small demo with a subset of players.

Jacques stated that Fujitsu cannot commit to a demo at the F2F. However they will possibly be able to do a demo.

Pramilla stated we go forward with our meeting. If there can be an impromptu demo, it can take place on Friday afternoon. If not, the France Telecom Exec will visit the group in its normal operation.

Bob F suggested that at least slideware can be used to explain the work of the group.

Tom Rutt will put on the agenda for Friday PM a report of the activities of the Demo subgroup.

The troublemaker has been made available to participants.

Bob F is working on a separate mail list for the group. However major items will be placed on the list of the group.

Doug asked when the subgroup list and web page will happen.

Bob F stated he will work on this with Oasis Staff.

4 Discussion of Issues:

Latest issues list at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/3529/wsrm-reqm-issues.html

This was after the meeting.

4.1 Action items from previous meeting:

Sunil agreed to get a proposal for the semantics of RemoveAfter attribute, Jacques will participate. Still open. Rel 97

Iwasa had a proposal to change the syntax of the ack response, for multiple acks. Payrits agreed to participate in the proposal. They should send a proposal to the group. Still Open, not yet discussed Rel 75

Email Discussion of Reliable Request/Response Wsdl operation support – Still Open, their proposal is complete, no discussion has occurred. Rel 65

4.2 Rel 94 – poll response:

Sunil sent the following mail:

Tom has requested me to re-list the requirements for Poll RM Reply pattern [1] and also list the concerns I’ve mentioned in the con. call. I already listed few issues briefly before [2].

Use Cases:

1. For a client behind a firewall using one-way MEPs. It can’t use the Response RM Reply pattern as the application is using one-way MEPs. It also can’t use the Callback RM Reply pattern as it is behind the firewall. So essentially there is no easy way out. I believe this is very prominent use case and should have an efficient solution. Poll RM Reply pattern solution would be solving this problem efficiently.

2. Retry is not always an alternate if the payload is huge. Retry-on-demand is an alternative. And one way to achieve is to poll the message before retrying.

3. Thin Client: Currently for applications using one-way MEPs and Callback patterns, they need to have a listener on the client side. This may be acceptable to fat/thick clients. This requirement may be too heavy weight for (very) thin clients especially if not all messages have to be reliable (say only 5 out 100 msgs. sent are critical for an application). So instead of having a listener, the Sender can only poll for acks. for those critical messages).

While the TC has unanimously accepted the requirement, and the syntax was agreed in-principle, the main concern seems to be more conceptual. Whether this request should be sent in the SOAP Body or SOAP Header? I foresee many issues with sending the request in SOAP Body.

Issues sending in SOAP Body:

If this Poll request has to be sent in the SOAP Body, then it has to be defined in the WSDL unlike in the Header case. In the latter case, it is not a must rather could. If not, interoperability is not guaranteed, schema/payload validation won’t happen etc.

So, if it has to be defined in WSDL, where?

Same as application’s WSDL: WSDL 2.0 (was WSDL 1.2) does have support for Interface (was PortType) inheritance. Provided with this, we could have required that all application interfaces that require RM Poll could inherit the RM Poll Pattern PortType. But WSDL 2.0 is not expected to be in community draft before we are. Even if so, we still has to solve the WSDL 1.1 cases. So for WSDL 1.1, this would require mucking around the Application’s WSDL – which is not acceptable. Mucking around problem will exist whether we are changing the same PortType/Port or whether adding new PortType/Port to the same <wsdl:service> element or adding a new <wsdl:service> to the same WSDL. Mucking around has lot of problems:

1. Versioning.

2. How is the updated WSDL available to the user?

3. It is no longer application’s WSDL, rather a combo version.

4. If QoS module has to update the application’s WSDL, who does when & how?

Different endpoint same URI as application endpoint URI in a different WSDL: Other option is to create another WSDL with one operation (Poll RM Reply Pattern) and endpoint address will be the same as the application endpoint address. However, the concern/issues here are:

1. How does the platform (RMP) get hold of this WSDL?

2. If the platform (RMP) hosts 1000 applications, do we have to create 1000 WSDLs with the same portType/Port with different URIs (basically one each for each application service endpoint)?

3. WS-I BP 1.0 discourages URI overloading though doesn’t prohibit it.

4. If the name of the operation is “poll”, then we will have a restriction that user shouldn’t have any operation with the same name. [This is not an issue if it is a DOC service as it would be namespace qualified. This will be an issue if it is a RPC service].

Different endpoint different URI: The other option is to treat a RMP as a Service and hosted on a different endpoint/WSDL. Issues in this case:

1. How does the client get hold of the WSDL?

2. How is the Service implemented? Rpc/doc, literal/encoded etc.

3. Security/DOS issues

4. If a RMP implementation uses different (persistence) cache for different endpoints (for different applications), how does this centralized RMP endpoint get hold of all these caches?

5. If every QoS is treated as a different Service and has a different endpoint, how can we achieve Secure, Transactional and Reliable stuff on the SAME endpoint?

6. No mechanisms to prohibit other (non RM) Headers on this request to this special port.

Other issues with Body:

1. Looks odd. All other RM operations are expressed in Headers.

2. Generally speaking Body contents are meant for end applications. Headers are the extensibility mechanism for Web Services and are a double edge sword. If required, they can be defined statically in the WSDL or can be added dynamically on wire without being defined in the WSDL.

3. Most of us (at least all the Interop participants used some sort of Handlers) will be using Handlers for the RMP implementation. JAX-RPC Handlers are meant to be triggered based on certain Headers, i.e., a Handler definition has a set of Headers (QNames) that are mapped to it and it is meant to be invoked only when those Headers appear on wire. So if we send this RM operation as a SOAP Body without any Headers, how will the Handler be invoked? We end up peeking into every message if this new implementation requirement is imposed.

4. Piggybacking will be prohibited.

So sending in Body is still possible, but have lot of issues as mentioned above. It should be the last resort. I don’t see any problem using Headers for sending this Poll request except for few conceptual worries, so I don’t see a need for a change. Here are the advantages using the Header:

1. Consistent with other RM operations.

2. Extensible.

3. Easy to define WSDL Bindings if required.

4. There is nothing wrong in sending operations in SOAP Headers.

a. It won’t be re-inventing a new MEP, as MEPs deal with Senders & Receivers and not Body or Header. The current proposal still constitutes the R-R MEP.

b. SOAP spec. doesn’t say that Headers shouldn’t be used for operations. Infact, it’s perfectly valid to use Headers for Platform (non application) operations. Here are some snippets from SOAP Specs.

i. SOAP provides a flexible mechanism for extending a message in a decentralized and modular way without prior knowledge between the communicating parties. Typical examples of extensions that can be implemented as header entries are authentication, transaction management, payment etc.[5]

ii. A SOAP header is an extension mechanism that provides a way to pass information in SOAP messages that is not application payload. Such "control" information includes, for example, passing directives or contextual information related to the processing of the message. [6]

[ps: I also discussed this in length with our rep. on XMLP W3C WG

and he echoed my thoughts that it is nothing wrong in sending in

Headers.]

iii. I don’t think this is anything different from the Callback thing we are doing.

iv. Many specifications already send QoS-like operations in Headers. The only difference is that they are sent with some associated payload, where as in this case, there is no such payload.

5. Batch multiple Poll requests

6. Piggy backing with other requests to the same endpoint.

7. No new implementation restrictions. Consistent with the current approach.

Let me also address Mark’s concerns raised in his mail [3][4]:

1. Security is bit different when compared to Reliability, Transactions, Lifecycle etc. The former has tight dependency with payload, while the latter ones are loosely coupled and generally have a out-of-band contract.

2. XKMS didn’t define WSDL SOAP Bindings and hence they don’t have the problems I mentioned above.

3. XKMS didn’t define any Header operations and ALL of them are in Body. So at least it is consistent in that respect.

Summary:

So in short, there are no technical issues as far as I can see with sending this request in SOAP Header except for conceptual concerns.

References:

[1] - http://www.oasis-open.org/archives/wsrm/200309/msg00034.html

[2] – http://www.oasis-open.org/archives/wsrm/200309/msg00063.html

[3] - http://www.oasis-open.org/archives/wsrm/200310/msg00009.html

[4] - http://www.oasis-open.org/archives/wsrm/200310/msg00008.html

[5] - http://www.w3.org/TR/SOAP/#_Toc478383497

[6] - http://www.w3.org/TR/2003/REC-soap12-part0-20030624/#L1161

Mark G stated that while the use cases are strong, the potential solutions could take several months. He would not want to waste the entire F2F on this issue, because there are a lot of other issues that should be resolve.

Tom Rutt stated we are going for a fist committee draft out of the meeting.

Tom Rutt proposed to limit the time at the meeting, if we cannot get agreement we would postpone to a future revision.

Mark G stated that the application will likely to be aware that the polling is going on. The intermediaries would not do it, only the thin client would do it. The app could be involved in this interaction.

Oracle – I guess it is not seen as a system operation.

Mark G, the thin client app probably would do the polling.

Jeff M agreed that the intermediary would be acting as a client in this case.

Mark stated the intermediary adds to the discussion, and it shows it is most useful for thin clients.

Jeff M asked if the RMP is an exposed service, or is it under the covers.

Mark G stated that if it is under the covers, the polling is not seen by the client. He stated that the client needs access to the polling operation to do the polling.

Jeff M stated that do we make rmp an application level thing, or is it the qos mechanism.

Oracle 0 I want it to be a qos mechanism.

Jeff M what is the target of the service?. Is it the RMP or the ultimate endpoint.

Oracle – all the WS implementation are treated as QOS mechanisms. We allow the end users to add these qos to their end services. It does not matter to them what these protocols are.

Oracle – keep as system level op.

Mark G – the application would participate in this.

Sunil stated that the Header poll allows thin client rmp to add the poll on a new Reliable message delivery.

Mark G is not convinced that this is an important feature.

Doug B stated that this is not enough of a benefit to sway the solution.

The ability to ask more that one question at same time is a good thing.

Marc G: Since the poll message is so tiny, it might not be a major concern whether piggybacking is not allowed.

Another issue is the address of the poll operation needs to be made known to the client.

Tom stated that the easiest way to resolve the issue is to demand that the poll operation is addressed to the same url as the one the reliable message was sent to.

Jeff stated it makes sense to demand that it be sent to the same URL.

Mark G stated that it makes sense to have the poll go to the same url whether or not it is in the body.

Oracle stated that they are using header handlers to ease the implementation of ws reliability.

They do not have to look at the bodies if the protocol is in the headers.

Oracle stated how many endpoints are needed for the polling endpoint, is another issue.

Mark G stated that requiring the same URL would allow turning on and off the poll for that destination.

Focus on a solution by email before the meeting. Limit the discussion, the first discussion at the meeting, and if we cannot agree, put it off to the next release.

Bob F stated we need to get all the proposals down to specifics, to get the flames out of the discussion.

If someone came out with proposal for the body it would help.

4.3 Rel 81 thru 86 on Parameters

Jacques proposed a small group look into this issue before the F2F.

He has a basic initial proposal:

I would propose we create a small task force to generate a group proposal for Rel 81 - 86

(configuration Parameters), as it is an issue with several possible ramifications and assumptions,

that we need to sort out and decide on before shaping a coherent proposal.

(e.g. what is the scope of these parameters?

- all connections sender-receiver an RMP is involved in?

- One individual connection?

- One group?)

Here is a summary of my (revised) initial but partial proposal on these:

Rel 81: Maximum message lifetime/duration

- cancelled (ExpiryTime is now mandatory)

Rel 82: Maximum message group (or message sequence) lifetime

- propose to rename removeAfter attribute, as GroupExpiryTime or ExpiryTime,

like for messages.

- propose to add GroupMaxIdleTime parameter as an option to terminate a group

based on maximum idle time between two messages. But would only apply if

GroupExpiryTime not specified.

Jacques clarified that the remove after time limit ends a group, or the end message for the group. Either of these can end the group. RemoveAfter is an optional attribute currently. Another way to estimate that the group is over is to put a time limit on the elapsed time between two messages in the group. He revised the initial proposal to state that this elapsed idle time is used when remove after is not specified.

Rel 83: Resend interval (related REL 47)

- as proposed in issue list.

Rel 84: Retransmission count (related REL 47)

- as proposed in issue list.

Rel 85: Duplicate search scope (minimum number of past messages to look-up)

- to defer, as maybe more an implementation issue tied to overall available store size.

Rel 86: Unordered messages window size (max number of messages to hold)

- to cancel, see proposal for Rel 57.

implementations will have to detect their persistent store limits.

So I see at least 3 parameters (Rels 82, 83, 84) that represent some

form of RM agreement that govern the behavior of a Sender, of a receiver or both,

and that should not appear in message headers. The editorial treatment of these

could be something like:

"When reliability feature XYZ is required, an RMP MUST represent and persist

the parameters <...> [for each connection][for all conenctions,...]"

These parameters can then be referred to by the spec to describe the behavior of an RMP.

Regards,

Jacques

Jacques stated that issue 57 for window size might not be able to be specified for an rmp to enforce. He stated this in his proposal to resolve issue 57. Ordered sequence missing message on receiver side. He as covered this with Scott, and they have proposed a resolution.

The two parameters, for Rel 82 will affect our protocol. Group Max Idle time could also be in the header. Three parameters are proposed for being in the message.

Jacques stated that other parameters do not need to travel to the receiver.

Marc G stated that if these parameters are part of the RMP, the receiver could use faults to indicate this to the sender.

For example the resend interval parameter is in the rmp layer, but the sender does not need to tell the receiver what it is. If the sender send messages too often, the receiver can only send a fault.

Some parameters are under sender control, and the receiver does not need to know them.

Marc G asked why parameters should not go into the header.

Jacques asked for a small team to resolve these problems.

There was a Question on retransmission count being sent from sender in the header.

Want to have all header values determined by the end of F2F.

Jacques stated we need to determine which parameters appear in the message header soon.

How to retire a group that is taking too long.

Jacques asked who could commit to help review any text he prepares on this topic.

Marc G agreed to review Jacques text. Bob F agreed to review the proposal from Jacques.

Tony Graham volunteered to review the proposals.

They will post the output before the meeting.

Action: Jacques will have a proposal available at meeting.

4.4 Rel 57 Issue

Jacques sent an email on 9/30:

Rel57: proposal:

Title: Ordering and Missing Message Behavior Description:

Split out from issue REL-16

What is the behavior of a WSRM receiver that is ordering messages and one of the messages

is never received, or at least not within the MET (timeout) of a subsequent message even

though ACKing is being used?

For example: it receives msg #0, #1, #3. The MET for message #3 is 5 minutes so the receiver

cannot wait more that 5 minutes for #2 to arrive. What does it do when the 5 minutes expires?

-----------------------------------------------------------------------

Patrick Yee a preference for option (a) below.

26 Aug 2003: Doug mentioned one option for (c) -- silently dropping later messages.

Have we previously discussed an issue that solves this problem?

See REL-86 for additional considerations. Proposal: Options:

(a) Send a fault back to the sender, notify the application, and abort all further ordering

for the group.

(b) Send a fault back, deliver #3 to the app just before it times out, and continuing

ordering all subsequent messages.

------------------ summary of proposal (Jacques) --------------------

So there are two questions to answer here:

Question (Q1): when to decide to give-up "waiting" for a missing message?

Question (Q2): which behavior should then be required: (a), (b) (c)?

Q1: A sequence is hopelessly broken when the minimum of {ExpiryTime of

each received out-of-order message } has expired.

But storage shortage is also a valid cause that needs to be handled in spec,

if only on the fault side.

Q2: drop all out-of-order remaining messages, but send back a fault to Sender

in all cases ((a) above).

-----------------------------------------------------------------------

NOTE: I use the term "mis-ordered" for messages that belongs to a sequence

which is supposed to be ordered but is not (un-ordered sequence now would

mean a sequence not supposed to be ordered in the first place).

NOTE: (a) is not quite clear: are the "mis-ordered" messages still delivered to the

application?

I will assume :

(a1) keeps delivering without ordering anymore,

(a2) drops all mis-ordered remaining messages,

and (c) is like (a2) but without sending fault back.

Question Q1: Proposal: A sequence is hopelessly broken when the minimum of {ExpiryTime of each received mis-ordered message } has expired.

Issue 1:

For practical reasons, the sequence may be given-up earlier than the earliest ExpiryTime:

The receiver RMP might not be able to store a large number of mis-ordered messages

if ExpiryTime is large (as it is usually based on business needs, not RMP capacity).

In addition, as several mis-ordered sequences will compete for storage space, a "new"

mis-ordered sequence may have not much storage left and very quickly reach the store limit.

So there should be some means for an RMP implementation for deciding when to stop storing a mis-ordered sequence, which means "dropping" a mis-ordered sequence before ExpiryTime expires.

Recommendation 1:

We will not fully address this issue here, as this may be seen as an implementation

issue, but an RMP implementation MUST gracefully detect and react to space

shortage for stored messages. (This may require some configuration parameter, e.g. storage

space, total number of messages, etc.)

Once the storage limit has been reached for a sequence,

the Sender app will need be aware that the sequence is dropped. (this

is addressed in Q2 below.)

Question Q2: Proposal: Since ordered delivery is strictly defined as "no message

can be delivered to the application before all previously sent messages have been delivered",

it appears that either (a2) or (c) is appropriate. Beyond these options, the proposal here

is that the Sender application needs be made aware of the failure to deliver

(or failure to make available) the rest of the sequence to the receiver application.

Recommendation 2.1:

Because "exactly once" delivery is also required, the Sender will normally receive Acks,

and will notice that the "missing" message (say M1, the one that breaks the receiver sequence)

has failed. So a broken sequence will normally appear to the Sender RMP as (at least) a single

message delivery failure. This would work with both options (c) and (a2).

Note: several subsequent mis-ordered messages may be acked but not delivered to the

application. The Sender application will however know that all these acked messages

were not delivered to its counterpart, because they belong to same GroupId as M1.

So M1 delivery failure to the Sender app will also serve as a "sequence delivery failure".

Issue 2:

As a consequence of the issue 1 in Q1, a mis-ordered sequence on receiver RMP can be

dropped before the earliest ExpiryTime expires. If we call M1 the missing message

that "breaks" the sequence order, the Receiver RMP may actually have to dump the sequence even before the resending mechanism of M1 is over. In other words, the sender

may finally succeed sending M1, get an ack for all the messages of its sequence,

and yet not know that half of the sequence was not delivered to the application.

Recommendation 2.2:

An explicit fault message to Sender RMP is the only sure way to warn of undelivered

messages in the sequence. The RMP can then escalate the failure to the sender application.

Because an explicit fault is needed anyway from receiver RMP to sender RMP in order to

cover Issue 2, option (a2) is recommended here, as providing a uniform way to notify

sequence failures.

When to decide to give up on a broken sequence:

Which information is required by receiver.

Jacques stated his proposal, and gave his answers. He believes we can vote on this proposal.

There is agreement to the proposal.

Action: Jacques will provide proposed text for the spec, leaving out rationale, to be voted at the f2f meeting.

4.5 Reliable Request Response

Small group, Jacques was editor.

Mail from Jacques:

Here is a tentative summary of the reliable request-response proposal I have sent

a couple of weeks ago ( co-signed Marc G., Sunil K., Payrits S., Jacques D.)

Because it is a big chunk, we 'd like to get feedback first on the overall direction of the proposal

(summarized below).

Then there are still some details left to be discussed.

Jacques

------------------------------------------------------------------------------------------------------------------------------------------------

General recommendation on what WS-R should cover regarding Guaranteed delivery (GD)

of messages involved in a WSDL request-response :

1- Only the following GD cases should be supported by this version of WS-R:

- GD of request + GD of response (Variant 1)

- GD of request + no GD of response (Variant 2)

The following case should be excluded (not covered by this specification) (see Option 3.1.1):

- no GD of request + GD of response (Variant 3)

2- The recommendation for GD of request-response, is that its use of Ack and resend procedures will differ from one-way ops in the following way:

- request-response is treated as a single transaction (will be entirely replayed, if either leg failed)

- in case of Variant 1, in case the response is not acknowledged, the request-response should not be replayed.

Instead, the Ack should be resent (see Proposal 1.2) (depending on firewall restrictions on either side,

either using RMP-level polling to get the Ack, or a resending mechanism for Acks.)(to resolve!)

3- Given the impact of supporting GD request-response on SOAP implementations (see Appendix A), recommendation is that it should belong to a higher conformance profile for WS-R. i.e. some implementations that cover only the reliability of one-way operations

should still be considered as conforming at some level to WS-R.

Jacques discussed the proposal above.

Jacques stated this will not be easy to implement on a soap stack. This should be optional feature.

Agreed that we will have a agenda discussion on conformance at the meeting.

Agreed to add this aspect to the conformance discussion for the meeting.

Will discuss this at the meeting how to handle this. There are still some minor issues to decide, the ack from response is lost. How do we get the other ack. Jacques will lead this discussion at the f2f meeting.

4.6 New Draft Spec for Meeting

Marc G asked if we will have a New draft for face to face meeting, with accepted issue being moved into the spec.

There are some issues which are closed and that they could be put into the text.

Iwasa agreed to check all closed issues to get them into the spec.

Action: Iwasa agreed to get document out by the end of the next week.

5 Discussion of F2F meeting document distribution policy and agenda(Oct 28 - 30) in CA

The chair asked if we can agree that the meeting will be all electronic document access

It was agreed that we will not have paper distribution at the next meeting.

Agreed starting time 9:00

Agreed call in periods

First morning for roll call. 10:00 am pacific coast time for roll call

And the last two days, time the call at the normal call time 5:30 Eastern Time.

Meeting adjourned at 7:30 Eastern time.

wsrm message

0 Draft Agenda:

1 Roll Call

2 Minutes Discussion

2.1 Appointment of Minute Taker

2.2 Approval of previous meeting minutes

3 Discussion of Interop subgroup Activities

4 Discussion of Issues:

4.1 Action items from previous meeting:

4.2 Rel 94 – poll response:

4.3 Rel 81 thru 86 on Parameters

4.4 Rel 57 Issue

4.5 Reliable Request Response

4.6 New Draft Spec for Meeting

5 Discussion of F2F meeting document distribution policy and agenda(Oct 28 - 30) in CA