Meeting started at 8:00 PDT
====================================================================
Roll Call
Voting Members:
---------------------------------
Alejandro
Abdelnur
Sun
yes
Sasha
Aickin
Plumtree
no
Subbu
Allamaraju
BEA
yes
Olin
Atkinson
Novell
yes
Atul
Batra
Sun
yes
Amir
Blich
SAP
no
Chris
Braun
Novell
yes
Rex
Brooks
Starbourne
yes
T.J.
Cox
Novell
no
William
Cox
BEA
yes
Brian
Dirking
Stellent
yes
Michael
Freedman
Oracle
yes
Ross
Fubini
Plumtree
no
Noah
Guyot
Vignette
yes
Richard
Jacob
IBM
yes
Jon
Klein
Reed-Elsevier
no
Andre
Kramer
Citrix
yes
Alan
Kropp
Vignette
yes
Carsten
Leue
IBM
no
Dan
Machak
Tibco
no
Nigel
Ratcliffe
Factiva
no
Thomas
Schaeck
IBM
no
Steven
Smith Capitol
College no
Yossi
Tamari SAP
yes
Rich
Thompson
IBM
yes
Charles
Wiecha
IBM
yes
Total voting
members: 26
Voting members in attendance: 16
(62%)
A quorum was present.
Members on Leave Of Absence
----------------------------
Sunit
Randhawa
Fujitsu
LOA
Joe
Rudnicki U.S.
Navy
LOA
Eric van
Lydegraf Kinzan
LOA
Prospective Members (non-voting):
---------------------------------
Winston
Damarillo GlueCode
Software no
Metin Ergener Vignette no
David
Holladay
Microsoft
yes
Dimitri Jirov SAP
yes
David Raphael Ericsson no
WSIA Members (non-voting):
-----------------------------
Ravi
Konuru
IBM
no
Bruce Lucas
IBM no
Graeme Riddell Bowstreet no
1. Accepted
previous minutes
2.
JavaOne: Bill Cox ran a BOF on
JSR168/WSRP that was well-received.
About 50 participants, many of whom were hearing details about WSRP for
the first time.
3. Subcommittee
reports:
·
Interop: Oracle Producer and Consumer now available.
·
Markup: Discussing CSS issues raised by Nicolas
Prade (via Dan Machak) of Tibco.
See Nicolas’ email on the list.
Want to ready clarified CSS definitions by Autumn for inclusion in the
Primer.
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.
- 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.
Mike F:
Needs further investigation..
Rich:
If Producer mime is xhtml, the fragment needs to be valid. Goes for any
mime type. (Intermediates, Consumers).
Alej:
But the embedded URL's are invalid...fragments containing them are never valid.
Yossi:
Wrong for an intermediary to treat markup as other than cdata? Example:
markup + CSS. Intermediaries should not rely on the mime type.
Rich:
Create some errata: requirement on Consumer, recommended behavior on
behalf of others.
Alej:
How does this affect Consumer rewriting?
Rich:
Unencoded & in xhtml is invalid (URL template).
5. Outstanding
errata issues:
#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:
Andre:
Already have the url-type namespace for the Consumer to prefix producer tokens
Chris:
pretty unwieldy to do use the rewrite template.
Subbu:
Conceptually, rewriting and prefixing are different.
Andre:
Complicates consumer rewriting because it has to know ahead of time what the
prefix is before receiving the markup.
Alej: Just
uses a well-known token to prefix, then Consumer would have to rewrite it.
Alan:
Again, complicates Consumer rewriting.
Rich:
Would rather have the Producer do the prefixing itself.
Rex:
Leave this to experience?
Alan:
Think we need a solution now.
Rich:
To email discussion. 2 main
questions: #1) constant token that does not force consumer
parsing? #2) make namespace prefix required help?
Meeting ended at 9:00 PDT