OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Prelim minutes of 6/1 meeting


The prelim minutes are attached.

Please post corrections to the entire list before Friday.

tom Rutt

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133


Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003

Preliminary Minutes of WSRM TC Conference Call –May 25, 2004

 

The meeting of the WSRM TC  took place by teleconference 

Tuesday, June 1, 2004, from 5:30 to 7:30 PM Eastern Standard Time

 

 

1         Draft Agenda:

Draft Agenda to WSRM TC Conference Call

1 Roll Call

2 Minutes Discussion

2.1 Appointment of Minute Taker

2.2 Approval of previous meeting minutes –

3 Action Item Status Review

4 Discussions of unresolved editorial comments

5 Discussion of Document progression

6 Discussion of FAQ for WS-Reliability

 

2         Roll Call

Attendance:

 

First Name

Last Name

Email

Role

Company

Voting Level

Jacques

Durand

jdurand@us.fujitsu.com

Member

Fujitsu

1

Kazunori

Iwasa

kiwasa@jp.fujitsu.com

Secretary

Fujitsu

1

Tom

Rutt

tom@coastin.com

TC Chair

Fujitsu

1

Robert

Freund

bob.freund@hitachisoftware.com

Member

Hitachi

1

Eisaku

Nishiyama

nishiy_e@itg.hitachi.co.jp

Member

Hitachi

1

Nobuyuki

Yamamoto

no_yama@bisd.hitachi.co.jp

Member

Hitachi

1

John

Fuller

jfuller@wernervas.com

Observer

Individual

 

Junichi

Tatemura

tatemura@sv.nec-labs.com

Member

NEC Corporation

1

Alan

Weissberger

ajwdct@technologist.com

Member

NEC Corporation

1

Abbie

Barbir

abbieb@nortelnetworks.com

Member

Nortel Networks

1

Mark

Peel

mpeel@novell.com

Member

Novell

1

Anish

Karmarkar

Anish.Karmarkar@oracle.com

Member

Oracle

1

Sunil

Kunisetty

Sunil.Kunisetty@oracle.com

Secretary

Oracle

1

jeff

mischkinsky

jeff.mischkinsky@oracle.com

Member

Oracle

1

Pete

Wenzel

pete@seebeyond.com

Member

SeeBeyond

1

Doug

Bunting

doug.bunting@Sun.com

Secretary

Sun Microsystems

1

Tony

Graham

Tony.Graham@Sun.com

Member

Sun Microsystems

1

 

 

 Meeting  is  quorate.

 

3         Minutes Discussion

3.1      Appointment of Minute Taker

Tom Rutt will take minutes.

 

Minutes will serve to record issue resolutions.

3.2      Approval of previous meeting minutes

The minutes of the May 25 teleconf are posted at:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6979/MinutesWSRM-052504.htm

 

Alan moved to approve the minutes, Iwasa seconded.

 

No opposition, minutes approved.

4         Status of Action Items

4.1      Action 052501-1 (Tom Rutt) pending

 
New Action: Tom took a new action item to complete the status column of 
pre public review issues list, with correct URLs.
 
Open

4.2      Action 052501-2 (Sunil) pending

 
 
:Action: Sunil will come up with a proposal for the namespace for all 
four of our schemas.
 
Closed

4.3      Action 052501-3 (Iwasa) Pending

 
 
Action: Iwasa sould have a new document, .999 available by Wed . appling agreed changes from 5/25 minutes
 
Still needs to use the agreed definition from minutes for Payload
 
closed

4.4      Action 052501-4 (Anish and Tom) pending

 
Action: small team of Anish and Tom will come up with a http binding 
clarification proposal for next week.

 

closed

 

5         Discussion of Issues and editorial Comments

The following issues list includes open items which need further discussion:

 

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6924/PublicCommentsIsssues-052504Input.html

 

 

5.1      PC11.24

 

  ·  Definition of Payload
From Tom Rutt <tom@coastin.com> on
26 May 2004 12:47:07 -0000

 

the newest version (.999) has the following definition for payload:

Lines 169 and 170

Payload:

The contents within the SOAP body of a Reliable Message.

 

This needs to be changed to the definition we agreed on at the meeting:

 

Payload

information intended for the consumer of the reliable message.

 

--

Agreed change.

5.2      PC13 HTTP POST as Mandatory

 

PC13

Spec

Editorial

open

Tom Ruttl

 

