1. redirectURLs URI-escaping
    • Original Comment: http://lists.oasis-open.org/archives/wsrp-interop/200711/msg00000.html

    • Summary: Does the rewrite result of a wsrp_rewrite expression in redirectURLs need to be URI-escaped? Another question which arises: the rewrite expression is a URL value, therefor it needs to be URL escaped. Consumers must not expect the redirect URL to contain directly parseable rewrite expressions.

    • Proposal:

      1. URI-escape the rewrite result. This is required since the redirectURL obviously needs to be a valid URL.
      2. Consumers should be prepared to handle both cases similar to XML escaping in rewrite tokens in the markup. This means a redirectURL being an already valid URI with escaped rewrite expression within a URL parameter value, and the redirectURL string being interpreted as a plain string with not yet escaped rewrite expression becoming a valid URL after rewriting. This gives Producers the largest flexibility on mechanisms they use to generate the redirectURL string, either directly within the portlet or using frameworks returning already valid URLs with URI escaped parameter values.
    • Resolution: Accept above proposal. Do not change the spec since the current interpretation of the redirectURL field and the symmetry to URL rewriting in markup seems sufficient to cover the proposed resolution.

  2. portlet cookies transport
    • Original Comment: http://lists.oasis-open.org/archives/wsrp-interop/200803/msg00001.html

    • Summary: Where need cookies set by portlets / returned to portlets need to flow? Within the protocol structure ClientAttributes or at the HTTP transport level?

    • Proposal: Tie portlet cookies to the transport level similar to Producer managed cookies as a plain HTTP state mechanism. Cookies should be transferred and managed at the transport level. This is already covered by the specification since 1.0 and does not introduce any need for a spec change. Discussions also clarified that Producers (thus portlets) can return cookies with any response on the markup interface. The only "special handling" applies to "scoped cookies" defined by the init cookie protocol and returned with initCookie() response. Here the Consumer manages cookies in a scoped manner as specified in section 4.1.20. Portlet cookies or any cookies returned outside of initCookie() are not scoped or namespaced.

    • Resolution: Accept above proposal. No changes required to spec, errata or other documents.

  3. getPortletProperties - mapping of qnames to names string array
    • Original Comment: http://lists.oasis-open.org/archives/wsrp-interop/200803/msg00001.html

    • Summary: the PropertyDescription type declares property identifiers (names) being of type xsd:QName. However the getPortletProperties() operation takes a names array as a first class citizen parameter of type xsd:string maxOccurs="unbounded". A mapping of the types is needed.

    • Proposal: 4 options are discussed on the ML:

      1. use java Qname as String notation as used e.g. in JSR286
      2. use local part only
      3. use XML notation
      4. define well known extension
    • Resolution: The most interoperable and compatible with future versions is option 2. The solution is a follows:

      • Producers
        1. generate a PropertyDescription for portlet properties (and this is only necessary for those) with an empty namespace URI ("") and a local part

        2. Producers which expose portlets / backends which indeed use Qnames for their portlet properties need to encode those Qnames to fit into the local part of PropertDescription.qname only. Since PortletProperties are private to the portlet/producer, the encoding of an eventual Qname to a string is opaque to the Consumer and is a Producer choice.

        3. Producers need to make sure that the encoded results contain valid values for the local part of a Qname as defined in the W3C Namespace 1.0 recommendation.

        4. upon receiving a getProperty(.., names) operation, Producers which have choosen to encode the local part need to decode the names' values with the algorithm chosen in 3..

      • Consumers
        1. Consumers pass only the local parts of PropertDescription.Qname in the getProperty(.., names) operation as a String value.

        2. Consumers should ignore the namespace URI from PropertyDescription.QName

        3. the encoding of the local part is opaque to the Consumer. Consumer must forward the value unchanged.
  4. Double encoding of {params}:
    1. {wsrp-url}
    2. {wsrp-navigationalValues}
  5. How to rewrite binary
    1. Use 8859-1 by default
    2. Errata?
    3. Primer
  6. How can the consumer track current mode and window state when the producer return empty ""
    1. Options:
      1. Extension: New {params} for current mode and state
      2. Resend templates when mode/state change
    2. Errata?
    3. Primer
  7. WSRP 1.0: Is navigational state tied to mode
    • Should be independent of mode
  8. WSRP 1.0: How should producers deal with non spec {params}
    • CS 216 (1.0 errata)
    • Primer - Non TC Extended params should not start "wsrp-"
  9. Primer Section on what {param} require double encoding
    1. wsrp-url
    2. wsrp-navigationalValues
  10. Should wsrp-secureURL's default value be based on the secureClientCommunication
    • No - URLs must be able to navigate in and out of secure pages
    • If another portlet switches to non-secure URL the navigational state may be sent unsecured
      • Primer
    • Extension to not-resend templates?
  11. XML parser may change line feed/carriage return
    1. Use itemBinary
    2. Use CDATA section -- needs testing (should preserve whitespace)
    3. primer?
    4. http://www.w3.org/TR/2004/REC-xml-20040204/#sec-line-ends

  12. XML character encoding vs. Mime Type charset
    1. Use itemString's character encoding as the XML's encoding <?xml version="1.0" charset="Shift_JIS"?>

    2. Use itemBinary and mimeType="text/plain; charset=Shift_JIS"
    3. Re-encode item string as UTF (java/.NET default) -- lose original encoding
    4. Primer?
  13. namespacePrefix format

    • Original Comment: The WSRP spec implies that the namespace prefix can be used for things like Javascript and tag ids. However, it does not specify any format (e.g. must start with letter or '_' followed by letters, digits and '_').

    • Summary: The current spec allows the namespacePrefix to have any value, however it should be constrained to widely usable values.

    • Proposal: In order to ensure usability of the prefix in various technologies (html, javascript, css, jsf, etc.). The value of the namespacePrefix MUST start with a US-ASCII letter [A-Za-z] followed by zero or more US-ASCII letters [A-Za-z] digits [0-9] and underscores [_]. [A-Za-z]([A-Za-z]|[0-9]|_)*

    • Resolution: Errata? Primer?

  14. Unable to set the response-code for getResource
    • Summary: Currently it is not possible to set the response-code (HTTP status) on resources fetched via getResource(). This is important as the response code may contain information useful to the client.

    • Proposals:

      1. Map Faults to various error codes (e.g OperationFailed - 500)

      2. Add a well known client attribute (e.g. wsrp:extra-HTTP-STATUS)
      3. Add a full extension
    • Resolution:

  15. template - use for adding new comments
    • Original Comment:

    • Summary:

    • Proposal:

    • Resolution:

  16. Event Payloads

  17. Property Values

WSRP_Interop_Discussions (last edited 2010-03-25 15:10:56 by nadernetunity)