[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Issues list - first cut
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 wsrm@lists.oasis-open.org > <mailto:wsrm-comment@lists.oasis-open.org> (public archives > <http://lists.oasis-open.org/archives/wsrm/>). > > Comments on this list should be sent to the > wsrm-comment@lists.oasis-open.org > <mailto:wsrm-comment@lists.oasis-open.org> 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.andrue.goodner@sap.com> Marc Goodner > <mailto:marc.andrue.goodner@sap.com> > *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:doug.bunting@Sun.com> 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.andrue.goodner@sap.com> Marc Goodner > <mailto:marc.andrue.goodner@sap.com> > *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@nokia.com> Szabolcs Payrits > <mailto:Szabolcs.Payrits@nokia.com> > *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:ajwdct@technologist.com> <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:ajwdct@technologist.com> <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:ajwdct@technologist.com> <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:ajwdct@technologist.com> <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:ajwdct@technologist.com> <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:ajwdct@technologist.com> <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:ajwdct@technologist.com> <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:kiwasa@jp.fujitsu.com> <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:kiwasa@jp.fujitsu.com> <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:doug.bunting@Sun.com> <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:tom@coastin.com> <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:doug.bunting@Sun.com> > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]