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 aug 12 tc meeting

The prelim minutes are attached.

Please post corrections before next monday.

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

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


Prelim Mnutes WSRM TC Conference Call – August 12, 2003



1 Roll Call

Last Name







Arjuna Technologies Limited




Booz Allen Hamilton




Cyclone Commerce




France Telecom







TC Chair

























Mitre Corporation




NEC Corporation
























Sun Microsystems




webMethods, Inc.




WRQ, Inc.

2 Minutes Discussion
2.1 Appointment of Minute Taker
Doug will take detailed resolutions.
Tom Will take minutes of discussion.
2.2 Approval of previous meeting minutes

7/29/2003 Teleconference minutes:

Dave ingham moved, Jeff turpin seconded.
NO opposion minutes approved.
3 Discussion of Issues:




Dave led us through the issues.


3.1 Rel 39 - Reply To


Sunil sent out a proposal on Aug 1, with a proposal.


The name binding pattern was proposed to be a RMRepyPattern.


The name does not refer to the binding in wsdl.


Doug had questions:

Not clear why we are discussion non reliable messages, in the text.


   3.2.4: Sentence “however this element must not appear in a non reliable message”.


Bob stated the universe of non reliable messages is very large.


Jishnu stated that the presence of this element will implies that this is a reliable message.


There is still an open issue, 16 , about the requirement for ack requested with hordering.


Magdolna stated reliable message is a general term.  If we use capitals for Relaible Message is confusing.


There is already a sentence stating  It is Required for guaranteeing message delivery..


Delete sentence “it is required for RM and the next sentence.”


Bob stated that deleting the two sentences is ok.


Payrits asked about the reply to attribute. 


Sunil clarified that the Reply to is no longer an attribute of ack requested.


Sunil move to accept the proposal with deleted two seconds.  Bob seconded.


No opposition, motion passes Issue rel 39 closed with resolution.


3.2 Rel 16  Ordering and ack requested.


This has seen several emails, one from Iwasa and a reply from sunil.


Sunil stated we need to split into two issues.


a)      is ack requested a must when someone is using ordering.


b)      is duplicate elimination  a must for ordering.


There was not agreement.


Regarding a): Scott gave a use case of an app delivering non critical messages, eg logging.  It would be ok to miss a message now and then, but you do want them ordered.


Scott stated that it would be difficult to distinguish a lost message from one that is late in arriving.  Scott stated using the message expiry time would work.  The receiver if receive d 1 and 3, once it had 3 it would wait for the expiry time for 3, and if 2 was not received by that time, it would deliver it above.


Sunil stated that this could happen, with ordering or not.


Doug stated the idea is to use the expiration time to decide when to ignore gaps in the sequence.   If a message is received out of sequence it is held up till epsilon before message expiry.  It comes close to violating other words in the spec, and it is a difficult way around meeting the use case.   He asked if this is a use  case we need to solve.


Payrits stated that he would not impose mandatory reuirement to


Scott reason is for performance optimization. 


Scott stated the extension would make the sender easier in this use case.


What is behavior of message ordering if the message is missing.


Payrits is uncertain about making this change.


Scott stated the logic to implement recovery from a missing message, is the same.


Scott stated he is willin got forgo this.


Resolve issue 16 a) ack requested is required for ordering.


16 b)  Is duplicate elimination required for ordering.


Sunil stated there is no need for duplicate elimination required for ordering.


Iwasa stated that whether using duplicate elimination or not, the message goes to the app layer is going to remove duplicated messages when using ordering.  The sequence number less that latest message should be removed because of ordering.  Same sequence no message will be removed by the ordering mechanism.


Sunil stated we should allow this, but we should not make duplicate elimination mandatory.


Doug stated the current ordering algorithm does not require eliminating the duplicate message in the ordering case.


Magdolna: confused if not required.  If don’t request duplicate elim – all messages must be passed to app.  If the duplicate message is sent out of order, it has to be delivered, unless duplicate elimination is requested.


Sunil stated the algorithm does allow sending the ordered messages more than once.


Doug : 1, 2, 3 received and forwarded, the n 2 is receive as a duplicate, then that duplicate is required to be delivered .


Tom asked what the definition of ordering is.


Payrits stated 1, 2, 3, 2 means 2 is not second.


1,2 3, 3 is another example from Ben.  


Doug stated that  Neither of these cases are possible with the current requirements.


Sunil clarified that the current spec does require the coupling.


Doug stated 1, 2, 3, 2 is not allowed.


Sunil understanding  of message order, deliver as long as all preceeding are received.


Sunil stated that it should deliver the second 3 in the 1, 2, 3, 3, case.


