Issues list - first cut

["Goodner, Marc Andrue" <marc.andrue.goodner@sap.com>]

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.

Regards,
Marc g

<<wsrm-reqm-issues.html>>

Title: OASIS Reliable Messaging TC Issues List

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
• Detailed list of issues
• Legend for detailed list

Summary List of Outstanding Issues

id	Status	Spec	Topic	Class	Section	Title
REL-1	Active	Req	feature	Design		Acceptance of initial requirements
ED-1	Active	Dcouments	Administrative	Editorial		Define document formats
ED-2	Active	Issues	Administrative	Editorial		Define fields for issue list
REL-2	Unassigned	Req	feature	Design		Request/Response MEPs
REL-7	Unassigned	Req	feature	Design		Backwards compatibility
REL-9	Unassigned	Req	feature	Design		Pull model
REL-10	Unassigned	Req	feature	Design		Attachment support
REL-11	Unassigned	Req	feature	Design		Message ID and GroupID/SequenceNo
REL-12	Unassigned	Req	feature	Design		Capabilities of Transport Protocol
REL-4	Unassigned	Req	def	Design		Sync/Async definitions
REL-5	Unassigned	Req	def	Design		Crash tolerance definition
REL-6	Unassigned	Req	def	Design		Persistance definitions
REL-8	Unassigned	Req	def	Design		Intermediaries clarification
REL-3	Unassigned	Req	bind	Design		Non HTTP Bindings

Detailed List of Issues

id	Spec	Section	Topic	Class	Status	Raised By	Owner
ED-1	Dcouments		Administrative	Editorial	Active	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.
	Resolution:
ED-2	Issues		Administrative	Editorial	Active	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
	Resolution:
REL-1	Req		feature	Design	Active	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.
	Resolution:
REL-2	Req		feature	Design	Unassigned	Alan J. Weissberger
	Title: Request/Response MEPs
	Description: The WS-RM spec v1.0 currently includes only the one-way message pattern. [see email]
	Proposal:
	Resolution:
REL-3	Req		bind	Design	Unassigned	Alan J. Weissberger
	Title: Non HTTP Bindings
	Description: HTTP bindings is OK. What about non-HTTP one way bindings? [see email]
	Proposal:
	Resolution:
REL-4	Req		def	Design	Unassigned	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]
	Proposal:
	Resolution:
REL-5	Req		def	Design	Unassigned	Alan J. Weissberger
	Title: Crash tolerance definition
	Description: Crash tolerance needs to be unambiguosly defined.[see email]
	Proposal:
	Resolution:
REL-6	Req		def	Design	Unassigned	Alan J. Weissberger
	Title: Persistance definitions
	Description: Persitant storage and persistant message need to be clearly defined.[see email]
	Proposal:
	Resolution:
REL-7	Req		feature	Design	Unassigned	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]
	Proposal:
	Resolution:
REL-8	Req		def	Design	Unassigned	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]
	Proposal:
	Resolution:
REL-9	Req		feature	Design	Unassigned	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]
	Proposal:
	Resolution:
REL-10	Req		feature	Design	Unassigned	Iwasa
	Title: Attachment support
	Description: Must be able to use attachments, MIME or WS-Attachments.[see email]
	Proposal:
	Resolution:
REL-11	Req		feature	Design	Unassigned	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
	Resolution:
REL-12	Req		feature	Design	Unassigned	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).
	Proposal:
	Resolution:

Table Legend

id

Issue number

Title

Short title/name of the issue

Spec

Document referred to in issue (Req = Requirements, Spec = XMLP/SOAP Specification

Description

Short description of issue, possibly including link to origin of issue

Section

Reference to specification section that motivated this issue

Topic

Rough topic categorisation, one of: env(elope), rpc, enc(oding), meta(issue), bind(ing), fault

Class

Design or Editorial

Status

One of: Unassigned, Active, Closed, Postponed

Proposal

Current proposal for resolution of issue, possibly including link to further text

Resolution

Short description of resolution, possibly including link to a more elaborate description

Raised by

Person who raised the issue

Owner

Reliable Messaging TC Member responsible for the issue

---

Maintained by Doug Bunting.