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.

Regards,

Marc g

 <<wsrm-reqm-issues.html>> 

Title: OASIS Reliable Messaging TC Issues List

			

				
				OASIS Reliable Messaging TC
			

		OASIS Reliable Messaging TC Issues ListLast update: 23 Apr 2003
Issues regarding the documents produced by
    the OASIS Reliable Messaging TC should be reported to  (public archives).
    

Comments on this list should be sent to the
    
    mailing list (Archives).
    

		

		
Summary list of outstanding issues

Detailed list of issues

Legend for detailed list
Summary List of Outstanding Issues
		
			
idStatusSpecTopicClassSectionTitle

			

				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.
		
				

				
Resolution: 
				

			

					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 
						

					
				

				
Resolution: 
				

			

					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.
		
				

				
Resolution: 
				

			

					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]
				

				
Proposal: 
				

				
Resolution: 
				

			

					REL-3Req
					bindDesignUnassigned
					Alan J. Weissberger
					
				

				
Title: Non HTTP Bindings
				

				
Description: 
			HTTP bindings is OK.  What about non-HTTP one way bindings?
[see email]
				

				
Proposal: 
				

				
Resolution: 
				

			

					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]
				

				
Proposal: 
				

				
Resolution: 
				

			

					REL-5Req
					defDesignUnassigned
					Alan J. Weissberger
					
				

				
Title: Crash tolerance definition
				

				
Description: 
			Crash tolerance needs to be unambiguosly defined.[see email]
				

				
Proposal: 
				

				
Resolution: 
				

			

					REL-6Req
					defDesignUnassigned
					Alan J. Weissberger
					
				

				
Title: Persistance definitions
				

				
Description: 
			Persitant storage and persistant message need to be clearly defined.[see email]
				

				
Proposal: 
				

				
Resolution: 
				

			

					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]
				

				
Proposal: 
				

				
Resolution: 
				

			

					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]
				

				
Proposal: 
				

				
Resolution: 
				

			

					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]
				

				
Proposal: 
				

				
Resolution: 
				

			

					REL-10Req
					featureDesignUnassigned
					Iwasa
					
				

				
Title: Attachment support
				

				
Description: 
		Must be able to use attachments, MIME or WS-Attachments.[see email]
				

				
Proposal: 
				

				
Resolution: 
				

			

					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
		
				

				
Resolution: 
				

			

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

				
Proposal: 
				

				
Resolution: 
				

			
		Table Legend
		idIssue numberTitleShort title/name of the issueSpecDocument referred to in issue (Req = Requirements, Spec = XMLP/SOAP SpecificationDescriptionShort description of issue, possibly including link to origin of issueSectionReference to specification section that motivated this issueTopicRough topic categorisation, one of: env(elope), rpc, enc(oding), meta(issue), bind(ing), faultClassDesign or EditorialStatusOne of: Unassigned, Active, Closed, PostponedProposalCurrent proposal for resolution of issue, possibly including link to further textResolutionShort description of resolution, possibly including link to a more elaborate descriptionRaised byPerson who raised the issueOwnerReliable Messaging TC Member responsible for the issue
		
		
	Maintained by Doug Bunting.