Doug asked how you could define the ordering so the one case is disallowed while the other is allowed.


Sunil stated that his definition of ordering would send the duplicate message in both cases.


Magdolna stated that this is not a clear rule.


Bob asked if ordering implies monotonic increasing order.  He stated that the usability would be better with the monotonic rule.  Conceptual gaps between ordered delivery and duplicate elimination.  Bob states the duplicate elimination must be required for ordered deliver.


Sunil agreed that this is the most common scenario.


Dave I stated that by separating the two we do not reduce the protocol, since both can be requested.  It increased the flexibility of the spec.


Payrits asked if there is any advantage to using message ordering without implicit elimination.


Dave I stated he has no use case.


Ben stated that the flexibility is not justified.


Tom asked if we can resolve by requiring duplicate elimination when ordered delivery is in use.


Magdolna moved, Ben seconded.


No oppositon, motion passes.


The first new issue, what happens to ordered sequence when missing message is not received within the message lifetime.

Scott stated we have not described the semantics of acking with ordering.


Scott agree to start two new threads of email on the two new issues.


3.3 Rel 56 Issue of configuration


Doug stated we need to finalize the discussion of Alan’s proposal on email before the next meeting.


Alan sent a new email on the 29th of July.  This is for Rel 56.


Decided to defer discussion until next meeting.


3.4 Soap 1


This is the substantial remaining requirements issue.


Payrits sent an email about this back on 27 th, prior to our last meeting.


There was not much discussion.




 I would summarize the minimal changes in the spec needed for SOAP 1.2 support in WSRM:


 - schema must be changed to allow SOAP 1.2 elements to be present in the messages. This means actually SOAP 1.2 MustUnderstand attribute. (see schema below).


-  Fault handling needs to be changed in the spec anyway, because it is not perfectly defined now (breaking SOAP 1.1 rules, no SOAP-level error codes etc..), that's where SOAP 1.2 compatiblity must be cared for.


 - refer to SOAP 1.2 where SOAP 1.1 is referred in the spec.


You can check the changes between SOAP 1.1 and SOAP 1.2 yourself in Section 6 of the SOAP 1.2 Part 0 (Primer) document. I think all other changes effect the implementation but not the specification. Using Infosets in addition to the schema, may be considered, but is not a must. (However, it means minimal editorial work. For example in Section 3.4.1 there should be a line added:


And everything else should remain.)



            Best regards,




<?xml version="1.0" encoding="utf-8"?>

            <xsd:schema targetNamespace="http://schemas.fujitsu.com/rm"





            elementFormDefault="qualified" attributeFormDefault="unqualified">


            <xsd:import namespace="http://schemas.xmlsoap.org/soap/envelope/" />

            <xsd:import namespace="http://www.w3.org/2003/05/soap-envelope" />




            <xsd:element name="MessageHeader">



                                                <xsd:element ref="ns1:From" minOccurs="0"/>

                                                <xsd:element ref="ns1:To" minOccurs="0"/>

                                                <xsd:element ref="ns1:Service" minOccurs="0"/>

                                                <xsd:element ref="ns1:MessageId"/>

                                                <xsd:element ref="ns1:Timestamp"/>


                                    <xsd:attribute ref="soap:mustUnderstand" use="optional"/>

                                    <xsd:attribute ref="soap12:mustUnderstand" use="optional"/>







<xsd:element name="ReliableMessage">



                        <xsd:element name="MessageType" minOccurs="0">


                                    <xsd:restriction base="xsd:string">

                                                <xsd:enumeration value="Message"/>




                        <xsd:element ref="ns1:ReplyTo"/>

                        <xsd:element ref="ns1:TimeToLive" minOccurs="0"/>

                        <xsd:element ref="ns1:AckRequested" minOccurs="0"/>

                        <xsd:element ref="ns1:DuplicateElimination" minOccurs="0"/>


                        <xsd:attribute ref="soap:mustUnderstand" use="optional"/>

                        <xsd:attribute ref="soap12:mustUnderstand" use="optional"/>






<xsd:element name="RMResponse">



                                    <xsd:element name="MessageType">


                                                <xsd:restriction base="xsd:string">

                                                            <xsd:enumeration value="Acknowledgment" />

                                                            <xsd:enumeration value="Fault" />




                                    <xsd:element ref="ns1:RefToMessageId"/>


                        <xsd:attribute ref="soap:mustUnderstand" use="optional"/>

                        <xsd:attribute ref="soap12:mustUnderstand" use="optional"/>






<xsd:element name="MessageOrder">



                                    <xsd:element ref="ns1:GroupId"/>

                                    <xsd:element ref="ns1:SequenceNumber"/>


                        <xsd:attribute ref="soap:mustUnderstand" use="optional"/>

                        <xsd:attribute ref="soap12:mustUnderstand" use="optional"/>




