Preliminary Minutes Thursday Boston F2F

The following voting members were added to the attendance roll.

Eisaku	Nishiyama	nishiy_e@itg.hitachi.co.jp	Member	Hitachi	1	x
Junichi	Tatemura	tatemura@ccrl.sj.nec.com	Member	NEC	1	x

7 WS-Reliability Spec Draft Review

First page has name change to working draft.

Decided to delete last sentence of abstract.

Introduction needs to be updated.

Add reference to basic profile 1.0

Deleted example from section 1.4, and replace with a placeholder.

Figure 2 needs change, ack message or fault on return

Agreed for need to add picture for each of the three rm-reply patterns.

He did modify the messageId clause. This needs clarification of semantics of use of sequence number when ordering is in in use.

Need to update fault section

Need to update Http binding section.

Scott and Sunil will be the schema editors.

8 Resumed discussion of Specification Issues

8.1 Rel 37

Here is a proposed resolution for Rel37:

REL-37 Spec 3.1.4 feature Design Unassigned

Title: Use of messageID in RFC2822

Description:

Alternative could be uri

The reason this exists is that software to generate

a unique id by RFC2822 is very common. This

guarantees uniquness, uri does not.

Global Unique IDs (GUIDs): Generating GUIDs is a nasty problem. One easy way

to solve would be that Sender asking the Receiver to generate one for it

before it initiates any reliable message.

Proposed Resolution:

Close this issue with no action, since now the MessageId is removed.

However there would be same issue for GroupId.

But I would like to keep the format for GroupId as-is, unless

someone propose a new format for GroupId.

Any comments?

Thanks,

Iwasa

Jeff M stated the web world is using URI’s for identifiers.

Doug B stated the mid URI scheme could be recommended for the URI contents for the GroupID. This would add only a few octets over using the MessageID, but allows greater flexibility.

It was clarified that Doug’s suggestion will not cause interop problems if the sender uses another URI form, as long as the sender can guarantee global uniqueness.

RFC2392 defines the message ID uri scheme (using “mid”).

Agree to change GroupId syntax to be URI, with a recommendation to use the “mid” shema, from RFC2392

Issue agreed to be closed with this resolution.

8.2 Rel 28

Here is a proposed resolution for Rel28:

REL-28 Spec 1.1.1 feature Design Unassigned

Title: Application Level Synchronous Messaging

Description: Should now be in scope represented in the req/resp MEP.

Proposal: Close on next call unless a proposal comes forward for this one.

Proposed Resolution:

Close this issue with no action, since this could be resolved with

combination of piggybacking[Rel51] and request/response binding

pattern[Rel19].

Comments?

Iwasa

Marc Gooder stated that 28 has nothing to do with piggybacking.

Payrits stated there is text needed in the document to cover lost response+ack message.

Doug B stated the sender would retransmit the request in this case, because it does not get the response.

Payrits asked what would happen if the ack to the response is lost (since original receiver cannot resend the response).

Marc G stated that the ack would go on an http request, the http response would let the ack sender know the ack was received.

The problem is when the request receiver did not get an ack for the reliable response, it has no way to set up a http connection with the original sender to resend the reply.

Agreed to close issue with no action. We will support request response wsdl operation types.

Agreed to a small team (Payrits, J. Durand, Sunil, Marc G) to propose RM protocol mechanisms to support Reliable WSDL Request response operations. Target to have a proposal ready in two weeks.

8.3 Rel 76 (spec issue on polling)

Sunil agreed to take homework to come up with text to include in the spec to cover polling. This should be ready for the next conference call.

8.4 Rel 27

Here is a proposed resolution for Rel27:

REL-27 Spec Abstract feature Design Unassigned

Title: Receiver can not accept incoming connection

Description: See REL-9

Proposal: Close on next call unless a proposal comes forward for this one.

Proposed resolution:

Close this issue with no action.

Thanks,

Iwasa

Agree to close this issue because there is no requirement.

8.5 Rel 39 Reply to

Mail from Tom Rutt:

Modify the definition for the AckRequested element to take out the “synchronous attribute”. Note that this makes the element empty (no value, no attributes)

Rename the Synchronous attribute as “RMReplyPattern” and make it a mandatory element, to change the use of the terms synchronous and asynchronous to the new binding pattern terms.

Note: This proposal includes the RM-faults in the definition for the binding pattern element.

