Re: DR305 -- ongoing discussion

David,

The revision, IMHO, has gone a bit too far in that it has 
abstracted out all the useful detail for judging whether 
we have met this requirement (when we get down to doing XP 
itself).  Sort of like saying I want a restaurant with good 
food without defining "good food" or giving examples of what 
(I think) is good food -- a steak might fill the bill for 
one person, whereas another fancies fresh cod (I sort of like 
fried grasshoppers, once in a while ;-)

Sorry I wasn't in Redmond due to a conflict.

Best regards,
Henry
-------------------------------------------
At 04:57 PM 12/29/2000 -0500, David Ezell wrote:
>By vote of the Working Group in Redmond during the December 13-14 
>face to face meeting,  I've been asked to revise the wording of
>DR305.
>
>=== From the 2000-12-19 XP Requirements WD:
>
>>DR305 (Absorbs old DRs: DR003) Ednote: Under consideration. Owner: David
Ezell
>> 
>>The XML protocol must provide facilities that encourage a common approach for

>>providing features such as  authentication, encryption,payment, reliable
>delivery, 
>>sessions and transactions. Such facilities might include optional 
>>standardized header and/or trailer elements. These facilities should 
>encourage 
>>"best-practice" in implementing the required features.
>
>=== Proposed revision:
>
>>R305 
>>
>>In order to encourage a consistent approach for developing features which are
>>out of scope for the XP specification itself, the XML Protocol Specification
>>must provide facilities and enumerate favored ways of applying those 
>facilities
>>in support of such features.
>>
>>Examples of features which are out of scope but for which consistent design
>>will undoubtedly be beneficial are 1) message authentication and encryption 
>>(perhaps using SMIME, SSL, or digital signatures), 2) sessions and 
>transactions
>
>>(possibly by providing globally unique identifiers for messages), and
>>3) service definition and discovery.
>>
>>SOAP 1.1 facilities such as the "Header" element and the "encodingStyle",
>>"mustUnderstand", and "actor" attributes are examples of the kinds of 
>>support facilities and use patterns addressed in this requirement.
>
>=== Rationale:
>
>Note that the first sentence is the actual requirement.
>
>Item "c" in the following list of specific comments as well as the need to 
>include older DRs led to a rephrasing of the requirement (as opposed to a 
>gentler rework).  
>
>Specific comments from the f2f:
>
>a-- "facilities might..." ought to be "facilities should".
>b-- The term "implementing" is problematic.
>c-- Suggesting possible outcomes for this requirement might help clarify it.
>d-- "payment" should not be included in the list of features.
>
>Other observations:
>
>The spirit of DR305 is that the WG (through the XP specification) should
>acknowledge
>that certain classes of features will be required for a large number of XP
>applications,
>and that even though the design of these features is out of scope for this WG,
>everyone
>would benefit from some guidance on "best-practice" in creating these
features.
>Some
>other DRs were removed from the requirements document with the understanding
>that
>their mention in DR305 would be an adequate capture of their essence.  These
>include
>the following:
>
>DR046
>>xml protocol should work well with popular security mechanisms. 
>>Popular ones are smime/ssl/digital signatures.
>
>DR051 
>>A message must have a globally unique identifier. 
>
>DR065 
>>Must not preclude transaction support, discovery of service definitions and
>security.
>
>Thanks,
>David Ezell 
>
>
>

Received on Tuesday, 2 January 2001 16:20:28 UTC