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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

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


Subject: RE: [xdi] Agenda: XDI TC Telecon Friday 9:00-10:00AM PT 2012-05-25


I propose a new agenda format as a way of sharpening our focus during the calls.

Today's agenda is rewritten to demonstrate the new format.

PROPOSED FORMAT FOR AGENDA

1) Presentations
    a) OX Open Source Project Update by Mike Schwartz / 5m
    b) X^2 Open Source Project Update by Markus Sabadello / 5m
    c) Unnamed Open Source Project Update by Phil Windley/Drummond Reed / 5m
    d) OASIS XDI Test Server Update by Markus Sabadello, Joseph Boyle, and Mike Schwartz / 5m
        Ref: http://wiki.oasis-open.org/xdi/IdTrustProposal
    e) Spec Repository Update by Bill Barnhill / 5m
    f) XDI Dictionary Update by Drummond Reed / 5m

2) Decision Point Queue for Future Discussion (queue review and poll for new items / 5m)
    a) Are any of the XDI querying proposals on the list or wiki acceptable to all?
    b) If so, which do we use going foward?
    c) Will that one stand on it's own, or are changes needed?

3) Decision Points Resolution (remaining time)
Note: I propose we take these in order and note a definitive resolution that is final pending no objection within two weeks, or until a concrete counter proposal is advanced and formally voted on.  An objection cannot be raised without a counter proposal, which becomes the highest priority decision point to resolve at the next meeting.  In other words it only takes consensus at a meeting with no objection over the following two weeks to finalize, but it takes a formal vote to change something once consensus is achieved and documented without objection.  I believe this is necessary going forward to keep charging on a steady course.

    a) Should the HTTP binding of XDI use an XDI enabled version of REST?
    b) If it does, should we also have a 2nd binding that is non-REST?
    c) Should we use a parameter to contain a message, or something else?
    d) Should we use headers to contain message, or message metadata for $GET, or something else? 
    e) Are any of the REST proposals sent to the mailing list this week acceptable to all?
    f) If so, which do we use going foward?
    g) Will that one stand on it's own, or are changes needed?

4) NEXT CALL


























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