Make the Reply To an optional attribute of the RMReplyPattern Element.

It should remain an open issue as to which RM headers these two elements are contained in.

Change 3.2.4 to the following:

“

3.2.4. AckRequested Element

The AckRequested element is an OPTIONAL element. This element is to be used for a sender to request the receiver to send back an Acknowledgment (or RM-Fault) message for the message sent.

The pattern used to send the Acknowledgement or RM-Fault is based on the value of the RMReplyPattern element.

“

Change the existing 3.22 ReplyTo element to the following:

“

3.2.2 RMReplyPattern Element

The RMReplyPattern element is used for a sender to indicate what RM reply pattern is requested. The RMReplyPattern element is a MANDATORY element. This element is used to specify whether the Acknowledgment Message (or RM fault messages) should be sent back directly in the reply to the reliable message, in a separate callback request, or in the response to a separate poll request.

This element MUST have one of the following three values.

- Response : An Acknowledgment Message (or RM Fault message) MUST be sent back directly in the Reply to the Reliable Message. This pattern is not applicable for one-way application level MEP

- Callback: An Acknowledgment Message (or RM Fault message) MUST be sent as a callback request, using the address in the ReplyTo element

- Poll: An Acknowledgment Message(or RM Fault message) MUST be sent as a response to a poll request

The RMReplyPattern element contains the following OPTIONAL attribute:

- a ReplyTo attribute

(1) ReplyTo attribute

This is an OPTIONAL attribute, used to specify the initial sender’s endpoint to receive a callback Acknowledgment message or Fault Message. A value of this attribute MUST be present if the RMReplyPattern element value indicates that the Callback Acknowledgement pattern is requested.

If present, the ReplyTo attribute is required to be URL as defined in [RFC 1738].

“

This was agreed to be applied to the editor’s draft.

8.6 Rel 87

Mail from Sunil:

Here is a proposal for WS-R Headers based on REL-36, REL-39, REL-46.

We will have 4 Headers. Once we finalize it, I can create

a schema.

RMMessageHeader

- GroupId - MessageID [RFC2822]

- SequenceNumber- MessageID [RFC2822]

- TimeStamp UTC

- TTL or MED or whatever UTC (not used on simple ack or fault)

- RMReplyPattern –STRING (not used on simple ack or fault)

- ReplyTo attribute - uri

RMRequest

- AckRequested

- DuplicateElimination

- MessageOrder

- status attribute = Begin, Continue, End

RMResponse

- RefToMessaageId - - MessageID [RFC2822] Fix this to be the vector groupID/SeqNo

RMFault - QNAME

Thank

RMMessageHeader is MUST be present, others MAY be present.

Agreed to change TimeToLive element name to “ExpiryTime”. Iwasa will change throughout document.

Group agreed to proposal.

8.7 Rel 41

Ack requested name change.

Agreed to Close with no change, semantics have been clarified.

8.8 Name Prefix of Parameters.

Doug B suggested we remove the RM prefix from our header names.

Proposal: Remove all “RM” prefix from element and attribute names.

No opposition. Agreed. Iwasa will apply to next edit.

The only use of “RM:” will be as a namespace prefix.

8.9 Ordering and sequence no discussion

The text is currently unclear on whether sequenceNO other than 0 can be used without ordering. The general consensus is no.

Without ordered deliver, the groupID is unique for each sent message. Thus the group size is considered to be one in this case.

If a user want to have two application groups of messages, where all of the first application group is sent before any of the second app group is sent:

The sender will generate a single RM:group id to used for both of the application groups, and will treat it as one RM group for ordered deliver.
If the user needs to identify their application group, they must include it as part of the schema for the application message payload (e.g., in the WSDL input message).

The groupID is used only to scope the ordering. It is not to be used for other grouping purposes.

Payrits asked what the indication is that the sender wants to do ordered deliver. (or what does the sender to indicate that it does not want ordered delivery).

Sunil suggested that, either:

· a sequenceNo starting with 1 is required for ordered delivery, zero value implies ordering not requested..

· Make sequence NO optional to send, and if sent implies ordered delivery.

The current spec has a messageOrder element, which has a status attribute to identify first , more, or last.

For now clarify that when ordering is not in use, the sequence no is always zero.

9 Demo of WS-Reliability 1.0

There was a demo of the WS-Reliability 1.0.

The demo participants included:

