WSRP 2.0 issue: Need to foramlize receiving/responding client metadata on in-protocol getResource

Though the WSRP 1.0 specification is mute on the subject (I believe)
the expected behavior of consumer based proxied http resources is that
client request meta data is propogated to the resource via http request
headers and client response meta data is propogated back via http
response headers.  I.e. the consumer acts as an http proxy by and large
passing thorugh the client request headers and returns in the client
response headers those it received in the resource response.

In WSRP 2.0 we added in protocol resource serving.  As the structure of
this call is based on the information passed in a regular GetMarkup
passing client request and response meta data is more muddled.  The
MimeRequest structure contains fields that correspond to the content
type, character set and locale of the resource request.  Though
unstated these are expected to come from the corresponding client
request headers.  In addition the clientData field passed in
MimeRequest contains the userAgent, request verb, and ccppHeaders. 
Again the expectation is these come from the client request headers. 
In MimeResponse there are corresponding fields to carry the content
type and locale of the response, caching information and ccpp profile
warnings.  Again the expectation is that the consumer ultimately
encodes these properly into the client response headers.

In WSRP 2.0 we have said (encouraged) Ajax developers to use our
in-protocol getResource to convey the ajax request.  We have been
hearing from some Ajax developers (JSF AJax impelmentations) that they
rely on encoding information about the partial rendering in the client
request headers.  To work these implementations need to be assured that
such headers are passed to the producer in a consistent, interoperable
way.  Though at the moment these developers haven't indicated a
reciprical reliance on the http response headers, its not hard to
imagine systems utlizing this mechanism to convey reponse meta data
back to itself so its client javascript can properly handle the
response.

To support this WSRP 2.0 needs to have a formal definition of how
client request meta data not already represented in specific fields in
the ResourceParams , MimeRequest, or ClientData structures are passed
and likewise how client response meta data not already represented in
specific fields in ResourceResponse, ResourceContext, or MimeResponse
are returned.

The solution is to define that both these extra request/response meta
data is carried in a NamedStringArray.  With the semantic in an http
client environment that there is one name/value per http header with
the name being the header name and the value being the header value
exlcuding those headers that are either overriden by the consumer or
reflected directly in the passed request data.  Likewise there is one
name/value pair for each additional piece of response meta data (other
then what is already reflected in the response data) where the name
becomes the http client response name and the value is value.

The primary question/issue is where to represent this NamedString
array(s).  There are a variety of options for requests all of which
rely on using a NamedStringArray:

  
Define a standard extension to be carried in the extension field
of the ClientData structure and require its use for getResource()

  
Add an additional field in the ClientData called XXX
(otherClientAttributes???) and require its use for getResource() (and
other operations?)

  

  
Define an additional field to ResourceParams called
resourceAttributes??? 

  

Likewise there are a variety of options for responses all of which rely
on using a NamedStringArray:

  
Define a standard extension to be carried in the extension field
of the MimeResponse structure and require its use for getResource()

  
Add an additional field in the MimeResponse called XXXX
(clientAttributes?) and require its use for getResource() (and other
operations?)

  
Define an additional field in ResourceResponse called
resourceAttributes???

  
Define a standard extension to be carried in the extensiuon field
of the ResourceResponse.

  

-Mike-