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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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


Subject: RE: [ws-rx] Issue 59 Proposal, correction s/Jacobsen/Jacobson/


Bob:

 

-          terminology: use "message" instead of "request" (the only cases where "request message" is used in the doc, is for operations such as CreateSequence)

 

Beside this, +1

 

Jacques

 


From: Bob Freund-Hitachi [mailto:bob.freund@hitachisoftware.com]
Sent: Monday, November 07, 2005 1:54 PM
To: [WS-RX]
Subject: RE: [ws-rx] Issue 59 Proposal, correction s/Jacobsen/Jacobson/

 

Correction, spelling of RFC 1323 author's name

 


From: Bob Freund-Hitachi
Sent: Tuesday, November 08, 2005 6:44 AM
To: [WS-RX]
Subject: [ws-rx] Issue 59 Proposal

 

This proposal is relative to Web Services Reliable Messaging Committee Draft 01

 

Discussion:

Now that the committee has agreed to delete re-transmission parameters, the characteristic of re-transmission behavior is under described.  We propose to add text to the core specification that expands the exposition of re-transmission behavior somewhat as follows:

 

 

Insert after line 265:

 

2.5 Retransmission

The RM Source will expect to receive acknowledgements from the RM Destination during the course of a message exchange at occasions described in Section 3 below.  Should the acknowledgement not be received timely, the RM Source MUST re-transmit the request since either the request or the associated acknowledgement may have been lost.  Since the nature and dynamic characteristics of the underlying transport and potential intermediaries are unknown in the general case, the timing of re-transmissions cannot be specified. Additionally, over-aggressive re-transmissions have been demonstrated to cause transport or intermediary flooding which are counterproductive to the intention of providing a reliable message exchange.  Consequently, implementers are encouraged to utilize adaptive mechanisms that dynamically adjust re-transmission time and the back-off intervals that are appropriate to the nature of the transports and intermediaries envisioned.  For the case of TCP/IP transports, a mechanism similar to that described as RTTM in RFC 1323 [RTTM] should be considered.

 

Delete lines 951-952 reason: reference is not used; besides it is a book that may not remain in print

 

Insert before line 953:

[RTTM]

V Jacobson et alia, "RFC 1323 TCP/IP High Performance Extensions" 1992



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