Title: HTTP POST Binding Clarification

Description: We need to clarifiy that the mandatory binding in the spec is to use htttp post.This is not stated clearly.In fact we need to clarify the exsting lines 1310, 1311, 1312"(3) The Acknowledgment Message is sent with another HTTP connection from the Receiving RMP to the Sending RMP. Example 15 is an example of this message.(4) The HTTP response for (3) has no HTTP message body. Example 14 is an example for this HTTP Response."to require an http post request.This clarification is needed, for interoperability, to avoid the use of http get when http post is expected.

Proposal: From Tom Rutt on 18 May 2004 21:22:35 -0000Add the following paragraph to the intro to section 6"This section specifies a normative binding of WS-Reliability soap header elements, using the SOAP binding to HTTP, as specified in Section 6 of SOAP 1.1. The WS-Reliability header elements, when mapped to an HTTP request, must be carried in an HTTP POST operation."Add the following sentence to the conformance clause:"The binding of WS-Reliability protocol specified in Section 6 of this specification, using SOAP HTTP binding defined in section 6 of SOAP 1.1, must be used when this specification is bound to SOAP over HTTP."Meeting discussion 5/18:Anish: What do you intend on this wording. Are other protocol transport bindings allowed.Tom: the intent is If you use this spec with SOAP over HTTP you must use the binding in section 6.Take this to the list for wordsmithing.

Resolution:

 

  ·  Action item 052504-4 - Clarification of HTTP Binding
From Tom Rutt <tom@coastin.com> on
1 Jun 2004 16:37:08 -0000

 

Mail from Anish:

 

Tom,

The current wording says that if a request is sent using HTTP transport protocol, then the requester cannot ask that the ack be sent using SMTP (or an other protocol).

IMHO, this is too restrictive. All we need to say is:

1) If the request is using SOAP 1.1 protocol then the ack/reply must use SOAP 1.1. Similarly if the request is using SOAP 1.2 protocol then the ack/reply must use SOAP 1.2
2) If the ReplyTo contains only a URL which uses the 'http:' URL scheme, then
a) the ack/reply must use the section 6 SOAP 1.1/HTTP binding, if using SOAP 1.1
b) the ack/reply must use the SOAP 1.2 HTTP binding for request/reply MEP, if using SOAP 1.2.

This is necessary because a URL does not indicate which binding to use and there are multiple binding that use HTTP as the transport protocol.

Suggested amendments are inlined below.

HTH.

-Anish
--

 

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

 

1     Clarification of the Introduction of section 6, HTTP

 

Binding.

 

Replace the intro paragraph for section 6 (lines 1206

 

thru 1211) from:

 

 

This section describes the three binding pattern - “Response”, “Callback”, and “Poll” binding pattern for HTTP. These binding pattern is identified by the value of ReplyPattern element (See Section4.2.3 for detail). This specification expects that the transport layer will not deliver a corrupted message to the reliability layer.

 

When a request message contains AckRequested element, upon receipt of a reliable message, the Receiving RMP MUST send a reply. This reply MUST be either an Acknowledgment Indication or an RM Fault Indication. This reply MUST be sent by specified binding pattern in the ReplyPattern element of the request message.

 

 

to

 

 

This section specifies two normative bindings of WS- Reliability header elements to SOAP header blocks carried using HTTP as a transport protocol.

 

     SOAP 1.1 over HTTP POST binding: An implementation of WS-Reliability MAY support mapping the ws reliability header elements as soap header blocks in accordance with the SOAP 1.1 HTTP Binding, as specified in Section 6 of SOAP 1.1.

 

     SOAP 1.2 over HTTP POST: An implementation of WS- Reliability MAY support mapping the ws reliability header elements as soap header blocks in accordance with the SOAP 1.2 HTTP binding for the request/response MEP, as

specified in Section 7, SOAP HTTP Binding, of SOAP 1.2 Part 2:

 

Above text agreed

 

If a reliable message request is invoked using SOAP 1.1 over HTTP POST binding, all subsequent message exchanges pertaining to that message ID MUST use the SOAP 1.1 over HTTP POST binding.

Suggested amendment:

 

"If a reliable message request is invoked using SOAP 1.1, all subsequent message exchanges pertaining to that message ID MUST use the SOAP 1.1 protocol."

 

Agreed to amended text

 

