Re: [wsrp-wsia] Issues for next several calls

[Rich Thompson <richt2@us.ibm.com>]

Sorry for the delay in getting this out ... I had a hard drive failure 
after our call on Thursday and am just coming back online with a new one. 
Expect updates to this schedule based on the progress we make in the calls 
(and any new issues) .....

Of the issues currently open, I propose we address them with this 
schedule:

Call on 12/19:
   #186: Specify the "SHOULD tokens" for the defaultTemplate

   #171:  Expand "Typical Process Flow" and remove "Example scenarios"

   #172:  Remove section "Interaction Lifecycle states"

   #173:  Add summary of interfaces in beginning of interface chapters
           => I think a summary chapter between 3 (last intro section) and 
4 (first interface section) could work well

   #179:  requestParameter semantics unclear
    (Does resolution impact tentative resolution of #165? => Consumer must 
strip the prefix it supplied for namespacing)

   #177:  locale MAY be based on end-user settings and not SHOULD

   #180:  <base> tag should be "other tags" and not to "disallowed" tag

   #184: Can performInteraction return new navigationalState?

   #178:  The Consumer SHOULD NOT use a MODE not specified in meta- data

   #176:  Simplify Producer by allowing it to return all locales re 
gardless of "desiredLocales"

   #187: How does POST data reach the Producer?

   #170: Scope of Producer-Consumer HTTP session



Call on 1/2:
   #185: Remove concept of Roles from the spec

   #174:  The Consumer SHOULD NOT assert a role for a role which th e 
Producer does not have
            => proposal:  add verbiage to the effect that the Consumer 
MUST NOT assert a role the Producer has not said it supports. The Producer 
SHOULD be prepared to receive a role it does not currently support as it 
may have existed in a previous service description. The Consumer is not 
required to get a current snapshot all the time, but must abide by the 
snapshot it has.

    #175:  Roles should be per-Entity and not per-Producer

    #181: registration changes
          - proposal is: Drop the registration API so that registration is 
always out of band and do not pass any additional data. Whatever the 
Producer actually needs can be acquired/modified through its out-of-band 
system. 



Call on 1/7:
    #169: Does refresh page (F5/Ctrl+R) re-invoke 
performBlockingInteraction?

    #183:  markup charset different or the same as the XML response 
charset?



Call on 1/9:
    #182:  Globalize the Address Type/User Information fields and Postal 
Code is missing.
           => This is delayed to here because I am trying to pull together 
a table comparing the internalization specs and what we now have



Rich Thompson