Payrits summarized that a new must understand attribute and a new fault element must be defined.


Payrits stated that the only thing we are defining is soap headers.  These can be used for either soap 1.1 nodes or soap 1.2 nodes.   The namespace of envelope element tells the processor.


The question is whether both must understand attributes are put in the schema.


Sunil stated you cannot have one schema with two optional attributes.   He send an email:



 It's better to define 2 different schemas with different targetNamespaces for

 soap 1.1 and soap 1.2 versions rather than a consolidated one.


 As per the schema below, here are some comments:



     <xsd:attribute ref="soap:mustUnderstand" use="optional"/>

     <xsd:attribute ref="soap12:mustUnderstand" use="optional"/>


 By having both mustUnderstands 'optional', one can send a RM without

 any mustUnderstand attribute at all for RM Headers, which is against our

 specification (our spec. mentions that mustUnderstand attribute must be present).


 While we can have a complex schema to say that one of them must be present,

 the problem goes away if we have 2 different schemas.




 <xsd:import namespace="http://schemas.xmlsoap.org/soap/envelope/" />

  <xsd:import namespace="http://www.w3.org/2003/05/soap-envelope" />


 Though it should be okay importing the above 2 imports (since the targetNSs

 are different), it will be better if we avoid it as the local names are same.


3) targetNamespace="http://schemas.fujitsu.com/rm


 We should start using a standard (OASIS namespace or some other NS)

 and a valid namespace.




Joe Chiusano:.  Can have a 1.2 schema which can extend the 1.1 schema.  Using schema derivation techniques..The redefine can be used in the extended schema.


Doug stated that you could do it this way.  The outermost header elements would be in one or another.


Doug clarified that in this case there are  still two schemas, but they do not have to be separately managed.


Doug asked how the sender knows which soap envelope to use for a given event.


Joe stated that some policy handshake could let the two nodes know which version to use.


Doug asked what a 1.1 endpoint receives a 1.2 soap message.


Sunils stated that it may send a version mismatch.


Doug stated that the entire envelope for a soap 1.2 message  is in a namespace the soap 1.1 node would not have knowledge of.


Payrits stated that this case is covered in the version mismatch.


There was agreement that we would need two schemas. 


Sunil stated that these schemas should have distinguishable name spaces.


Doug disagreed, since these have different soap body namespaces.


Agreed to add new technical issue for spec.


What namespaces should be used in editor’s drafts.  This is an issue for the editors.


Doug stated we would also have to address the infoset issues, if writing a spec for both 1.1 and 1.2.   Some people state that such a spec would require infoset terminology.


Payrits did not disagree it is useful, but we could live without it.


Payrits agreed that you can use info set terminology to define headers for use with soap `1.1.


Payrits stated that soap 1.2 does not need to be tied to schema.


Soap 1.2 specs do not give schema but give infoset.


Payrits stated we should also give schema, even if infoset is used in the spec.


Joe asked if there is a schema to infoset converter.


Bob stated that this notation occurring is nice, but should not slow down our first publication.


Tom asked if Doug could determine if an infoset description is required for a 1.2 soap application.


Payrits stated it is nice, and would be good to include.


Payrits stated that the fault change does not accept the schema at all.  Just the text on the fault section would be required.


Joe asked if anyone needs an infoset definition.example.


Joe will send a url to the list for peoples’ information.


We will publish a soap 1.1 compatable schema even if we have an infoset spec.


Doug move that when we publish this spec we have two schemas, one compatible with soap 1.1 and the other compatibile with soap 1.2.  Jeff turpin seconded.


No opposition, motion passed.


Soap 1.1 version mismatch must be responded.


Sender that has both 1.1 and 1.1 capabilities, can with, at most one extra error, can determine the version of the receiver.


The infoset is optional to be included in the spec.


Jeff M stated that this does close the requirements issue.,


Add as a new spec issue the need for the infoset.Terminology. 


Agreed to close the soap 1.2 issue, but add a new spec issue soap 2 regarding the need for infoset in the spec.


Doug stated that the requirements issues are closed (except for Rel 56), but the status does not reflect the stages.


Doug asked payrits to go thru the list of closed requirements issues and determine their true status for the issues list.


By the end of the week payrits will either update a new spec by the end of the week.


Goal is wg draft spec, and an almost complete requirements document.

4 Discussion of Editor’s Draft Requirements Document


Target to approve the requirements by the end of the face to face.
Send any comments to the list before the next meeting.
Payrits will have new draft available before end of week.

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