[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Proposed Resolution for Rel22
Dock, The original reason for the issue on the list was our reference to 2119 (optional to implement) terminology versus our use of "optional" and a few other words in the "can zero copies of this element / attribute appear in a valid (compliant) WS-Reliability message?" sense. In that light, Iwasa is recommending a way to avoid the problem -- specifically, never using 2119 terminology except within the conformance section. You seem to be going a step further and recommending a particular approach to conformance. Is that correct? If so, your proposal actually relates to issue REL-29 and merits further discussion. I suspect the conformance section will end up saying more than "do the whole specification". At least, the various definitions for crash tolerance and persistence imply we will have more to day. Deployment patterns (for example, intended for use where inbound HTTP requests are not allowed) may imply conformance patterns... thanx, doug On 29-Aug-03 12:41, Dock Allen wrote: > Maybe a revisit of why something might be optional: > > 1-save bandwidth (not very much value here) > > 2-backward compatibility > > 3-sideways compatibility (with implementations that don't support WSRM) > > 4-allow implementations to only support some of the features > > I think we're after 2 and 3. Meaning that a non-supporting implementation will ignore the parameters on input, and will not provide them on output. > > This means that 4 would be implied, but I argue against that. If you permit implementors to only support part of the specification, it becomes pretty complicated for the user > (what if you are using an implementation that only supports ordering and you are talking to an implementation that only supports duplicate removal?) I don't see any benefit > (from an interoperability point of view) for subsets, and they add complexity to the overall community, as well as making life really difficult for users who have mult-platform > applications and vendors who need to write applications that can exist in multiple environments. So I would recommend that either you do the whole spec, or none of it. > > My two cents worth > > Dock Allen > > > > iwasa wrote: > > >>Here is a proposed resolution for Rel22: >> >>-- >>REL-22 Spec meta Editorial Unassigned Tom Rutt >>Title: Optionality >>Description: The use of the term OPTIONAL needs to be >>revisited particularly in a specification of this nature where >>interoperability is an explicit goal and RFC 2119 has been >>referenced. [see original spec] >>Proposal: Go to email on this issue >>-- >> >>Proposed Resolution: >>We inlude Conformance section in the spec. >>The word "OPTIONAL " in the spec means >>the element or attribute is optional to be in a message. >>But it doesn't say anything about optionality >>for implementation. >>Comformance section should mention about >>the optionality for implementation. >>-- >> >>Any comments? >> >>Thanks, >> >>Iwasa >> >>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php. > > > > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php. > -- SunNetwork 2003 Conference and Pavilion "An unparalleled event in network computing! Make the net work for you!" WHEN: September 16-18, 2003 WHERE: Moscone Center, San Francisco For more information or to register for the conference, please visit: http://www.sun.com/sunnetwork
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]