OASIS Web Services for Remote Portals (WSRP) TC

WSRP/WSIA Telecon 01/14/2003

Roll

No quorum reached.

Therefore discussion around the open issues.

#197
Clarification about the usage of the tokens.
Proposed resolution: add wsrp-SessionID, wsrp-portletInstanceKey and wsrp-userContextID

#194
Discussion about whether password should be in there. Andre pointed out that it might mean that credentials should be provided (somehow).
Richard stated that these should be left to the security TCs.
Agreement to not add password.
Mike asked why specify DIME and SOAPAttachments, these are defined by the bindings.
Andre that these are currently not supported by the stacks, therefore it might be helpful.
Mike: But we did say, that we use naming conventions for the bindings to indicate that.
General agreement.
Proposed resolution:
Add a non-normativ appendix if time allows, gather the list items by email.

#198
Proposed resolution: The concepts are orthogonal, thus a Portlet can claim to have no user specific state turn around but later clone_on_write.

#199
Proposed resolution:
1.) preferred title use is optional, consumer's choice to show or not to show things.
2.) preferred title must match the locale of the markup
3.) no just a string, as it is the dynamic title for the current markup

#191
Mike: did we consider markup to be binary in general?
Rich: it should be less expensive to send it as string.
Mike: splitting into two fields seems "ugly"
Rich: maps well to the stacks -> send binary data as attachments
Richard: this is only true for DIME, not for MIME attachments
Andre: it doesn't cost us on the wire, no additional information would be sent.
Richard: we would need additional semantics to state that both fields are mutual exclusive because <choice> is not supported by the stacks.
Proposed resolution: continue to investigate, discuss on Thursday

#200
Rich: binary OK for registrationState and portletState. Others might be Pushed to the client, therefore should remain strings
General Agreement.
Proposed resolution: change both fields to binary, leave the others strings

#201:
No one had strong reasons for changing the names as they don't really improve the understanding of the semantics.
Rich: need to make sure in the spec to make this clear.
Proposed resolution: no name change, clarify in the spec.

#202:
Bruce: it would be very convenient to have inline schema transport in that case. Why don't we define <any> to transport the schema?
General discussion about pros/cons.
Proposed resolution: schema inlining seems to be sufficient for a lot of cases. Maybe we should give it a try to transport via <any> inline.

#???/1
Proposed resolution: no objection to move

#???/2
Proposed resolution: element seems to be preferred.