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: Issues list - first cut

Title: Issues list - first cut

Attached is the first draft of the issues list. This format, numbering scheme and the source documents may change in discussions with other editors but I do believe that all of these issues are correct. I am going to work with the other editors to lock down these document issues and get an update with the source materials (it is generated from an XML file) posted to the member site which should then remain a stable point of reference. This should be done by early next week. Hopefully that will be enough lead time for everyone that we can then refer to this as a source for the next teleconference.

Right now we have 11 unassigned issues. If you have an issue not represented in this document please post to the list and it will be added for further discussion.

Marc g


Title: OASIS Reliable Messaging TC Issues List
OASIS OASIS Reliable Messaging TC

OASIS Reliable Messaging TC Issues List

Last update: 23 Apr 2003

Issues regarding the documents produced by the OASIS Reliable Messaging TC should be reported to wsrm@lists.oasis-open.org (public archives).

Comments on this list should be sent to the wsrm-comment@lists.oasis-open.org mailing list (Archives).

Summary List of Outstanding Issues

REL-1ActiveReqfeatureDesignAcceptance of initial requirements
ED-1ActiveDcoumentsAdministrativeEditorialDefine document formats
ED-2ActiveIssuesAdministrativeEditorialDefine fields for issue list
REL-2UnassignedReqfeatureDesignRequest/Response MEPs
REL-7UnassignedReqfeatureDesignBackwards compatibility
REL-9UnassignedReqfeatureDesignPull model
REL-10UnassignedReqfeatureDesignAttachment support
REL-11UnassignedReqfeatureDesignMessage ID and GroupID/SequenceNo
REL-12UnassignedReqfeatureDesignCapabilities of Transport Protocol
REL-4UnassignedReqdefDesignSync/Async definitions
REL-5UnassignedReqdefDesignCrash tolerance definition
REL-6UnassignedReqdefDesignPersistance definitions
REL-8UnassignedReqdefDesignIntermediaries clarification
REL-3UnassignedReqbindDesignNon HTTP Bindings

Detailed List of Issues

idSpecSectionTopicClassStatusRaised ByOwner
ED-1Dcouments AdministrativeEditorialActive Marc Goodner Marc Goodner
Title: Define document formats
Description: Initial documents have been edited as MS Word files and distributed as PDF to the group. Do we wish to continue this way or do we wish to use an alternate format?
Proposal: Doug proposed that we use Docbook for the documents and generate target distribution format (html, pdf etc.) for that and use XML in the W3C style for the issue list. Marc taking a first pass at this based on Szabolcs work so far.
ED-2Issues AdministrativeEditorialActive Marc Goodner Marc Goodner
Title: Define fields for issue list
Description: Field codes need to be defined (at least intially) for use in the issue list for locus, section, priority, topic and status. Additionally a numbering convention needs to be defined for use issue numbers.
Proposal: Use as much of what was already defined in the html xsl transform (doh!), added some additional keys

Locus (Spec heading): Spec, Req, Issues

Section: relevant to doc

Priority (Class heading): Design, Editorial

Topic: use cases, feature, soap, bind(ing), fault, meta(issue), def(initions), admin(istrative)

Status: Unassigned, Active, Closed, Postponed

Issue Numbers: ED-n (Editor admin topics), REL-n (reliability specific), SOAP-n, WSDL-n, HTTP-n

REL-1Req featureDesignActive Szabolcs Payrits Szabolcs Payrits
Title: Acceptance of initial requirements
Description: This draft contains only 8 requirement points.

[see email attachment]

Proposal: I propose to vote about these points either as a whole or point-by-point.
REL-2Req featureDesignUnassigned Alan J. Weissberger
Title: Request/Response MEPs
Description: The WS-RM spec v1.0 currently includes only the one-way message pattern.

[see email]

REL-3Req bindDesignUnassigned Alan J. Weissberger
Title: Non HTTP Bindings
Description: HTTP bindings is OK. What about non-HTTP one way bindings?

[see email]

REL-4Req defDesignUnassigned Alan J. Weissberger
Title: Sync/Async definitions
Description: We need to unambiguously define "synchronous" and "asynchronous" before we can agree on these two different bindings. (From last meeting: discussion needed, proposals should be made at face to face.)

[see email]

REL-5Req defDesignUnassigned Alan J. Weissberger
Title: Crash tolerance definition
Description: Crash tolerance needs to be unambiguosly defined.[see email]
REL-6Req defDesignUnassigned Alan J. Weissberger
Title: Persistance definitions
Description: Persitant storage and persistant message need to be clearly defined.[see email]
REL-7Req featureDesignUnassigned Alan J. Weissberger
Title: Backwards compatibility
Description: Backwards compatibility with non WSRM nodes, fallback to standard SOAP? - How to identify these nodes - Implications on WSDL definitions[see email]
REL-8Req defDesignUnassigned Alan J. Weissberger
Title: Intermediaries clarification
Description: Are SOAP intermediaries store and forward entities that also implement WS-RM over SOAP? Or are they strictly SOAP entities that are unaware of WS-RM? Are SOAP intermediaries store and forward entities that also implement WS-RM over SOAP? Or are they strictly SOAP entities that are unaware of WS-RM?[see email]
REL-9Req featureDesignUnassigned Iwasa
Title: Pull model
Description: Usefull in situations when a user can only intitiate an HTTP request, i.e. behind a firewall or using a limited (mobile) device.[see email]
REL-10Req featureDesignUnassigned Iwasa
Title: Attachment support
Description: Must be able to use attachments, MIME or WS-Attachments.[see email]
REL-11Req featureDesignUnassigned Doug Bunting
Title: Message ID and GroupID/SequenceNo
Description: From last meeting: Message ID is mandatory, removing it is problematic - TR Some people don't want to maintain both types of IDs, seems redundant. SequenceNo seems optimized for ordering which won't be used as often (via Doug B.)
Proposal: - Option 1 Use GroupID/SeqNo for all message ids - Option 2 Use MessageID for everything and use pointers (linked list) for ordering (Doug B. proposal) - Option 3 Keep it as it is
REL-12Req featureDesignUnassigned Tom Rutt
Title: Capabilities of Transport Protocol
Description: From last meeting: - TR example: 1. A persistent connection guarantees ordered delivery 2. A nonpersistent implementation does not guarantee ordered delivery

Details in meeting minutes (to be posted).


Table Legend

Issue number
Short title/name of the issue
Document referred to in issue (Req = Requirements, Spec = XMLP/SOAP Specification
Short description of issue, possibly including link to origin of issue
Reference to specification section that motivated this issue
Rough topic categorisation, one of: env(elope), rpc, enc(oding), meta(issue), bind(ing), fault
Design or Editorial
One of: Unassigned, Active, Closed, Postponed
Current proposal for resolution of issue, possibly including link to further text
Short description of resolution, possibly including link to a more elaborate description
Raised by
Person who raised the issue
Reliable Messaging TC Member responsible for the issue

Maintained by Doug Bunting.

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