A ReplyTo element present in a Request element or Poll Request element sent using the SOAP 1.1 over HTTP POST binding, MUST use the URI form of reference, with an http: uri to use for invoking the ws reliability response, in accordance with the SOAP 1.1 over POST binding.

Suggested amendment:

 

"If a ReplyTo element present in a Request element or Poll Request header element, sent using the SOAP 1.1 protocol, contains only a URL and uses the 'http:' URL scheme, then the WS reliability response MUST be sent using the HTTP binding specified in section 6 of SOAP 1.1.

 

Agreed to amendment

 

If a reliable message request is invoked using SOAP 1.2 over HTTP POST binding, all subsequent message exchanges pertaining to that message ID must use the SOAP 1.2 over HTTP POST binding.

Suggested amendment:

 

"If a reliable message request is invoked using SOAP 1.2,

all subsequent message exchanges pertaining to that message ID MUST use the SOAP 1.2 protocol."

 

Agreed to amendment

 

A ReplyTo element present in a Request or Poll Request header element sent using  the SOAP 1.2 over HTTP POST binding, MUST use the URI form of reference, with an http uri to use for invoking the ws reliability response, in accordance with the SOAP 1.2 over POST binding.

Suggested amendment:

 

"If a ReplyTo element present in a Request element or Poll Request header element, sent using the SOAP 1.2 protocol, contains only a URL and uses the 'http:' URL scheme, then the WS reliability response MUST be sent using the HTTP binding for request/response MEP specified in SOAP 1.2

 

agreed to amendment

 

The following subsections specify the mapping of ws

reliability header elements to HTTP request and response

messages, for the three rm-reply patterns.  The Poll reply pattern has two variations (synchronous and asynchronous). 

 

The specific reply pattern in use is identified by the value of ReplyPattern element (See Section4.2.3 for detail).

 

This specification expects that the transport layer will not deliver a corrupted message to the reliability layer. When a request message contains AckRequested element, upon receipt of a reliable message, the Receiving RMP MUST send a reply. This reply MUST be either an Acknowledgment Indication or an RM Fault Indication.  For the Callback and Poll reply patterns, a ws reliability response element can contain multiple acknowledgement and/or rm fault indications.

 

For simplicity, the detailed examples only show the use of SOAP 1.1.  However, the figures showing the mapping of ws reliability elements to HTTP POST request messages and HTTP response messages apply to both the SOAP 1.1 over HTTP POST binding, and the SOAP 1.2 over HTTP POST binding.

 

2     change Binding Pattern to reply pattern

 

Lines: 1212, 1223, 1253, 1274, 1289, 1328, 1348, 1354,

 

1369, 1410, 1414, 1430,

 

agreed

 

3     clarification that response goes on http post for

 

callbacks

 

the text for lines 1285 and 1286

 

 

(3) The Acknowledgment Indication is sent with another

 

HTTP connection from the Receiving RMP to the Sending

 

RMP. Example 14 is an example of this message.

 

 

does not require sending the rm: response on an HTTP Post

 

operation.

 

Also the text for lines 1425 thru 1427:

 

 

(5) The HTTP request corresponding to the Poll request in

 

(3) includes Acknowledgment Indication and/or Reliable

 

Messaging Fault. Example 18 is an example for this

 

message. This request is sent to the listener identified

 

the ReplyTo element in the PollRequest element.

 

 

does not require sending the rm: response on an HTTP Post

 

operation.

 

Clarify both of these sentences by stating that the HTTP

 

POST operation is used to send the  response.

 

 

Agreed with amendments.

 

Anish moved to accept proposal as amended, Iwasa seconded.

 

 

No opposition, motion passes.

 

5.3      Editorial Comments

 

5.3.1      Namespace for Schema, and location

 

Schemas and Namespaces
From Sunil Kunisetty <Sunil.Kunisetty@oracle.com> on
1 Jun 2004 17:13:38 -0000

 

 
 Folks,

 WSRM TC has the following 4 schemas:
 
 

 Schema Namespace

 File name

 Prefix

 Description

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

 ws-reliability.xsd

 wsrm

 Schemas for the WSRM Elements

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

 reference.xsd

 ref

 Has the schema for ServiceRefType

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

 fnp.xsd

 fnp

 Schema for F,P, and all Compositor constructs

 http://www.oasis-open.org/committees/wsrm/schema/1.1/feature/rel/

 wsrmf.xsd

 wsrmf

 Schema for WSRM Properties

 Except for one know change (removing ReplyTo property from wsrmf.xsd), I'm assuming the contents are going
 to be final. I suggest all of you to review the schema along with the specification document too and please send
 me comments.

 Currently, these schemas are not referencible as the schema files are hosted at a different location than
 their namespaces? If we want to make them referencible (I prefer so), then we have to change the namespaces.
 This will result changes in the schemas and the document, although the changes would be mostly
 find-and-replace.

 If we do want to make them referencible, then the namespaces should start with:
        
