OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[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]