Jacques Durand, Bob Freund, E. Nishiama, J. Tatemura (all voting members)

Peter Petersen, Oracle, peter.h.petersen@oracle.com

Sumit Gupta, Oracle, sumit.gupta@oracle.com

Hamis Ben Malek, Fujitsu, Hmalek@fsw.fujitsu.com

Isao Hirano, Hitachi, hirano@bisd.hitachi.com.jp

Bob Freund opened the demo.

The presentation is posted in the meeting section of the website ( http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/3369/WS-RMDemo-0904.pdf )

The trouble maker runs on the receiver side.

They will provide feedback from their efforts, and will tailor the issues feedback to the current draft.

The demo was successful.

Jeff M stated it would be useful to have this as an official feasibility demo, interoperability test subteam of the TC.

Jacques stated there was a lot of work on the test bed architecture, which was not shown in the demo.

Having an officially sanctioned subgroup of the TC would allow other members to join in the informal demonstration.

Peter, from Oracle, stated that WS-I have sample app implementations hosted on a public web site, to allow testing against their service.

Peter also stated it is important to have this group, with a document stating formally what the demo is about. He would like to see a detailed spec on a demo endpoint service, along with standard problems in the demo.

Marc G stated that a sample application as additional deliverable may affect our timeline.

It was clarified that we would not have to hold up the main spec waiting for the demo endpoint service spec.

Peter stated that having such a spec would simplify the process of joining the demo.

Sunil stated that using OASIS document delivery would help for sharing code, etc.

Jeff M stated one of the reasons to make this part of the work of the TC, makes us covered by the OASIS IPR rules. This will help in anti-trust measures.

There is a question on how to distribute common test bed code.

Two deliverables mentioned:

Demo endpoint service specification
Common code for distribution.

Having a separate subgroup would formalize the process.

Tom Rutt asked the demo participants to put together a proposal for a TC subgroup.

The purposes of a new TC subgroup would be, to:

Provide a mechanism for interoperability testing across different implementers of the specification
Provide concrete specific feedback to the TC regarding implementation experience with the specification.
Provide promotion/PR capability for the realization of this specification.
Provide test tool standards, specifications, and test case definitions, for those choosing to participate in interoperability testing of WSRM.

A future activity (not necessarily the same subgroup) could be to:

Provide a compatibility test suite for the spec.

There were several concerns about ha

Historically speaking, the OASIS process allows latitude for TCs to form subgroups.

Jacques stated a driver for this work is to promote a common, consistent, and interoperable interpretation of the spec. There were some objections to having this point be explicitly listed in the charter points for the new subgroup.

Another future activity (not necessarily an OASIS subgroup) could be to:

Provide distribution point for sample apps or other test tool implementations in support of the above activities (the activity would have to sort out IPR and licensing concerns).

10 Continuation of Specification Issue discussions

10.2Rel 58 Namespace Identifier

Doug thinks we have a few high level questions to answer before sending it to editorial team:

What scheme (urn or http) should we use for the namespace identifier?

Doug stated that OASIS has a urn scheme reserved.

e.g., “ urn:oasis:names:tc:wsrm:schema:1.1:SOAP1.1 ” for the soap 1.1 compatible schema, and “urn:oasis:names:tc:wsrm:schema:1.1:SOAP1.2” for the soap 1.2 compatible schema

RFC 3121 states that if we use urn for OASIS we need to use the recommended form.

HTTP form gives people a place to look to for more information on the schema referred to by the namespace.

Doug stated the decision is independent of the schema location attribute.

e.g., of http form:

http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1 and

http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.2

There was consensus to go forward with HTTP naming scheme.

The document name for the output from this meeting will continue to be “Web Services Reliability” Working draft 0.1. It will use the target namespace as the first http:// form.

Alan stated that it would be better if the spec had the same name of the TC. However, Jeff m pointed out that there is another spec copyrighted with that name already.

The schema name should be ws-reliability.

Should the namespace identifer include a version identifier for the first version of the protocol?

We resolved issue SOAP-1 through a requirement to supply 2 schemas. Does this lead to a need for multiple namespace identifiers?

If so, how many? 2, using an entity reference for the unchanging portion of the schema, 1, extending that to use the same namespace identifier in the two resulting schema instances (that are never processed simultaneously), and 3, providing the core information in a separate schema and namespace, are all possible.

Will we also supply a normative schema location (require a specific value in all message instances)?