http://docs.oasis-open.org/wsrm/....

 There are 2 options w.r.t. to the remaining part of the namespace and that of the suffix/extension.

 a) Remaining part of the namespace.

     Option 1: Using the date/year convention that is followed by many specifications now
     (SOAP 1.2, WS-Security etc.).   Namespaces in this convention would look like:
     
http://docs.oasis-open.org/wsrm/2004/06/ws-reliability/...
     
http://docs.oasis-open.org/wsrm/2004/06/reference/...
     
http://docs.oasis-open.org/wsrm/2004/06/fnp/...
     
http://docs.oasis-open.org/wsrm/2004/06/wsrmf/...

      OASIS folks recommend the above, although they don't mandate it.

      Option 2: Is to use the version in the namespace, something similar to what we have currently.
      Schemas in here will look like:
               
http://docs.oasis-open.org/wsrm/1.1/ws-reliability.xsd
               
http://docs.oasis-open.org/wsrm/1.1/reference.xsd
               
http://docs.oasis-open.org/wsrm//1.1/fmp.xsd
               
http://docs.oasis-open.org/wsrm/1.1/wsrmf.xsd

      If we do decide to go with Option 2, we may need to further polish them.

      Between these 2 options, I prefer Option 1 as that seem to be practice these days.
 

 b) Other piece to this puzzle is whether to use the suffix .xsd in the namespace.

     Option 1:  with the suffix/extension:
     Example:
http://docs.oasis-open.org/wsrm/1.1/ws-reliability.xsd
     Something similar to what WS-Security did.

     Option 2:  without any suffix/extension:

     Example: http://docs.oasis-open.org/wsrm/1.1/ws-reliability
     Something similar to what SOAP 1.2 did.
     I prefix Option 2 here as it is elegant and succinct. However, I'm not sure whether OASIS hosting environment supports  mapping a context URI to a file name, i.e.,
     whether the URI
http://docs.oasis-open.org/wsrm/1.1/ws-reliability to a file under that context/directory. I have sent some mails to OASIS webmaster and still waiting their response on this. If this is possible, I strongly suggest option 2, i.e., without any suffix/extension to the namespace.

 Comments????

 -Sunil

 
 

WS security has .xsd in name space.

 

Tom: is there a problem with having the namespace name be the filename

 

Propose: schema name and file name being the same name.

 

Sunil: does not look good.  This is a style issue.

 

a)      use xsd in file name -

b)      do not use xsd in file name

 

2 xsd

2 no xsd

many abstains

 

The file will be names .will be xsd 

 

Anish: How the file is stored at the web server.

 

Tom: I am concerned about delaying the spec.

 

Jeff: you hand somebody  the URI, they will get an Http get on the schema.

 

Sunil: How sophisticated is the HTTP server that OASIS is running.

 

Tom: the brute force approach of WS-security works.  We do not have to wait.

 

Better wait till next week to get oasis response.

 

Next issues: dates or version numbers.

 

Tom: does WS security have a version number.

 

Jeff: I would prefer a version number.

 

Agree to Put version 1.1 in title of spec..   

 

WSS has version number in file name as well as the dates.

 

Sunil will try to use both the dates and the version number.

 

Action: sunil will continue on this one.

5.3.2      Pete Wenzel comments on draft .999

 

· Re: [wsrm] Groups - WS-Reliability-2004-05-26.pdf uploaded
From Pete Wenzel <pete@seebeyond.com> on
1 Jun 2004 20:39:46 -0000

Here are a few comments based on my quick review of 0.999.

 

Proposed changes that may require discussion:

 

  18-22: Comment process: Should describe use of the comment web form,

    not the mailing list(?)  Perhaps there is new boilerplate

    available for this.

Using the Web Form for comments.

 

