Re: Dispositions

[Don Flinn <flinn@alum.mit.edu>]

Frank

Thank you for your PDs.

And yes, unfortunately this process is bureaucratic, but we have 190
issues and counting.  Consequently, we need to control the process to
let the full TC decide on what the document should be.  Remember we are
to document the will of the TC.  With 90 members and 90 issues the
permutations could be ... whew.  Democracy is tough.

I'm open to any suggestions to improve the process.

Don 


On Wed, 2005-06-08 at 10:49 -0700, Francis McCabe wrote:
> Don
> 
> I apologize in advance for this.
> 
> I am not really a spreadsheet hacker. So I am sending you my proposed  
> dispositions in this email by text (there are many many comments)
> 
> Frank
> 
> P.S. Am I the only one who is finding this process a bit  
> bureaucratic? Esp. after the freewheeling first draft?
> 
> ============================
> Issue #7-26 -- definition of policy
> 
> 
> 
> Line: 461.
> 
> 
> I believed that the definition of policy that I outlined was the one  
> that was agreed to in the F2F.
> 
> I certainly agree that we should be consistent!
> 
> Issue #7-28 Contract life-cycle
> 
> I agree, a little more needs to be written here. However,  I am not  
> sure that we should be in the business of defining contract life-cycles.
> 
> A diagram might be helpful of course.
> 
> How about the following:
> 
> To replace lines 506-508
> 
> The negotiation phase of a contract is the period when the parties to  
> the potential contract discuss the agreement to be entered into. This  
> may be vestigial, as for example, in the case of a service whose  
> contracts are published in a service description and the only option  
> for a user of the service is to agree to the published description or  
> not use the service. In principle, a contract negotiation phase may  
> also involve extensive communication and adjustments to various  
> parameters.
> 
> The negotiation phase of a contract is terminated by some action on  
> both parties that signals that they agree to the contract. This  
> action may be implicit -- as in a service consumer's first request  
> message to the service -- or it may be explicit with an explicit  
> *agree* and *acknowledgment* communication from the various parties.
> 
> After line 515
> 
> The completion of a contract marks a period in which the obligations  
> of the parties have been fully discharged; i.e., no new agreements or  
> obligations are warranted by the agreed-to contract. For example, in  
> a typical purchase-deliver contract, the contract requires the  
> provider to deliver the product and the purchaser to supply funds to  
> meet the purchase. After both parties have met those obligations,  
> there may be no additional obligations (such as to provide further  
> product or further funds) arising from the contract.
> 
> In general, the completion of a contract may not be easily  
> delineated. Many contracts have long-term obligations on one or more  
> of the parties; for example, if the goods supplied turn out to be  
> defective then there may still be obligations on the supplier.
> 
> For most service interactions, where the contracts are less legal and  
> more technical, the obligations under the contract are likely to be  
> expressed in terms of security techniques used, Quality of Service  
> levels, specific data models applying to message exchanges and so on.  
> In such a case, once a service interaction is completed, the  
> obligations to follow pre-defined choreography, for example, becomes  
> moot -- a new service exchange may well require a different  
> choreography.
> 
> Issue #7-29 types of contract
> 
> 
> 
> I do not agree that we need to go into a lot of detail about the  
> types of contract. In any case, the service description is a kind of  
> contract, and it follows from the previous paragraph.
> 
> 
> 
> Not sure why implied definition of service interface is inconsistent  
> with others.
> 
> 
> 
> Issue #7-30 service context
> 
> 
> 
> Agree that it needs more work. Not at all sure about basing it on  
> transaction context -- although that is an example of a context.
> 
> 
> 
> Issue #7-31 action boundary
> 
> Defend the term to the death
> 
> 
> 
> Issue #7-32 service context
> 
> 
> 
> Will add something on context in intro to semantics
> 
> 
> 
> Issue #7-33 & 34 service purpose
> 
> 
> 
> Will add a figure and try to clarify
> 
> 
> 
> Issue #7-35 shared expectations
> 
> 
> 
> Will add more to the intro. E.g. something based on
> 
> 
> 
> The semantics of a service involve a shared understanding by the  
> service consumer of information that describes multiple aspects of a  
> service that has been provided by the service provider, and  
> potentially previous service consumers as well
> 
> 
> 
> 
> 
> Issue #7-36 service semantics
> 
> 
> 
> Good suggestion, will move text.
> 
> 
> 
> Issue #37, multiple metadata
> 
> 
> 
> Yes, we should agree on a single definition
> 
> 
> 
> Issue #38 metadata and documentation
> 
> 
> 
> Will clarify. However, I contend that documentation *is* metadata --  
> metadata intended for human processing
> 
> 
> 
> Issue #39 uses of metadata
> 
> agree that more could be added. Not sure that much more is needed
> 
> 
> 
> Issue #40 limits to semantics
> 
> 
> 
> This is a critical truth. Agree to expand further
> 
> 
> 
> Issue #41 vocabulary
> 
> 
> 
> Vocabulary is part of the semantics. However, perhaps its profile  
> should be enhanced by moving it forward. Deserves its own section  
> really.
> 
> 
> 
> Issue #42
> 
> Vocabulary section should be greatly expanded on.
> 
> 
> 
> Issue #43
> 
> Agreed
> 
> 
> 
> Issue #44
> 
> Autonomy should be moved to the initial section on services. It was  
> here as a marker
> 
> 
> 
> Issue #45
> 
> Designing for something to be possible does not make it mandatory
> 
> 
> 
> Issue #46
> 
> Rename agreed. Have already proposed a rewording
> 
> 
> 
> Issue #101
> 
> Agreed. Who will do this?
> 
> 
> 
> Issue #104
> 
> Agreed.
> 
> 
> 
> Issue #105
> 
> More on context is needed. Not clear about proposed set of facts  
> however. There is context, and there is the description of context --  
> different animals.
> 
> 
> 
> Issue #137
> 
> Disagree with emphasis on communication. Propose to ignore this.
> 
> 
> 
> Issue #138
> 
> 
> 
> Partially agree with this wording:
> 
> 
> 
> Policy: A statement of a service offer together with obligations,  
> constraints or other conditions of use of a given service, and  
> encapsulated as part of a service description. When a specific set of  
> entities accept such a policy, a contract is usually  
> established.                 Contract: The syntactic, semantic and  
> logical constraints governing the use of a service and thus  
> reflecting a service's policies
> 
> However, would prefer
> 
> Policy: A statement of the obligations, constraints or other  
> conditions of use of a given service. Policies are often encapsulated  
> as part of a service description.
> 
> Contract: A contract is established with a specific set of entities  
> accept a policy.
> 
> Issue #156 Use too loose
> 
> Agreed.
> 
> Issue #157 Context
> 
> Agreed.
> 
> Issue #158
> 
> Agreed. Sort of. The "sentence" is a noun phrase, intended as a title.
> 
> Issue #159
> Similar
> 
> Issue #160 Ownership domain.
> 
> Needs a definition. Agreed. Perhaps for the glossary?
> 
> Issue #161 Content
> is correct, not context. Refers to the content of communication
> 
> Issue #184
> We are talking about the layers of semantics, not the layers of service.
> 
> Issue #185
> Bullets -- agreed.
> 
> Issue #186
> Agreed.
> 
> 
> 
> 
-- 
Don Flinn
President, Flint Security LLC
Tel: 781-856-7230
Fax: 781-631-7693
e-mail: flinn@alum.mit.edu
http://flintsecurity.com