[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Ideas for issues list categories
Eve - I definitely agree with your new categories. These are in harmony with our current work. Thanks, Jahan --------- Jahan Moreh Chief Security Architect 310.286.3070 -----Original Message----- From: Eve L. Maler [mailto:firstname.lastname@example.org] Sent: Wednesday, October 01, 2003 10:33 AM To: 'email@example.com' Subject: [security-services] Ideas for issues list categories In this week's telecon, I agreed to propose a fresh set of categories for the issues list. In V1.0 and V1.1, we used the following categories for the issues list: Use Case Issues Document Format & Strategy Single Sign-on Push and Pull Variations B2B Scenario Variations Sessions Security Services AuthN Protocols Protocol Bindings Enveloping vs. Enveloped Intermediaries Privacy Framework AuthZ Use Case Encryption Business Requirements Domain Model Design Issues Naming Subjects Naming Objects Assertion Validity Assertion Style Reference Other Assertions Attributes Authentication Assertions Authorities and Domains Request Handling Assertion Binding Authorization Decision Assertions Attribute Assertions Dynamic Sessions General – Multiple Message Types Elements Expressing Time Instants Miscellaneous Issues Terminology Administrative Conformance XMLDSIG Bindings I suggest the following categories, which hew more closely to our agreed-on V2.0 deliverables: Technical Deliverables Technical Overview (OVER-nn) Assertions, Protocol, and Schemas (CORE-nn) Bindings and Profiles (BIND-nn) Metadata (META-nn) Other (TECH-nn) Outreach Deliverables (OUT-nn) Miscellaneous Issues (MISC-nn) Since we're unlikely to be in doubt as to the document in which an issue would be fixed, and relatively few issues will span documents, I think this should work as a good approximation. For issues that do span documents, we can just detail the desired results in the issue text, just as we always have. As an example, we would have the following issues so far: CORE-01: Remove AuthorityBinding element CORE-02: Remove RespondWith element CORE-03: Remove deprecated NameIdentifier URIs CORE-04: Require URI references to be absolute CORE-05: Null attribute values BIND-01: Disallow Status as only child of SOAP Body BIND-02: Remove deprecated artifact URI I'm inclined not to go any deeper than this because I'm not sure that the effort will result in corresponding gain in issue-disposition efficiency or accuracy, but am willing to be convinced otherwise. (I'm not all that thrilled with my ad hoc experiment to put related work items next to each other and give them "a" and "b" designations...) What do y'all think? If you agree with the top two(ish) levels I've proposed but would prefer to see another level, can you recommend some or do you think they should be created ad hoc? Eve -- Eve Maler +1 781 442 3190 Sun Microsystems cell +1 781 354 9441 Web Products, Technologies, and Standards eve.maler @ sun.com 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/security-services/members/leave _workgroup.php.