Doug stated that OASIS has a urn scheme reserved.

e.g., “ urn:oasis:names:tc:wsrm:schema:1.1:SOAP1.1 ” for the soap 1.1 compatible schema, and “urn:oasis:names:tc:wsrm:schema:1.1:SOAP1.2” for the soap 1.2 compatible schema

RFC 3121 states that if we use urn for OASIS we need to use the recommended form.

HTTP form gives people a place to look to for more information on the schema referred to by the namespace.

Doug stated the decision is independent of the schema location attribute.

e.g., of http form:

http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1 and

http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.2

There was consensus to go forward with HTTP naming scheme.

The document name for the output from this meeting will continue to be “Web Services Reliability” Working draft 0.1. It will use the target namespace as the first http:// form.

Alan stated that it would be better if the spec had the same name of the TC. However, Jeff m pointed out that there is another spec copyrighted with that name already.

The http scheme uri agreed for the normative schema location, should be http://ws-reliability.

http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1/ws-reliability.xsd

Close Rel 58 with the above resolutions.

10.3New issue Clarification of Sequence No without ordering

Sunil made a new proposal:

The problem with the initial spec. (v1.0) is that the there are

2 unique ids. (Msg. Id., Group Id. + Seq. No.) which are redundant.

The problem with the current spec. is that

- Not sure whether Seq. No. is needed or not for Un-Ordered Msg.

- Confusion whether this sub-element is optional or mandatory with 0

- Confusion around when to trigger MessageOrder

- When MessageOrder exist?

- When Seq. No. exists and is >1 ???

Proposed Solution:

Move the Seq. No. sub-element from MessageHeader element to MessageOrder

sub-element.

GroupId is unique as along as MessageOrder/SeqNo doesn't exist

If MessageOrder/SeqNo does exist, GroupId + Seq. No

Response will have 2 sub-elements as already decided

- RefToGroupId (Mandatory)

- RefToSeqNo (Optional)

Adv.:

- Don't have to be used for Non-Ordered Msgs.

- Easy triggering for Message Order

Marc G expressed a concern that the messageID sub elements would be split across two headers, which have arbitrary order of delivery.

Agreement to replace RefToMessageID with two new elements:

RefToGroupID
RefToSequenceNo

Four alternative proposals:

As Sunil suggested above: Move sequenceNo sub element from Message header to Request:MessageOrder sub element.

· Un ordered messages use seq no = 0 always, in Message header (for use in Response/RefToSequenceNo), and messageOrder subelement is not present in Request header

· Ordered messages use seq no >=1 in Message header, and the messageOrder subelement is present in Request header element.

· Un ordered message does not have seq no present in Message header (no RefToSequenceNo element present in Response header), and the messageOrder subelement is not present in Request header element.

· Ordered messages use seq no >= 0 in Message header, and the messageOrder subelement is present in Request header element.

same as 3, except move messageOrder status attribute to be attribute of sequence number element, and remove messageOrder element.

Meeting consensus on alternative 4) above.

Add text to clarify that:

Group ID is to identify a sequence of messages, where each sequence is of length 1 or more.

Close new issue with above resolution.

10.4Rel 40 Optionality of TimeToLive

Meeting already agreed to change name to “ExpiryTime”.

Question: do we want to allow a message which (symantically) has no expiry time.

Answer, no.

Agreed to close issue Rel40 to make ExpiryTime mandatory.

10.5Rel81

Close issue, with no change because ExpiryTime element is mandatory now.

10.6Spec wrapup

Iwasa agreed to make a new version of the spec available for the Friday meeting.

The meeting agreed to have a vote to progress the new spec to wg draft status, but not available for public comment.

wsrm message

7 WS-Reliability Spec Draft Review

8 Resumed discussion of Specification Issues

8.1 Rel 37

8.2 Rel 28

8.3 Rel 76 (spec issue on polling)

8.4 Rel 27

8.5 Rel 39 Reply to

8.6 Rel 87

8.7 Rel 41

8.8 Name Prefix of Parameters.

8.9 Ordering and sequence no discussion

9 Demo of WS-Reliability 1.0

10 Continuation of Specification Issue discussions

10.2Rel 58 Namespace Identifier

10.3New issue Clarification of Sequence No without ordering

10.4Rel 40 Optionality of TimeToLive

10.5Rel81

10.6Spec wrapup