Pete: took action to find out the latest convention.

 

  1205-1206: This section describes the three binding pattern -

    "Response", "Callback", and "Poll" binding pattern for HTTP. These

    binding pattern is

    ->

    This section describes the HTTP bindings for the three message reply

    patterns - "Response", "Callback", and "Poll".  These patterns are

 

    [Other uses of "binding pattern" throughout this chapter?]

 

agreed

 

  1474: Insert new paragraph:

    It has implemented all required syntax, features and behaviors.

 

Pete moved to add the new paragraph after 1494, seconded by Bob Freund.

 

No discussion.

 

No opposition, motion passes, add paragraph to conformance.

 

    [Are the requirements identified in some consistent manner

    throughout the document?]

 

Pete: what about MUSTs within MAYs.

 

Tom: currently you have to read to spec to see if it is mandatory

 

  1563: mustUnderstand ... value equal to 1 or "true"

 

BP 1.0 conformance was an issue.

 

Doug: XML schema data type there is no logical value 1, the only values are “true” or “false”.

 

Anish: currently states value = 1, it does not state value space or lexical space.

 

For 1.1: put “1” in quotes,

 

Doug: describe the soap must understand element being in the same namespace as used for the soap envelope element.  And then state that for our spec it should be “1”.

 

Anish: For soap 1.2 do we want to restrict it to “1”.

 

Would such a thing be required for soap 1.2.

 

Doug: I would agree if we do not have a reason to restrict beyond soap 1.2.

 

Agreed : wherever soap must understand is mentioned in document add two sentences:

  • for soap 1.1 must understand, we restrict to “1” .
  • For soap 1.2 must understand we restrict to “1” or “true”.

 

Tom: action to have a complete proposal.

 

Tom will get it out right after the meeting.  Iwasa will implement after discussion.

 

In 4.2, in 4.2

 

Editorial issues:

  Table of Contents: Page numbers off by one beginning around Chapter 6.

    Can the ToC items be turned into hyperlinks for easier navigation?

  105-106, 946-952: extraneous highlighting

  240: extraneous hyphen

  248: distinguishes two -> distinguishes between two

  250: reliable -> reliability

  254: derive -> are derived

  270: to -> of

  277: as different -> as a different

  358: to initially have knowledge of the RM Agreement -> to have

    knowledge of the RM Agreement initially

  382: will however greatly -> will, however, greatly

  393: notify a delivery error to the Payload Producer -> notify the

    Payload Producer of a delivery error

  394: receiving -> Receiving

  407: with same identity -> with the same Message Identifier

  656: of ReplyTo element -> of the ReplyTo element

  674: Request/ MessageOrder -> Request/MessageOrder

  905-906: extraneous line break and spaces

  1022, 1308: extraneous blue text color

  1472: conform -> conformant

  1485: to NOT implement -> NOT to implement

 

Section numbering:

  579: 4.2.1.3

  584: 4.2.1.4

  592: 4.2.1.5

  599: 4.2.1.6

  655: 4.2.3.2.1

 

--Pete

 

Iwasa should apply the editorial changes above, and the agreed changes from the motions.

 

5.3.3      Clarification of When Soap Fault must be sent

 

·  issue with use of SOAP Faults
From Jacques Durand <JDurand@us.fujitsu.com> on
26 May 2004 19:33:38 -0000

 

·  RE: [wsrm] issue with use of SOAP Faults
From Jacques Durand <Jdurand@us.fujitsu.com> on
27 May 2004 22:34:01 -0000

 

·  Section 4.5 editorial update
From Jacques Durand <Jdurand@us.fujitsu.com> on
27 May 2004 02:50:41 -0000

 

(4.5) Fault Codes and Processing For Reliable Messaging Failures

The protocol defines two fault categories:

·         The Message Format fault set, which includes all faults generated because of a malformed Reliable Message header.

·         The Message Processing fault set, which includes all faults generated while processing the message.

They are explained in detail in the following sections. These protocol specific fault codes are returned by the Receiving RMP within the response header element. Reliable Message Faults are carried in the SOAP Header, and do not rely on the SOAP Fault model for the following reasons:

·         The SOAP Fault model does not allow batching several faults in the same message.

·         RM faults may be carried by business messages that are not concerned by these faults, and for this reason they should not affect the SOAP body of these messages.

 

The rules for processing faults are:

·         A message for which an RM Fault is published MUST NOT be delivered by the Receiving RMP, and therefore MUST NOT be acknowledged.

