[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Groups - WSRP TC Conference Call modified
WSRP TC Conference Call has been modified by Rich Thompson (richt2@us.ibm.com).
Event description:
USA Toll Free Number: 877-718-0936
USA Toll Number: +1-712-923-6878
PARTICIPANT PASSCODE: 402957
Agenda:
1. Accept previous minutes
2. Outstanding errata issues:
2.1 #16. 5/9/03 (Andre Kramer)
Contact.telecom, Contact.online, Online.uri are not arrays in the IDL.
Should remove the maxOccurs="unbounded" from the WSDL.
Document: WSDL
Section: types
Action: Remove "maxOccurs" attribute from Contact/telecom, Contact/online, Online/uri
2.2 #17. 5/9/03 (Andre Kramer)
6.1.17 has UserProfile.bdate while ch 11 has bDate in table. Seems it should be bdate?
Document: Spec
Section: 11 (twice)
Old Text: bDate
New Text: bdate
2.3 #18. 5/19/03 (Rich Thompson)
Appendix E (Revision History) had value while the spec was being developed. I don't think it has value in the final spec.
Document: Spec
Section: Appendix E
Action: Delete this section.
2.4 #19. 5/13/03 (F2F)
Conformance statement for mode would be better in section 6.8. It should also be reworded for clarity to the portlet developer.
Document: Spec
Section: 6.1.12
Old Text: The Consumer MAY choose to respect this request to change the mode, but since the Portlet cannot depend on that choice it MUST NOT encode this new mode into any of its stateful settings. Rather, the Portlet MUST compute any such impact on stateful settings after the Consumer has actually changed the mode.
New Text: See section 6.8 relative to the processing of such requests.
Document: Spec
Section: 6.8
Old Text: Whether or not such a request is honored is up to the Consumer and often will depend on access control settings for the End-User.
New Text: The Consumer MUST respect requests to change the mode outside of exceptional circumstances (e.g. access control restrictions), but the Portlet must not depend on such a request being respected.
2.5 #20. 5/13/03 (F2F)
Conformance statement for window state would be better in section 6.9. It should also be reworded for clarity to the portlet developer.
Document: Spec
Section: 6.1.12
Old Text: The Consumer MAY choose to respect this request to change the window state, but since the Portlet cannot depend on that choice it MUST NOT encode this new window state into any of its stateful settings. Rather, the Portlet MUST compute any such impact on stateful settings after the Consumer has actually changed the window state.
New Text: See section 6.9 relative to the processing of such requests.
Document: Spec
Section: 6.9
Append to first paragraph: Portlets may request window state changes either through parameters on a link that an End-User activates or by returning a newWindowState in a BlockingInteractionResponse. The Consumer SHOULD choose to respect this request to change the window state, but since the Portlet cannot depend on that choice it MUST NOT encode this new window state into any of its stateful settings. Rather, the Portlet MUST compute any such impact on stateful settings after the Consumer has actually changed the window state
2.6 #21. 5/20/03 (Alejandro Abdelnur)
The namespacePrefix should be required as it may be used by the portlet to namespace things (ie: javascript thingies) within the generated content. This is independent from templating.
Document: Spec
Section: 6.1.2
Old Text: [O] string namespacePrefix
New Text: [R] string namespacePrefix
Document: WSDL
Section: wsrp_v1_types.xsd
Old Text:
New Text:
2.7 #22. 5/21/03 (Alejandro Abdelnur)
Spec doesn't really define the relationship between markup and title. Is title considered part of cache content? If yes, where does it say that in the spec? I see assertions like if MarkupContext.useCachedMarkup is true, then MarkupContext.markupString MUST be NULL. Why doesn't the spec say that MarkupContext.preferredTitle would be NULL too in this case.
Document: Spec
Section: 6.1.10
Old Text: If the value for useCachedMarkup is “true” the markupString and markupBinary fields MUST NOT be returned.
New Text: If the value for useCachedMarkup is “true” the markupString and markupBinary fields MUST NOT be returned. If the value for useCachedMarkup is “true” the preferredTitle field SHOULD NOT be returned and the previous preferredTitle value reused.
2.8 #23. 5/22/03 (Interoperability SC)
SOAP 1.2 is dropping the convention using ‘.’ as a delimiter within error codes. Suggest that WSRP does likewise and just uses leaf error code in a namespaced manner.
Document: Spec
Section: 13
Old Text: WSDL defines fault codes to be strings using “.” as a delimiter to scope the error codes. The following are defined for constructing a WSRP error code within the same namespace as used for the rest of the types defined by this specification:
New Text: The following WSRP error codes are defined within the same namespace as the rest of the types defined by this specification:
action: Drop “Top Level" column from table in section 13. Rename "Specific Code" column header to "Fault Code”.
action: Drop “Interface.” and “Security.” from fault codes throughout spec. Double check equivalent in WSDL.
2.9 #24. 5/22/03 (Interoperability SC)
What is the purpose of the "Fault" suffix on the fault type and element definitions. It adds confusion and is unneccesary.
Document: WSDL
action: Drop “Fault" suffix on the fault type and element definitions.
2.10 #25. 5/22/03 (Interoperability SC)
In order to make fault messages interoperable on current stacks, we suggest adding the following two conformance statements.
Document: Spec
Section: 13 - just before table3
New Text: The SOAP faultcode SHOULD be set to the WSRP error code being raised, namespace qualified to be in the "urn:oasis:names:tc:wsrp:v1:types" namespace. In addition, the SOAP fault's detail element MUST contain the corresponding namespaced fault element from the WSRP v1 WSDL as its only content.
3. Primer: Need volunteers to edit/update current draft
4. Promotion of WSRP as a standard
5. WSRP URI coding Issue (Andre originally brought to WSDL SC)
<summary>
WSRP 1.0 makes the assumption that URL encoding of wsrp-tokens on URIs is required and always safe.
RFC 1738 "...Only alphanumerics [0-9a-zA-Z], the special characters "$-_.+!*'()," [not including the quotes - ed], and reserved characters used for their reserved purposes may be used unencoded within a URL."
Not only does 1.0 rule out URI schemes that only allow these always safe characters (and use some other kind of encoding based on the above always safe set), for all or part of their values, but our 1.0 leads to implementation and usability problems with common Web Server stacks:
- consumer side Web servers will URL decode automatically.
- runs of '/' are interpreted as a single '/' path separator in URL paths.
- after URL decoding, some reserved as well as unreserved chars are problematic in some sub-parts of URLs.
- content authors will need to URL encode values they write into re-write expressions.
- re-write expressions are still not valid XML.
- templates are likely to be markup type dependent but 1.0 has no selection/specialization mechanism.
Testing has found that the following should be avoided for use in paths (the .../.../... in http://../.../.../...) with Microsoft ASP.NET based consumers:
%&'*:><
including the space char, as well as '/' and '' that commonly act as path separators.
The following are all fine in URL paths:
0123456789abcABC_-=?#,!£^(){}[]+`¬"+;|.,~$@
BinHex (http://www.w3.org/TR/xmlschema-2/#hexBinary) is a good way to make binary data safe.
Currently, HTML forms with method=GET can not be supported when using URL templates for .NET, and it remains to be seen what level of confusion and restrictions of use we have caused for WSRP developers.
</summary>
We (Citrix) are willing to live with these restrictions for 1.0 as long as the above short-comings are recognized and address in future versions of these specifications.
Real world portlets may want to add cryptographic checksums and encrypt state (navigationalState and interactionState) that they push out to consumers (and ultimately to Web browsers in many cases) so that they can't be attacked via unexpected input values. We would encourage use of binHex rather than URL encoding to convert from encrypted bytes or serialized binary data to URI characters.
6. SC Status/Issues
6.1 Interoperability (Richard)
6.2 Conformance (Rich)
6.3 WSDL (Andre)
6.4 PFB (Alan)
6.5 Markup (Rex/Andre)
6.6 Coordination (Rich)
6.7 Interfaces (Mike)
Date: Thursday, 05 June 2003
Time: 11:00am - 12:00pm Eastern Time
View event details:
http://www.oasis-open.org/apps/org/workgroup/wsrp/event.php?event_id=1658
PLEASE NOTE: If the above link does not work for you, your email
application may be breaking the link into two pieces. You may be able to
copy and paste the entire link address into the address field of your web
browser.
Referenced Items
Date Name Type
---- ---- ----
06 Jun 2003 wsrp-minutes-030605.htm Minutes
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]