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/8 Teleconf

the prelim minutes are attached.
We will have next week's meeting on monday instead of tuesday,
at the normal time and number.

Please post corrections 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 –June 8, 2004


The meeting of the WSRM TC  will take place by teleconference 

Tuesday, June 8, 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 Scheduled Vote for CD

7 Scheduled Vote to Submit to OASIS for member vote

6 Discussion of FAQ for WS-Reliability


2         Roll Call



First Name

Last Name




Voting Level





Booz Allen Hamilton






Cyclone Commerce

















TC Chair





































Nortel Networks




































Sun Microsystems






Sun Microsystems






University of Hong Kong




 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 June 01 teleconf are posted at:



Iwasa moved to accept, Abbie seconded.


No opposition, minutes approved.

4         Status of Action Items

  ·  Action Item status as of 6/3/04
From Tom Rutt <tom@coastin.com> on
3 Jun 2004 17:44:53 -0000


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


4.1      Action 060104-1 (Sunil) pending


Action: Sunil will come up with a proposal for the Namespaces and Schema file locations.



4.2      Action 060104-2 (Pete Wenzel) pending


Pete: took action to find out the latest convention for Comment process in boilerplate.


Pete incorporated into his editing draft.   Contrbution 1.01G


4.3      Action 060104-3 (Tom Rutt) completed


Tom: action to have a complete proposal for soap must understand attribute text in document.


Sent to list as:

·  Detailed proposal for SOAP must understand text.
From Tom Rutt <tom@coastin.com> on
1 Jun 2004 23:54:23 -0000


4.4      Action 060104-4 (Iwasa) completed


Action: Iwasa should apply the editorial changes, and the agreed changes from the 6/1 meeting motions.


·  Groups - WS-Reliability-2004-06-03.pdf uploaded
From kiwasa@jp.fujitsu.com on
3 Jun 2004 14:37:03 -0000


4.5      Action 060104-5 (Jacques) Pending


Action: Jacques, will propose further edits, on the FAQ for composability.



5         Discussion of Issues and editorial Comments

The following issues list includes one open item which need further discussion:


· ·  Updated public comments issues list posted
From Tom Rutt <tom@coastin.com> on
4 Jun 2004 00:45:00 -0000


5.1      Namespace for Schema, and location


·  Re: [wsrm] Action Item status as of 6/3/04
From Sunil Kunisetty <sunil.kunisetty@oracle.com> on
4 Jun 2004 05:44:50 -0000

·  Groups - ws-reliability-1.1.xsd uploaded
From Sunil.Kunisetty@oracle.com on
7 Jun 2004 19:06:11 -0000

·  Groups - reference-1.1.xsd uploaded
From Sunil.Kunisetty@oracle.com on
7 Jun 2004 19:05:59 -0000

·  Groups - fnp-1.1.xsd uploaded
From Sunil.Kunisetty@oracle.com on
7 Jun 2004 19:05:43 -0000

·  Groups - wsrmfp-1.1.xsd uploaded
From Sunil.Kunisetty@oracle.com on
7 Jun 2004 19:05:29 -0000


I haven't heard anything from the OASIS Technical Services Manager w.r.t. mapping URIs to Files inspite of
 couple of reminders. He may be vacation.

 So in the spirit of making progress and wrapping up work, here is a proposal based on some discussions
 this tuesday:

·          The namespaces have ".xsd"  in them to make them easily referencible without any mappings.

·         Namespaces follow both MM/YYYY convention in the URI and also the version no. of the specification as suffix to the file name.


 Schema Namespace

 File name






 Schemas for the WSRM Elements




 Has the schema for ServiceRefType




 Schema for F,P, and all Compositor constructs




 Schema for WSRM Features and Properties

 PS: Should the version nos. for reference, fnp, and wsrmfp be 1.1 or 1.0 ?

 If there are no major objections, I'll upload a 'draft' version of these schemas before the next con. call
 so that we can vote on these  on that call.



There was no room for the fourth column.  There is a description about the schema in the schema itself.


Tom: changes applied to 1.01F, all filenames have 1.1 in their name.


Sunil moved to accept namespace proposal, as implemented in 1.01F, Iwasa seconded.


No opposition, motion passes.


After voting we need to send the schemas to the web master.


For the submission we will put into a zip file.


5.2      Editorial comments on Draft 1.01

5.2.1      Tom Rutt Comments


·  Detailed Editorial Fixes for Sections 1 - 4 of ED 1.01
From Tom Rutt <tom@coastin.com> on
5 Jun 2004 19:58:05 -0000