·         In case a “Response” ReplyPattern was required, and when the message cannot be delivered to the Consumer due to a failure in processing the RM headers, then a SOAP Fault must be generated in addition to the RM Reply that contains the RM Fault. Because either a well-formed response or a SOAP Fault is expected on the Sending side, then the response leg of the transaction must contain a SOAP Fault in the SOAP Body when no business response is available. More details are given in the HTTP Binding section.

·         In case a “Callback” or “Poll” ReplyPattern was required, and when the message cannot be delivered to the Consumer due to a failure in processing the RM headers, then no SOAP Fault shall be returned. The HTTP binding section gives more details on the recommended behavior in such case.

 

(6) HTTP Binding

(6.1) Reliable Messaging with “Response” binding pattern

Add:

“In case the message cannot be delivered to the Consumer due to a failure in processing the RM headers, then it is RECOMMENDED that the response be conforming to the WS-I Basic Profile 1.0. To achieve this, the SOAP Fault element MUST be returned in an HTTP response with “500 Internal Server Error” HTTP status code. (see R1126 in [WS-I BP1.0])

(6.2) Reliable Messaging with “Callback” binding pattern

Add:

In case the message cannot be delivered to the Consumer due to a failure in processing the RM headers, then it is RECOMMENDED that the HTTP response be conforming to the WS-I Basic Profile 1.0. To achieve this, no SOAP Fault must be returned, and the HTTP response entity-body MUST be empty, with a “400 Bad Request “ HTTP status code if the RM Fault is a Message Format fault. (See R1113 in [WS-I BP1.0]). The status code should be “500 Internal Server Error” otherwise, in case of a Message Processing fault.

.

 

(6.3) Reliable Messaging with “Poll” binding pattern

Add:

In case the message cannot be delivered to the Consumer due to a failure in processing the RM headers, then it is RECOMMENDED that the HTTP response be conforming to the WS-I Basic Profile 1.0. To achieve this, no SOAP Fault must be returned, and the HTTP response entity-body MUST be empty, with a “400 Bad Request “ HTTP status code if the RM Fault is a Message Format fault. (See R1113 in [WS-I BP1.0]). The status code should be “500 Internal Server Error” otherwise, in case of a Message Processing fault.

Jacques moved to accept these changes to 4.5 and section 6, Mark Peel seconded.

 

No opposition, motion passes.

5.3.4      Comments from Tony Graham on .999

 

 

Line  Comment

 

93, etc.

        Change the many occurrences of two spaces, e.g. in 'else  "notify"',

        to a single space.

 

105  Add a comma after "side"

 

107  Change "quality of service" to either "quality-of-service" or

        "QoS".

 

        The present text reads like it's about the quality of the

        "service contracts".

 

 

118  Change "and and" to "and".

 

119  Change "Message resending" to "message resending".

 

135, 138

        Add a space after "Table".

 

135  Remove "Cardinality =".

 

135  Change "And type" to "The type".

 

138  Some of the namespace URIs end with '/' and some don't.  Is

        there any value in being consistent?

 

Sunil: mapping of a context URI it has to end with a /. 

 

If it was .xsd it would not have a /.

 

Resolve with overall issue.

 

 

140  Add a new paragraph stating that XPaths are used in titles and

        other places in Section 4.

 

        Also add a reference to XPath 1.0 in Section 8.

 

165  Change "will be" to "is".

 

176  Change "receiving RMP" to "Receiving RMP".

 

185, 188

        Change "producer party" to "Producer"

 

        "Party" was used without explanation in Section 1.2 for the

        combination of the Producer and the Sending RMP.  It should

        not be used again for something different.

 

185  Change "sending RMP" to "Sending RMP".

 

186, 190

        Be consistent about whether the parallel sentences are one

        sentence or two and about whether the sentences finish inside

        or outside the parentheses.

 

192  Remove the comma after "header".

 

192  Change "identifies reliable messages" to "identifies a

        reliable message".

 

204  Change "message which encountered" to "message that

        encountered".

 

227  Change "E.g., Sending RMP" to "E.g., the Sending RMP".

 

228  Change "sent with Callback" to "sent using the Callback".

 

229  The definition of "Reply Publishing" uses none of the

        previously-defined terminology.  For example, "error or

        acknowledgment" isn't consistent with other terminology.

 

239  Put the definition for "Intermediary" in the terminology

        section since it also appears in Section 1.2.

 

