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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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
   Security Services
   AuthN Protocols
   Protocol Bindings
   Enveloping vs. Enveloped
   AuthZ Use Case
   Business Requirements
   Domain Model
Design Issues
   Naming Subjects
   Naming Objects
   Assertion Validity
   Assertion Style
   Reference Other Assertions
   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

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 Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]