Editorial Changes:


For PN18: Fix the namespace used for the ws reliability schema in lines

(138, 494, 524, 708, 744, 821, 849, 932, 998, 1014


Line 82

Rationale: Middleware is an example of service provider

Proposal: insert “e.g.,” after “(“


Line 104

Rationale: “the an”

Proposal: remove “an”


Line 140

Rationale: xpath notation is used

Proposal: 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.


Line 231

Rationale: Since the term “publish reply” , and “publish fault” is used

in many

places in the document, this definition needs to be retained, but fixed

as follows

Proposal: :

Reply Publishing:

A party is said to publish an RM-reply when the RM-reply is made

available to its destination, in accordance with the RM-Reply pattern

requested by the Sending RMP. For example, if the callback reply pattern is

requested, publishing the reply requires sending a callback message

including the

RM-reply information. If the poll reply pattern is requested, publishing

the reply

requires making the RM-Reply information available to be returned to the


in response to a poll request.


Doug B concerned about this edit.

Reply Publishing:

Reply Publishing:

A party is said to publish an RM-reply when the RM-reply is made

available to its destination, in accordance with the RM-Reply pattern

requested by the Sending RMP. For example, if the callback reply pattern is

requested, publishing the reply requires sending a callback message

including the RM-reply information. If the poll reply pattern is requested, publishing the reply requires making the RM-Reply information available to be returned to the sender in response to a poll request.


Doug: if we changed this to an abstract operation I would be much more comfortable.  We have Notify on sender side with submit, but there is no Publish operation on the Receiving side.  My suggestion would be to use wording similar to operation definition.


Jacques: I am all for finding a better expression.  The Rationale for concept of publishing reply is that every time we had to mention that the receiver had to generate an ack or a fault, we used the term “sending back fault  This only made sense with response and callback reply patterns.  For polling the receiver had to wait for the callback request.


Doug: I would like it to be an abstract operation on the RMP.  It is easy to read it as being ambiguous.  (making available or sending it back).  We need to be concrete.  I cannot connect reply publishing with our use of word reply throughout the spec.



An abstract operation making an rm-reply available to its destination.


For the various rm-reply patterns this entails:

·        response reply : publishing the reply requires sending the rm-reply on the response of the underlying transport protocol.

·        callback reply pattern: publishing the reply requires sending a callback message including the RM-reply information.

·        poll reply pattern: publishing the reply requires making the RM-Reply information available to be returned to the sender in response to a poll request


No opposition to this edit. Will include in next editing draft



Line 319 – GroupExpiryTime table entry

Rationale: non null positive value does not go with date/time

Proposal: delete “A non-nul positive value”


Line 543 – groupId table entry

Rationale: the detail reference to 3.1.1 is wrong. It is not needed

Proposal: delete “*See 3.1.1 for details”


Line 546

Rationale: typo

Proposal: change “iidentifies” to “identifies”


Line 557

Rationale: grammar , semantics (plural) apply

Proposal: change “applies” to “apply”


Lines 678, 763, 882, 903

Rationale: page break causes first line of table to repeat in continuation

Proposal: remove designation of first line as table header


Note: this is not done in editing draft 1.01E


Line 729

Rationale: typo

Proposal: change “as” to “has”


Line 777

Rationale: there is no range in this case

Proposal: change “message range” to “group”


Line 778-781

Rationale: grammar and consistency with preceding paragraph

Proposal: change paragraph to:

“When the RefToMessageIds element has a groupId attribute and

SequenceNumRange element(s), the Receiving RMP MUST return RM-Repies for

the non-expired messages specified by the combination of groupId of

RefToMessageIds and SequenceNumRange element(s), that were either

delivered or faulted.”


Lines 882 and 895 – Value table entry

Rationale: RFC2396 is not the value of the element

Proposal: Replace “RFC2396” with “None”



Line 961 thru 965

Rationale: The last edit erroneously made a change which limited the

cases of applicability of the soap fault to just header problems


Delete “of” in line 961

Insert after line 962 “or other ws-reliability protocol related causes

(such as elimination of duplicate delivery), ”

Delete “that contains the RM fault“


Doug Concern on this edit:

Doug does not remember extensive use of ws-reliability protocol wording in existing text. 


Edit in question is as follows

In case of a Response RM-Reply Pattern was required, and when the message

cannot be delivered to the Consumer due to a failure in processing the RM headers,

or other ws-reliability protocol related causes (such as elimination of duplicate

delivery), 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.


Jacques: this is the case where we need a soap fault and an RM fault indication.  We cannot say RM-reply contains the soap fault.


Doug: I would just


In case a response rm reply pattern is required, and the message cannot be delivered to

the Consumer, then a soap fault must be delivered in addition to the rm-reply.


Doug: apparently our rmp does not know what the WSDL is.


It is not an error to get a duplicate invocation.


Doug: I would put nothing in the soap body in this situation.  It does not know what the WSDL MEP is, there is no difference in stuffing in a queue, or sending it along directly to the app.  Our protocol is designed only to support one way messages.  No matter what happens when a message is sent the sender has to get the same message back.


Deliver means make available to application. We cannot support request response MEPs from an applicaton perspective. 


Receving rmp to consumer interface does not allow the consumer to tell the receiving rmp anything.


Suggest to leave it empty, let the receiver deal with it.


End to end throughout this spec, an incoming message either does or does not get delivered to consumer.


Jacques: as long as soap body is well formed, this might be enough.  The reason to send soap fault, was to deal with some implementations of request response pattern.



In case a response rm reply pattern is required, and the message cannot be delivered to

the Consumer, then the rm-reply MUST be sent in the soap header, with an empty soap body.


Jacques: would soap stacks behave well when getting an empty soap body.  We could get rid of soap faults altogether.


Doug: I think we are having a number of overlapping conversations.  We agree that the existing spec does not support request response mep.  The body is always going to be empty when using ws-reliability.  


Doug:  there is no response from the deliver operation, it is an anonymous queue.  This is my concern.  There is no way for the consumer to deliver a response to the RMP.


Jacques: there are two ways the rmp can generate a response, either the rmp generates its own response with empty soap body when it cannot deliver the message.  The RMP is able to wait for a response from application side, but this is outside the scope of our RMP specification and contract.  Nothing stops an RMP from getting the Response.


Doug: This is a different abstract model, the RMP in our model is between the producer and consumer.    What I am worried about is that when using the resonse rm-reply pattern, one rmp sends a message to another, the receiver goes off thru a back channel gets payload and includes in response, the original rmp can blow up.  We have an interoperability problem.


If we say that the response rm-reply pattern is composible only with one way MEPs that would cover things.


Doug: there is no way that people implementing duplicate elimination will look here.


WSDL 1.1, http response to wsdl one way has no soap body.


Doug we do not support request response mep, for we have no way to get information back.  


Sunil for the second part it is not an issue.  For Oneway wsdl response pattern is not supported.


Tom: this leads to a limitation of response rm-reply pattern to a wsdl request response operation type with no response message defined in the wsdl.


Jacques: all that is asked of receiver rmp is to be able to add its own header in the response from the application.  This is the only thing that is required to support the response reply pattern.  We need to state this more clearly, that it has to be able to correlate a response with a request.


Doug: then we would need a new deliver response operation, which would be a new one from that in our spec.  We are missing a response submit operation in our model.


Jacques: let me rephrase: with request response, not tied to transport request response.   Maybe we have a problem with having to deal with BP 1.0 compliance.   Formally it would take a submit response to model the deliver of the response to the receiving rmp from the consumer.    Is is not a big stretch to require that the RMP must be able to correlate a request with a response, since current implementations allow that.  We might not have to change the abstract model, if we add this requirement. 


Only require the rmp to correlate a response with an underlying request message.


Jacques; Can do this as a Soap Node.


Doug: people implementing duplicate elimination will not be looking at section 4.5.  


Jacques updated suggestion could work, however I would like to see what it means not to make any use of soap faults.


Doug: Section: 4.5 could be fixed by stating that an empty body would be returned when the request is not delivered.


There are other things we have touched on: 


  • Receiver response in request rmp


  • Handling of a duplicate message -  needs to be also stated as not a fault situation  Needs to be stated in a section not about faults.


  • How to describe bundling soap fault with rm fault in response rm reply pattern.



Tom: could use empty body instead of Soap fault..


Jacques: I talked with Hamid: if request response if you only send back empty soap body, there could be mishandling on the sender side.  It is expecting conformance to signature or soap Fault.


Doug:  for question of cannot deliver in response reply operation. 


Hamid: The behaviour of an empty body depends on implementation of soap stack. Other stacks might get a higher level failure.


Sunil I prefer a fault to an empty soap body.  It could be dangerous.


Hamid: for one way it is ok to send empty soap body, for request response he needs to send a soap fault.


Tom: the receiving RMP knows the reply pattern.


Tom: Doug has raised a new technical Issue. 


Sunil: I had sent some earlier options on this.


Tom: this will take more than 15 minutes to resolve.


Jacques: there might not be  a lot of text changes, in the end.  The handling of Soap

Faults is related to our concern of implementation handling our Spec.


Jacques we need to get back to our development expert.


July 15th.


Jeff M: it would be nice to resolve this quickly.


Small Team to sheperd some text


Doug Concern:


Meeting next Monday 2:30 to 4:30 to try to resolve this issue.


Doug: I will send out a proposal for the text in section 4.5.  I do not understand Jacques comments enough to have any way to phrase his proposal of correlation into words.


Doug: The dup elimination and faulting problem I am not sure how we are leaning.


Hamid: have each company try a request response scenario, and have RMP send empty soap.


Jacques: this decision is linked to implementation aspects., if we can get away with it we may not use soap faults at all.




Action: Doug will propose text for  in 4.5 to clarify that when you cannot deliver due to rm fault, then send back a soap fault,


There is a separate issue for how to sneak around our abstract model to handle response correlation.  .


Third discussion is how to relate this to behaviour for duplicate elimination. 


Jacques took an  action to describe the response reply pattern to work with our abstract model to sneak around to allow response correlation, and how it can be used for duplicate elimination.  He will initiate discussion today.


Jacques; an extreme solution would be to eliminate the response reply pattern.



·  Editorial changes for Sections 5 onward to Draft 1.01
From Tom Rutt <tom@coastin.com> on
5 Jun 2004 21:05:46 -0000

Editorial Changes:


For PN18: Fix the namespace used for the ws reliability schema in lines

(138, 494, 524, 708, 744, 821, 849, 932, 998, 1014, 1293, 1324, 1366,

1405, 1452, 1473, 1514, 1535



Line 1113

Rationale: plurality

Proposal: change “time” to “times”


Line 1256

Rationale: typo

Proposal: insert space after Section


Line 1270

Rationale: the third sentence is redundant.

Proposal: Delete third sentence of para.


Lines 1273, 1339, 1421

Rationale: other causes can require this behavour

Proposal: change

due to a failure in processing the RM headers” to

due to a ws-reliability protocol related cause”


Doug B: I want to keep the 1.01 text.


Tom:s  concern.   Whatever we agree on earlier discussion of on secton 4.5 should be could reflect here.  


Some discussion on semantics of  due to a failure of processing rm header” 


Tom : this sounds like it only applies to our subset of rm faults for Rm-headers.   It might be read to exclude the messaging processing faults.


Doug: I read it as including all RM-faults, they all occur while processing rm request header.



For now, it was agreed to not accept this edit, and to take it out for the next editing draft.




Lines 1341,

Rationale: incorrect statement of requirement

Proposal: change

no SOAP Fault MUST be returned” to

a SOAP Fault MUST NOT be returned”




Related to discussion above. 



Tom: All changes applied to editing drafts 1.01E and 1.01F


Doug had comments, the changes

5.2.2      Jacques Durand Comments


·  Re: [wsrm] editorial comments on 101
From Tom Rutt <tom@coastin.com> on
8 Jun 2004 04:09:51 -0000

I  incorporated all of Jacques edits into contribution 1.01F, with my

own edit on the following text,  proposed for the introduction paragraph

to Table 26:


"This specification supports Reliable Messaging capabilities for WSDL

1.1 [WSDL 1.1] One-way and Request-response operation types only. While

a Request-Reponse operation can use any of the three RM-Reply patterns

to receive acknowledgments or faults, a One-way operation SHOULD (for

WS-I BP 1.0 conformance) only use either Callback or Poll RM-Reply

pattern. Table 26 indicates recommended usage of reply patterns, for twe

WSDL operaton typed. An RMP MUST, at leat, support the recommended

combinations in Table 26, for the reply patterns it supports. However,

an RMP is not requried to disinguish WSDL operation types."


Jacques Durand wrote:


> Editorial changes suggested below:

> ("Table 26" is the most significant change I suggest)


> Jacques


> ---------------------------------------------------------------------------------



> L68: is not --> are not


> L171:

> "information" is too vague: need at least to say it is part of

> the message:

> "subset of message data that is intended for the consumer..."


> L180: "when invoked, the operation..." -->

> "when invoked on a Receiving RMP, the operation..."


> L214, L218, L222:

> Proposed better wording:

> "The XXXX RM-Reply pattern is used if the..."

> -->

> "When the XXXX RM-Reply pattern is in use, the..."


> L222: "..a second" --> "..a separate"


> L246: "e.g., For..." --> "e.g. for..."


> L383: Appendix A --> Appendix B


> Figure 6:

> - the annotations "soap:envelope" and "soap:header" are missing

> on the right half.

> - the comment (L452) should tell more:

> "Fig 6 shows the structure... in the SOAP Envelope, for two samples of

> messages.

> On the left side of the figure, a Reliable Message is characterized by

> the presence of

> the wsrm:Request element. On the right side, a response to a Reliable

> Message

> contains a wsrm:Response element. Both wsrm:Request and wsrm:Response

> elements may be

> found in the same message."


> Table 26:

> "Support matrix", "Supported" are not the appropriate terms:

> This table is more about Usage than Capability, but currently mixes

> both notions,

> with capability ("supported") and usage ("disallowed").

> It should tell users what reply patterns should be used with what

> operation type.

> It is not about the capability of an RMP, which can in fact support

> the "disallowed"

> case as well, as mentioned in the notes, since the RMP is not required

> to distinguish

> teh operation types.

> I suggest to introduce the table as *recommended* usage of <reply

> pattern / op type>:

> L1218: "...One-Way operations can only use.." --> "...One-Way

> operations should only use.."

> Table: replace "Supported" by "Yes", and "Disallowed" by "No" in the

> table.

> L1219: Introduce table as:

> "Table 26 indicates the recommended usage of reply patterns, depending

> on the WSDL operation type. An RMP is REQUIRED to support at least all

> recommended combinations,


> although an RMP is not required to distinguish the operation types."



> L1227:

> better wording: replace:

> "The Receiving RMP can do whatever..."

> with:

> "The Receiving RMP may determine its behavior entirely based on

> message header content,

> regardless of the WSDL definition."







Changes applied to Editing draft 1.01F

5.2.3      Mark Peel Comments

Email from Mark Peel:

Some proofreading corrections: the line numbers are from the 06-04

document.  I didn't have time to proof the whole document.  If you don't

feel these are appropriate, I don't mind if you omit them.


Mark Peel

Web Services Infrastructure

Novell, Inc.



134:  Erroneous capitalization

in Table 1, replace "E.g" with "e.g."


150:  Typo

appears to contain a doublespace after the comma


228: Improper usage (e.g. is used to join parenthetical material within

a sentence)

replace "E.g.,  The" with "For example, the"


244: Erroneous capitalization

"For" should be "for"


344: omit needless word

change "and to not support" into "and not support"  -- omits "to",

which adds nothing to meaning.


328: use a form consistent with definition

"Group scope.  All" to "Group scope: all"


328: use a form consistent with definition

"Message scope.  A" to "Message scope: a"


348:  Confusing phrase

", that is a parameter affecting the entire group"  -- I don't know

what this clause means.  Does it intend to explain why GroupExpiryTime

can change dynamically?  It doesn't do a good job of it.  I suggest

striking this clause and putting a period after GroupExpiryTime.


401:  typo

appears to contain a doublespace in "the  resending"


498: Inconsistent capitalization

change "Schema" to "schema" to conform to previous line.


498-499: Wordy sentence construction

"If there are additional elements that are not described in this

specification present in message,"

Better as "If a message contains additional elements not described in

this specification,"


546: Inconsistent capitalization

"@GroupId" should change to "@groupId", making it consistent with the

other attribute descriptions that follow.


606: typo

"incremented of 1" should be "incremented by 1"


629: Erroneous capitalization

"Note: Given" to "Note: given"


629-630: unclear sentence construction

"in case Duplicate Elimination is required, when a received message is


Better "when a received message requiring Duplicate Elimination is



673: Improper usage (e.g. is used to join parenthetical material within

a sentence)

"E.g., If" to "For example, if"


691: typo

"things," to "things" -- there's no balancing comma to the one

following "things" and we can omit it.


693: series not properly punctuated

"element)" should really be "element)," -- but most written English

seems to omit that comma these days, so I don't insist on adding it



759:  omitted article

"by reference-schema" to "by the reference-schema" -- adds back "the"

into the sentence


764: omitted article

"of ReplyTo" to "of the ReplyTo"


765: omitted article

"with URI" to "with a value of type URI"


783:  consistent usage

"groupId attribute" to "@groupId attribute", a change required twice on

this line.  This is consistent with earlier sections describing



801: typo

"ispecifies" to "specifies"


805: change passive voice to active voice, reduce wordy phrase

"which is polling" to "asking"


837:  change passive voice to active voice

"is using" to "uses"


837:  awkward sentence construction (too many parenthetical clauses

joined by commas)

", if" to " and"


861: omitted article

"Response" to "The Response"


866:  typo

"case ," to "case," -- there's an extra space between "case" and the



867:  omitted article

"without sequence" to "without a sequence"


872:  consistent usage

"from and to" to "@from and @to"


877:  consistent usage

"groupID attribute" to "@groupId attribute"


885:  consistent usage

"groupID attribute" to "@groupId attribute"


877:  consistent usage, improper punctuation

"groupId attribute," to "@groupId attribute" -- also remove a

superfluous comma after "attribute".


895:  consistent usage

"groupId attribute" to "@groupId attribute"


917-918:  typo

917 ends with "numb" and 918 begins "er", suggesting a space snuck into

the word "number".


918:  typo

extra spaces between "15" and "for"


958:  excess word

"case of a" to "case a" -- omit "of"


958:  Clumsy construction

"In case of a Response RM-Reply Pattern was required, and when the

message cannot"

Better: "When a Response RM-Reply Pattern was required and the message



965:  Clumsy construction

"In case a Callback or Poll RM-Reply Pattern was required, and when the


Better:  "When a Callback or Poll RM-Reply Pattern was required and the



1938: typo

change "conditions" to "contributions"



Tom: All comments except the one on Line 629 was applied to editing draft 1.01F.  Full sentence is allowed to be introduced by Note: prefix in specifications.



Doug: I do not see the need for the word attribute if you are adding @foo and get rid of attribute.


Tom agreed to apply this in the next editing draft..

5.2.4      Tony Graham Comments


·  Re: [wsrm] 1.1-1.02 editorial
From Tom Rutt <tom@coastin.com> on
8 Jun 2004 13:55:32 -0000

I will put the following changed sentence in the next edting contribution:



However, it is allowed to dynamically change the value of

GroupExpiryTime or GroupMaxIdleDuration, pertaining to a group.






Tony Graham wrote:


>Lines 347-348 include:


>   However, it is allowed to change dynamically the value of some

>   group-level items such as GroupExpiryTime, that is a parameter

>   affecting the entire group.


>The spec should list the parameters that may be changed.  "Some" is

>too vague.


>(And change "change dynamically" to "dynamically change".)





>Tony Graham



Tom: Change applied to draft 1.01F


5.2.5      Pete Wenzil edits on 1.01F


Email from Pete Wenzil:

Tom, here are a couple more small edits (line numbers against 1.01F):


19-22: Replace comment instructions (see attached email).

Bottom Margin: Remove center tab-stop and extra tab from first line of

  footer; then the date will be right-justified properly, rather than

  on a new line.

29+: Table of Contents page numbering is off; remember to update it

  after switching change-tracking display on or off each time.

17: Figure 6 is out of alignment; double click on the

  wsrm:SequenceReplies and wsrm:ReplyRange frames to bring up

  properties, then "ok", and they will snap back to the right size.

  Move cardinality legend up a few lines so it all stays on the same

  page and eliminates the following blank page.  Maybe link together

  all the individual frames to lock everything in place?

240, 1233: Duplicate period.





6         Discussion of Document Progression.


Tentative Schedule:


June 9 – Draft 1.01H  :Tom will post a new document backing out the things not agreed from these minutes.


June  11 – proposals from email discussions agreed in principle


June 14 – Monday TC telecom, with potential CD and Submission Vote.  Agreed to be 5:30 to 7:30 PM Eastern Time, on Monday.


June 15 – submission sent to OASIS Staff


Tom: we need the “member experience” statements to be sent before the 15th , to be cited in the submission sent in on the 15th of Jun.


Jeff: I am confused about the Hitachi statement for Using the spec.  What statement can we make.  The statement requires IPR things.


Bob F: that is wording from the boilerplate.  Several companies have used this.


1         Potential Vote for CD progression


Postponed to Monday Jun 14 meeting




2         Potential Vote for OASIS Submission for Member vote of CD


Postponed to Monday June 14 meeting.

3         Frequently Asked Questions


Tom posted the following:


·  Approved FAQ set for WSRM TC
From Tom Rutt <tom@coastin.com> on 3 Jun 2004 13:57:21 -0000


No time to discuss.



Jeff M makes motion to adjourn Bob F seconded



No objection, meeting adjourned.



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