277  Change "response to this request" to "response to this second

        request".

 

288  Change "sequence number which is an integer, and which is

        unique within a group" to "sequence number, which is an

        integer that is unique within a group".

 

291  Change "althouh allowed" to "although it is allowed".

 

294  Change "a sequence number" to "a unique sequence number".

 

300  Change "A Reliability agreement for messaging" to "An

        agreement for messaging reliability".

 

300  Change the hyphens to en-dash (0x2013 in the StarOffice

        "Special Character" dialog box).

 

303 Change "protocol features, including details about choreography

        between sending and receiving RMPs, and timing parameters" to

        "protocol features, including timing parameters and details

        about choreography between sending and receiving RMPs".

 

        It currently sounds like "timing parameters" is a third level.

 

311  Change the first sentence to "Table 3 shows the Agreement

        Items that this specification uses."

 

 

Regards,

 

 

Tony Graham

 

Iwasa: will put these editorial into the next version of the document.

 

6         Discussion of Document Progression.

Soap must understand wording.

 

New document .9991  ready by Thursday morning Pacific time.

 

Question: CD numbering versus version numbering.

 

Doug: OASIS process requires that a CD must be referenencable.

 

It could be the may version.

 

Keep protocol version 1.1 separate from the CD name.

 

Iwasa will use 1.01 for the next CD name.

 

For next week the only open is the schema names issue.

 

Post editorial comments by Monday evening, so everone has a chance to look at them.

 

Tentative Schedule:

 

June 1 – all changes agreed at TC Teleconf.

 

June 2 – Frozen document available for informal 6 day review.

 

June 7 – editorial changes required to be posted to list.

 

June 8 – TC votes to approve CD at Teleconf, and also votes to submit to OASIS member vote.

 

June 15 – submission sent to OASIS Staff

 

1         Frequently Asked Questions

 

·  Updated Draft FAQ for comment
From Tom Rutt <tom@coastin.com> on 26 May 2004 15:25:14 -0000

 

Frequently Asked Questions about WS-Reliability Specification

 

Q:What is the need for the WS-Reliability specification?

 

Answer:

 

As Web Services (WS) start to be deployed across enterprise boundaries and for collaborative e-business and e-transaction scenarios, message reliability becomes a critical issue.   This is because communications over the Internet (and Intranets) is inherently unreliable, as usage of the “transport protocols” (e.g., HTTP, SMTP, and other message delivery protocols) admit conditions which do not offer guaranteed or ordered delivery.  Yet WS messages need be delivered to the ultimate receiver, even in the presence of component, system, or network failures.  If a message can’t be reliably delivered, then the user must be so informed.

 

Q: What are the reliability features supported by the WS-Reliability specification?

 

Answer:

 

A] Guaranteed delivery Delivery at least once - the sent message must be delivered at the receiver, or else a notification of potential delivery failure is given to the sender.

 

B] Duplicate elimination - Delivery at most once -with duplicates detected and eliminated by the receiver,

 

C] Guaranteed message ordering – messages are delivered in the order sent

 

Q: How does the WS-Reliability protocol relate to WSDL operation types?

 

Answer:

 

WS-Reliability has been designed to support One-Way and Request-Response operations. The two following requirements are observed by WS-Reliability:

 

1- An implementation of WS-Reliability is not supposed to be aware of the type of WSDL operation associated with the messages it is processing.

 

2- The RM protocol specified is compatible with current WS-I profiles.

 

One-Way operations:

 

All specified RM features apply to these operations, with the following restriction: In order to comply with current WS-I profiles, the "Response" reply pattern must not be used with these operations.

 

Request-Response operations:

 

All specified RM features apply to these operations, with the exception of the "response" leg of the operation, to which the Guaranteed Delivery protocol as defined does not apply: the HTTP binding required by current WS-I profiles requires a particular handling of re-sending that is beyond V1.0. It should be noted that the benefits of RM features may not be as obvious for this operation type as for the previous one: because Request-Response is often supported in a synchronous way by SOAP implementations, the application will generally have a level of control that may supersede some RM features. For example, an application can be certain that a delivery of a request occurred, when it receives the correlated response.

 

Because an implementation is not required to distinguish messages based on their associated WSDL operation type, an appropriate use of RM features will depend on the user layer.

 

 

Q: When will the WS Reliability spec be completed and what is it based on?

 

