I think we need an issue to tie down the requirement for use of WSDL for
describing services using RM.
Tom Rutt
Goodner, Marc Andrue wrote:
> 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>>
>
>
> ------------------------------------------------------------------------
>
> <http://oasis-open.org/> OASIS Reliable Messaging TC
> <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm>
>
>
> OASIS Reliable Messaging TC Issues List
>
>
> Last update: 23 Apr 2003
>
> Issues regarding the documents produced by the OASIS Reliable Messaging
> TC <./#drafts> should be reported to
> <mailto:> (public archives
> <http://lists.oasis-open.org/archives/wsrm/>).
>
> Comments on this list should be sent to the
>
> <mailto:> mailing list (Archives
> <http://lists.oasis-open.org/archives/wsrm-comment/>).
>
> * Summary list of outstanding issues <#summaryList>
> * Detailed list of issues <#detailList>
> * Legend for detailed list <#legend>
>
>
> Summary List of Outstanding Issues
>
> id <#id> Status <#Status> Spec <#Spec> Topic <#Topic> Class <#Class>
> Section <#Section> Title <#Title>
> REL-1 <#xREL-1> Active Req feature Design Acceptance of initial
> requirements
> ED-1 <#xED-1> Active Dcouments Administrative Editorial Define document
> formats
> ED-2 <#xED-2> Active Issues Administrative Editorial Define fields for
> issue list
> REL-2 <#xREL-2> Unassigned Req feature Design Request/Response MEPs
> REL-7 <#xREL-7> Unassigned Req feature Design Backwards compatibility
> REL-9 <#xREL-9> Unassigned Req feature Design Pull model
> REL-10 <#xREL-10> Unassigned Req feature Design Attachment support
> REL-11 <#xREL-11> Unassigned Req feature Design Message ID and
> GroupID/SequenceNo
> REL-12 <#xREL-12> Unassigned Req feature Design Capabilities of
> Transport Protocol
> REL-4 <#xREL-4> Unassigned Req def Design Sync/Async definitions
> REL-5 <#xREL-5> Unassigned Req def Design Crash tolerance definition
> REL-6 <#xREL-6> Unassigned Req def Design Persistance definitions
> REL-8 <#xREL-8> Unassigned Req def Design Intermediaries clarification
> REL-3 <#xREL-3> Unassigned Req bind Design Non HTTP Bindings
>
>
> Detailed List of Issues
>
> id <#id> Spec <#Spec> Section <#Section> Topic <#Topic> Class <#Class>
> Status <#Status> Raised By <#Raised by> Owner <#Owner>
> *ED-1* Dcouments Administrative Editorial Active Marc Goodner
> <mailto:> Marc Goodner
> <mailto:>
> *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 <mailto:> 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
> <mailto:> Marc Goodner
> <mailto:>
> *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
> <mailto:> Szabolcs Payrits
> <mailto:>
> *Title:* Acceptance of initial requirements
> *Description:* This draft contains only 8 requirement points.
>
> [see email attachment]
> <http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200304/msg00059.html>
>
> *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
> <mailto:> <mailto:>
> *Title:* Request/Response MEPs
> *Description:* The WS-RM spec v1.0 currently includes only the one-way
> message pattern.
>
> [see email]
> <http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200304/msg00057.html>
>
> *Proposal:*
> *Resolution:*
> *REL-3* Req bind Design Unassigned Alan J. Weissberger
> <mailto:> <mailto:>
> *Title:* Non HTTP Bindings
> *Description:* HTTP bindings is OK. What about non-HTTP one way bindings?
>
> [see email]
> <http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200304/msg00057.html>
>
> *Proposal:*
> *Resolution:*
> *REL-4* Req def Design Unassigned Alan J. Weissberger
> <mailto:> <mailto:>
> *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]
> <http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200304/msg00057.html>
>
> *Proposal:*
> *Resolution:*
> *REL-5* Req def Design Unassigned Alan J. Weissberger
> <mailto:> <mailto:>
> *Title:* Crash tolerance definition
> *Description:* Crash tolerance needs to be unambiguosly defined.[see
> email]
> <http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200304/msg00057.html>
>
> *Proposal:*
> *Resolution:*
> *REL-6* Req def Design Unassigned Alan J. Weissberger
> <mailto:> <mailto:>
> *Title:* Persistance definitions
> *Description:* Persitant storage and persistant message need to be
> clearly defined.[see email]
> <http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200304/msg00057.html>
>
> *Proposal:*
> *Resolution:*
> *REL-7* Req feature Design Unassigned Alan J. Weissberger
> <mailto:> <mailto:>
> *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]
> <http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200304/msg00057.html>
>
> *Proposal:*
> *Resolution:*
> *REL-8* Req def Design Unassigned Alan J. Weissberger
> <mailto:> <mailto:>
> *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]
> <http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200304/msg00057.html>
>
> *Proposal:*
> *Resolution:*
> *REL-9* Req feature Design Unassigned Iwasa
> <mailto:> <mailto:>
> *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]
> <http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200304/msg00058.html>
>
> *Proposal:*
> *Resolution:*
> *REL-10* Req feature Design Unassigned Iwasa
> <mailto:> <mailto:>
> *Title:* Attachment support
> *Description:* Must be able to use attachments, MIME or
> WS-Attachments.[see email]
> <http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200304/msg00058.html>
>
> *Proposal:*
> *Resolution:*
> *REL-11* Req feature Design Unassigned Doug Bunting
> <mailto:> <mailto:>
> *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
> <mailto:> <mailto:>
> *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. <mailto:>
>
--
----------------------------------------------------
Tom Rutt email: ;
Tel: +1 732 801 5744 Fax: +1 732 774 5133
