[wsrp] WSRP TC Teleconference on June 19, 2003

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

I would note that we scheduled a teleconference
for next Thursday at the normal time in order to deal with the agenda items
we did not get to today. I would note that the more the errata items are
vetted on the email list, the easier it will be to deal with them on the
calls.

Rich Thompson

Rich Thompson/Watson/IBM@IBMUS 06/12/2003 01:55 PM

To:        wsrp@lists.oasis-open.org         cc:                 Subject:        [wsrp] Groups - WSRP TC Weekly Teleconference added

WSRP TC Weekly Teleconference has been added 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.  SC Status/Issues
  2.1  Interoperability (Richard)
  2.2  Conformance (Rich)
  2.3  Markup (Rex/Andre)
  2.4  WSDL (Andre)
  2.5  PFB (Alan)
  2.6  Coordination (Rich)
  2.7  Interfaces (Mike)

3. Outstanding errata issues:

  3.1   #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.


  3.2   #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.


  3.3   #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.


4.  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. 
  - 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.


5.  Primer: Need volunteers to edit/update current draft
    - SCs will need to assist preparing
relevant sections
    - Will be needed this fall as marketing
of the WSRP standard kicks off.


6.  Promotion of WSRP as a standard
   Ideas todate include:
    - Conferences (XML2003, others?)
    - Articles such as Eilon's last
year (Thomas, Carsten and Richard have written one for a German newspaper)
    - Reviews by companies such as
O'Reillys
    - OASIS promotion (Rich to contact
Carol Geyer)
    - Others?


7.  Should we require that our URL expression be encoded
such that it is valid for the mime type into which it is placed?



Date:  Thursday, 19 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=2273

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.



You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php