Answer:

 

Agreement was reached in Nov 2003 on a committee draft spec (v0.52),

which was implemented in a demo at the Philadelphia XML Conference, in Deceber 2003. The TC has recently voted on a committee draft spec

(v.0.992) which completed its 30 day public review, April 19, 2004.

Note that the spec is based on Requirements issues that have been

compiled for the committee’s internal use (over 100 requirements have

been identified).

 

- An OASIS standard could be approved in the 2nd Quarter of 2004

 

 

Q: What is the relationship between WS-R and ebXML V2.0?

 

Answer:

 

Overall, they both have same messaging reliability contracts as objectives: guaranteed delivery, no duplicate delivery, ordered delivery, and combinations

of these. 

 

However, WS-R has improved on scalability and performance by generalizing the use of sequence numbers, and can accommodate different security and access conditions on each party, as this is more frequently the case with a Web service and its clients, compared to more symmetrical access conditions in messaging. The reliability contract is more "application-oriented" in WS-R, where acknowledgment is on final delivery, in contrast to "on receipt" by the message handler in ebMS.

 

Q: Why does the spec have a different name than the TC?

 

Answer:

 

The difference in naming of the TC (WS Reliable Messaging) and the specification (WS Reliability) is a result of how materials were originally submitted to OASIS to initiate this activity.  The TC chose not to rename the specification to avoid confusion with a similarly named, though unrelated, specification (WS-ReliableMessaging) that has not been submitted to a standard body. This permits one to unambiguously refer to the exact specification being discussed.

 

 

 

·  FAQ on Reply Pattern Support
From Tom Rutt <tom@coastin.com> on 1 Jun 2004 20:06:42 -0000

Action Item work from Jacques, Sunil and Tom:

 

 

The following is a proposal for a FAQ on reply pattern support.

FAQ:

'Why several reply patterns.?

Answer:  Because there are different use case and deployment scenarios and different WSDL MEPs/operations, limiting to just one reply pattern will adversely affect its usage and importance of the protocol.

For example, a Sender behind a firewall may prohibit incoming requests, as required by the callback reply pattern  and, hence, needs to use some kind of polling mechanism to poll for the message.

Similarly a one-way WSDL operation cannot use a Response pattern as it is against the WS-I Basic Profile 1.0 for a one-way operation to have a SOAP envelope in its response. Because of such common, yet different use cases, different reply patterns have to be supported by WS-Reliability."

 

Ask : anybody disagree with posting the agreed text above.

Jacques moved to accept these FAQ items, abover, for first version, Seconded by Iwasa.

 

Not discussion

 

No opposition, motion passes.

 

Send to carol and Ask her how to post them.

 

The following one needs more work:

Action: Jacques, will propose further edits, on the following.

 

Q: How is WS-Reliability designed to compose with other web service protocols?

 

Answer:

 

Web service specifications which can compose with WS-Reliability are likely to fall under the following (fuzzy) categories :

 

(a)- "Under WS-R": Add-ons to SOAP transport like routing, addressing, that WS-R may need to accommodate or profile.

Status: nothing in the open space yet

 

(b)- "Supporting WS-R" specifications (policies, WSDL annotation), that support some function assumed by WS-R but not central to its deployment:

Status: not finalized or not open.

 

(c)- "Over WS-R", Higher level specifications (BPEL, Choreography, CAF, ASAP...) would use/profile reliability, not the reverse.

 

(d)- "Complementary to WS-R" specifications (Security, transactions, Context...)

that support other business requirements likely to be used in conjunction with reliability, and share message footprint.

 

SOAP header composability and processing model makes this possible.. An important consideration in design of the WS-Reliability protocol was to have it be orthogonal to any other web services protocols which define the use of  soap header elements.  WS-Reliability defines elements to be sent in  Soap headers .  Our header elements  only contain parameters essential for the operation of the WS-reliability protocol.   For example, WS-reliability defines a reply to element for the sending Reliable Message Processor to convey a call back address for the Reliable messaging reply.  This address is independent of any other reply mechanisms used for other protocols (e.g., WSDL response is not influenced by the WS-Reliability reply To parameter).   Apparent redundancy (message ID, reply to address for callback) should not be an issue

 

Appropriate profiling and guidelines may apply.

 Bob has text on the letters to send aroung

Bob F mad motion to adourn.  Anish seconded.

Admourned at 7:21 PM.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]