Fw: [wsrp-markup] [wsrp][markup] Conf Call Agenda

URL encoding is left up to the entity. It should also be the responsibility of the entity to decode any possible client parameters. The issue was raised that some server side APIs (IIS for example) always perform a URL decode of parameters. Some consumer implmentations may find it a hassle to pass un-decoded params to the producer. We need to decide if the consumer should always pass back the same url encoded parameter, and to prohibit the consumer from decoding them.

[Jane Dynin] Let's assume for the moment that the consumer is prohibited from decoding the parameters, it does not decode them and then re-encode them. Consider the following scenario:

Producer creates an URL that has some parameters, which include Japanese characters. Producer returns the data to the consumer, and decides to return everything in the Shift-JIS (Japanese) codepage, and thus the parameters are encoded in Shift-JIS.

Consumer is doing the URL rewriting. Also, for matters of simplicity, consumer only wants to talk UTF-8 to the producer. All XML parsers must support UTF-8, so it's a logical choice for the consumer to use UTF-8. Now, it must send a request to the producer that contains those parameters. What does the consumer do? There are several options:

1. We could prohibit this situation from happenning by allowing only ASCII characters in parameters.

2. We could say that the consumer-producer interaction has to happen in UTF-8.

3. Consumer could figure out what encoding the producer was using, somehow store it, and transcode the parameters from Shift-JIS to UTF-8.

I think it would be much simplier if we chose option 2, at least for the 1.0 WSRP spec. There are lots of weird internationalization issues that can creep up, and establishing that all communication between the producer and the consumer has to happen in UTF-8 will definitely simplify matters. In addition, there is no extra burden for the portlet writers since XML has built-in support for UTF-8. UTF-8 is also compatible with lower ASCII -- files and strings which contain only 7-bit ASCII characters have the same encoding under both ASCII and UTF-8.

Action Item: Investigate if it is possible to retrieve un-decoded parameters using IIS. This is definately doable in Servlet 2.2 and greater.

[Jane Dynin] This is also doable in IIS. I tested IIS 5.0. Using the QUERY_STRING server environment variable in the ServerVariables collection gave me the raw, unparsed, undecoded querystring. Here's a link to the relevant documentation: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iisref/html/psdk/asp/vbob5vsj.asp

We will leave caching of resources up to the http protocol. There is no need to provide our own semantic of resource caching.

[Jane Dynin] I later realized the problem with this: SOAP uses HTTP Posts, and according to the HTTP spec (RFC 2616, section 13.10), if you're using a POST, you will have to revalidate an entry. This means that you can't use the expiration model (Expires headers) HTTP caching, but you can use the validation model (ETag) caching. If you're using plain HTTP (GET), then you can use both expiration and validation model caching.

Need to add a URL attribute, such as wsia:rerwriteResource, to indicate to the consumer wheather or not a specific resource should be parsed for rewriting. Most resources will not require rewriting (images, pdfs, etc.) so by default the consumer will not rewrite a resource unless explicetly told to do so by the producer entity by using the wsia:rerwriteResource attribute within the resource URL.

[Jane Dynin] Here is a question to the group: how do you access a resource that's binary (image, pdf)? Do you use SOAP or plain HTTP GET? How do you send preferences to that resource? There are plenty of use cases where there is a need to send preferences to get back binary data from the producer. For example, consider an email portlet that allows viewing of attachments -- to access the attachment, which is binary data, the portlet needs to get the username and password of the user or some other token identifying the user for security purposes.

wsrp-markup message