WSRP Specification Work January Face-to-Face. Resolved Change Requests 1: Identifier 6: Delete Role from Glossary 9: Property Type reference 12: Missing

WSRP Specification Work

January Face-to-Face

Resolved Change Requests• 1: Identifier• 6: Delete Role from Glossary• 9: Property Type reference• 12: Missing ‘=’• 14: Insert ‘to’• 17: 4k = 4096• 18: H2 indentation• 19: Update WSIA membership list• 21: Repeated ‘User’ definition • 22: ‘HTML’ -> ‘XHTML’• 23: 12.18 indention• 24: clone-on-write enumerated values• 26: move InvalidUserCategories fault

Resolution to “Inconsistent ResourceList handling”

• Accept having ResourceList type fields only in directly returned structures:– Drop from PortletDescription and ModelDescription– Add structures PortletDescriptionResponse and

PortletPropertiesDescriptionResponse.

• Accept

Change Request #4• Spec / throughout

• Requested by: Rich Thompson

• Old text: "Producer Offered Portlet"

• Proposed text: "Producer Configured Portlet"

• Reasoning: I just noticed that this phasing is out of sync with the resolution to Issue #154. This change would eliminate this difference, though personally I prefer the current.

• Keep as is

Change Request #87• Spec / 1.2.2.1 / Page 10 / Line 6

• Requested by: Subbu Allamaraju

• Old text: ...2) unique within and scoped by the supplied registrationHandle

• Proposed text: ...2) unique within and scoped to the Consumer registration

• Reasoning: registrationHandle not introduced yet.

• Accept

Change Request #88• Spec / 1.2.3 / Page 10 / Line 23


• Old text: XForms represents a markup technology that can be leveraged to address these performance issues

• Proposed text: Client-side scripting and XForms are examples of technologies that can be leveraged to address these performance issues

• Reasoning: Required?

• Accept

1 of 2


• Requested by: Alejandro Abdelnur

• Proposed text: [append] Note that use of such technologies does not relieve the need for a Portlet to validate the input data it receives.

• Reasoning: Clarify that the use of technologies that push data validation closer to the user do not relieve the ultimate responsibility of the Portlet to do validation.

• Accept

2 of 2

Change Request #117• Spec / 1.2.4 / Page 10 / Line 30-40• Requested by: Sasha Aickin• Old text: [list of functions]• Proposed text: [delete]• Reasoning: This seems a bit early in the spec

to discuss the functions that will be called. Also, the section is for describing the End-User actor; I don't think this helps that goal.

• Accept … primer should consider the equivalent• Add description of what an End-User can do

without explicitly mentioning the operations. (Sasha to propose)

Change Request #71• Spec / 1.2.4 / Page 10 / Line 39• Requested by: Andre Kramer• Old text: • Proposed text: [insert] A Consumer SHOULD only

initiate one performBlockingInteraction or performInteraction at a time, on behalf of a User.

• Reasoning: Natural for a portal, but not clear this is always required (for non-blocking interactions).

• Not in this place for the spec … Andre will consider and propose where and what. (He did … for 6.3.2)

Change Request #89• Spec / 1.3 / Page 11 / Line 26


• Old text: Much as new relationships are formed, at times relationships end.

• Proposed text: Producers and Consumers may choose to end a registration relationship at any time.

• Reasoning: Too philosophical

• Accept

Change Request #90• Spec / 2 / Page 11 / Line 40-42• Requested by: Subbu Allamaraju• Old text: Note that many times providers use

"comply" to a standard to sidestep because they don't actually "conform" to a standard. Reasons they do not "conform" often include the standard is not approved yet or that the provider does ...

• Proposed text: [delete this sentence and the following sentence]

• Reasoning: Grammar• Accept

Change Request #118• Spec / 3 / Page 12 / Line 3

• Requested by: Sasha Aickin

• Old text: "leveraged"

• Proposed text: "leveraging"

• Reasoning: the tense is wrong.

• Accept



• Old text: SOAP - Defines how to invoke remote interfaces

• Proposed text: SOAP - Defines how to invoke web service interfaces

• Reasoning: Clarity

• Accept

Change Request #119• Spec / 3.2 / Page 13 / Line 6-8• Requested by: Sasha Aickin• Old text: "The textual portion of this specification...

<snip> ... to be conformant to this specification."• Proposed text: "The textual portion of this specification

does not contain normative statements regarding the exact syntax of XML passed between Consumer and Producer, but it does contain normative statements about the manner and order in which calls must be made in order to be conformant."

• Reasoning: To say that there are no normative statements about how actors need to interact seems wrong to me. The WSDL cannot, for example, mandate that we send back the sessionID.

• Accept



• Old text: "whenever such an item may be created"

• Proposed text: "when a transient item is created"

• Reasoning: I think it reads better. I got tripped up the first time I read the sentence.

• Accept … also drop parenthetical phrase

Change Request #121• Spec / 3.5 / Page 14 / Line 10• Requested by: Sasha Aickin• Old text: "is always encapsulated by the

Portlet's scope."• Proposed text: "is encapsulated by the Portlet's

scope, when one exists."• Reasoning: In the Portlet scope section, you

say that Portlet scope only happens for cloned Portlets, so the text as written implies that session scope cannot exist for Producer Offered Portlets. I don't believe this is the case.

• Rather, define “portlet scope” for a POP



• Old text: Because WSIA and WSRP are connectionless protocols ...

• Proposed text: Because the WSRP protocol operates over connectionless technologies

• Reasoning: Are there two such protocols? Where was this said. The same about connectionlessness.

• Accept

Change Request #29• Spec / 3.6 / Page 14 / Line 27• Requested by: Alejandro Abdelnur• Old text: "To supply the bookmarking capability End-

Users expect, the Consumer may store this state, or a reference to it, in the URL. The Consumer may also choose to not supply this functionality to its End-Users. "

• Proposed text: "To supply the bookmarking and page refresh capabilities End-Users expect, the Consumer MAY store this state, or a reference to it, in the URL."

• Reasoning: More explicit• Accept

Change Request #92• Spec / 3.7 & 6.7.2 / (15/12) & (45/2)


• Old text: ... (cookies or URL-rewriting) to push the navigational state or sessionID out to its client.

• Proposed text: ... (cookies or URL-rewriting) to propagate the navigational state or sessionID to its client

• Reasoning: Like it better.

• Accept



• Old text: [section 3.8]

• Proposed text: [delete]

• Reasoning: We just defined and discussed session state in 3.6, and the other types of state don't get their own section. I don't see that this section adds much to what's already been said in the spec.

• Accept



• Old text: Possible implementation choices include: ...[till the end of the list]


• Reasoning: There are other specs that address this. In the J2EE land, it is better to refer to the servlet spec rather than to JavaWorld articles.

• Accept



• Old text: [entire section]


• Reasoning: What is event handling? Why should it (or not) be discussed? Suggest we drop this.

• Accept



• Old text: ... depends on the JSessionID cookie and ...

• Proposed text: ... depends on session cookie and ...

• Reasoning: There is no such thing as JSessionID cookie in the servlet spec. The name of the cookie is JSESSIONID.

• Accept

Change Request #30• Spec / 3.13 & 3.14 / Page 16 & 17


• Proposed text: [combine]

• Reasoning: Significant overlap on similar issues

• Keep separate

Issue #173 Resolution

• Accept new section (#4) that lists the interfaces and operations in a succinct way.

• Keep

Change Request #123• Spec / 4.4 / Page 18 / Line 14• Requested by: Sasha Aickin• Old text: "PortletDescriptionResponse"• Proposed text: “LocalizedPortletDescription"• Reasoning: We may have gone over this before (I

don't actually remember), but I think that we should take out "Response" as much as possible from our return types, especially when the return type is already a noun (as it is in this case). If we decide that we do want to keep response, though, we should use it consistently and always put <function_name>Response. That would change my suggestion to "GetPortetDescriptionResponse".

• Keep as is

Change Request #48• Spec & wsdl / 5-8 & 14 • Requested by: Michael Freedman [RT modified]• Old text: • Proposed text: Remove Security.AccessDenied and

Security.AuthenticationFailure faults• Reasoning: They don't seem to be appropriate.• [Eric VanLydegraf] I would push it to transport level

(e.g. HTTP 401 Error for Consumer failing to authenticate to Producer)

• [Rich Thompson] I generalized Mike's request ... these faults belong to the security subsystem, not the WSRP protocol.

• Drop Security.AuthenticationFailure

Change Request #51• Spec / 5.1.1 / Page 19 / Line 20 • Requested by: Michael Freedman• Old text: after "as part of containing data structures"• Proposed text: [insert] "They are designed to

communicate extended information between the Consumer and Producer. Consumers and Producers SHOULD NOT rely on receiving back any extensions passed to or returned from an invocation."

• Reasoning: We have a number of data structures that are repeatedly supplied to the Producer. We should make it clear that the Producer can't use the extensions field of these structures to pass/maintain state. Likewise for the Consumer.

• Accept

Change Request #72• Spec / 5.1.2 (5.1.1?)

• Requested by: Andre Kramer

• Old text:

• Proposed text: move to 3.3

• Reasoning: Get our extensibility mechanism definition out of the flow of service description

• Keep as is

Change Request #36• Spec & wsdl / 5.1.10 / Page 22 / Line 4 & 10

• Requested by: Michael Freedman

• Old text: [R] string markupType

• Proposed text: [R] string markupTypes[]

• Reasoning: To reduce verbosity shouldn't we allow a portlet to define the N markup types for which the remainder of the structure applies? Or do folks think that this is such a rare case that not dealing with an array is a better form?

• Keep as is

Change Request #37• Spec / 5.1.11 / Page 23 / Line 20• Requested by: Michael Freedman• Old text: needSecureCommunication• Proposed text: • Issue: Our description/support for secure communication seems weak. In many

places we tie together into a single boolean secure comunication between the client and consumer as well as secure communication between the consumer and the producer. Why do we do this? Do we really allow a Producer to offer both secure and non-secure ports at the same time? What is this use case for this? If so shouldn't GetServiceDescription return a boolean field indicating which should be used? Or are we expecting the register call to throw a fault indicating secure access is required? I.e. if we believe there is a use case for supporting both ports and transitioning between them [in a manner that is tied to the client]. I think I understand this field but then aren't we missing a simple way to indicate all communication between the consumer and producer should be secure regardless of the communication between the client and the consumer?

• rename field to defaultMarkupSecure (default=false) (Rich to develop description) … default markup will have links that determine security for later pages. Issue: markup generated for a secure interaction MUST NOT be reused for a non-secure page (possible result of an interaction with another portlet) … restricts the ability of the Consumer to make the page not secure even when interactions do not indicate a need for security. Flag only relates to Client-Consumer communication. For secure client communication, the Consumer SHOULD also communicate to the Producer securely if the Producer has made a secure port available.

1 of 2

Change Request #86• Spec & wsdl / 5.1.11 / Page 23 / Line 20• Requested by: Alejandro Abdelnur• Old text: needSecureCommunication is defined as a

String accepting 3 values: none (default), some, all.• Proposed text: needSecureCommunication should be

a boolean with FALSE as default.• Reasoning: 'some' does not provide useful information

to the consumer. A portlet saying 'some' is a portlet that can render markup in secure and non-secure mode and will decide what to render in a programmatic way: the MarkupParameters indicate if the connection is secure or not. If a secure communication is not supported the portlet will [programmatically] just do it's non-secure business.

• See #37

2 of 2



• Old text: This will require the Consumer format its URLS in a manner ...

• Proposed text: "If the Consumer uses this portlet, the Consumer MUST format its URLs in a manner ..."

• Reasoning: Make it clear in this description that Consumers can ignore such portlets.

• Accept

Change Request #73• Spec / 5.1.11 - PortletDescription.userContextStoredInSession

• Page/Line:• Requested by: Andre Kramer• Old text: • Proposed text: The session referred to here is a Portlet session

or the HTTP session that scopes the Portlet session if one exists.

• Reasoning: If requiresInitCookie <> "none" then a per-user HTTP session is active for the user. We may wish to re-visit whether templatesStoredInSession is scoped in the same way (as an optimization).

• Add Interface.InvalidSession fault – semantics are that the Consumer MUST reinvoke the operation with a null sessionID the addition of any data it had dropped under the presumption it was stored in the session. (Note: add equivalent presumption to processing InvalidCookie fault)



• Proposed text: [append] "Note that the Consumer MAY send templates on any invocations regardless of the value of this flag."

• Reasoning: Templates may change within the span of a session

• Accept (also for UserContext data)

Change Request #67• Spec & wsdl / 5.1.12 / Page 24 / Line 19-23• Requested by: Alejandro Abdelnur• Old text: Note that the WSDL from section 15 defines two

means by which this field may be sent, either as a generic array of elements or as a single element with a type of string. This second choice was added as many properties are likely to be of this type and it allows the web stack to automatically do the (de)serializing to the wire format.

• Proposed text: Note that the WSDL from section 15 defines two means by which this field may be sent, either as a generic array of elements or as an array of element with a type of string . This second choice was added as many properties are likely to be of this type (especially the case ofa single string) and it allows the web stack to automatically do the (de)serializing to the wire format.

• Reasoning: Expecting string[] to be common.• Keep as is

Change Request #75• Spec / 5.1.15 PropertyDescription / Page 25• Requested by: Andre Kramer• Old text: • Proposed text: [O] string propertyUsage• propertyUsage: Describes whether the property is

read-only (propertyUsage == "readOnly") or optional (propertyUsage == "optional"); with the Producer supplying a default value for optional properties.

• Reasoning: Property types are overloaded for Portlet and Registration properties and we have no way to indicate which are optional and which are read-only (especially important for registration). Not clear if consumer can currently ignore registration properties it does not understand.

• Revisit for v2

Change Request #68• Spec & wsdl / 5.1.16 + / Page 25 / Line 24


• Old text: ModelDescription

• Proposed text: PropertyModelDescription


• Keep as is

Change Request #27• Spec & xsd file / 5.1.16 / (25/28) - ModelDescription.schema• Requested by: WSDL subgroup• Old text: <element ref="xsd:schema" minOccurs="0"/>• Proposed text: <element name="modelTypes" minOccurs="0">• <sequence> • <any namespace="##other"/>• </sequence>• </element>• Reasoning: The ref=xsd:schema does not work for any of the

standard wsdl tools we have tested (Axis ignores it, .Net throws an error, JAXRPC stops serializing entire enclosing structure). Also the wire format of the two current formats is NOT equivalent (different namespaces). Proposal follows the WSDL example where the schema leaves the content model open and the spec comments on expecting this to be a schema element from the schema spec. Testing will continue ....

• Accept



• Old text: [O] cookieProtocol

• Proposed text: [O] CookieProtocol

• Reasoning: This type isn't defined/described previously in this chapter. Shouldn't we add its description along with the rest?

• Accept

Change Request #74• Spec & wsdl / 5.1.17 ServiceDescription• Requested by: Andre Kramer• Old text: • Proposed text: [O] string[] locales• Reasoning: What locales the service description is

available in is not advertised. Unlike PortalDescription.markupTypes[].locales[], there is no clear way to work out what desiredLocales[] to request with getServiceDescription(). Remember, getServiceDescription() typically needs to be called twice anyway so why not help seed desiredLocales?

• Accept (not related to offeredPortlets)

Change Request #38• Spec & wsdl / 5.1.17 / Page 26 / Line 37• Requested by: Michael Freedman• Old text: none• Proposed text: add a new field [O] boolean

requiresSecureCommunication• Reasoning: This field indicates whether all calls between the

consumer and the producer must use the secure ports. Default would be false. We need a convenient way for a Consumer to know how to establish/continue communication with a Portlet for all calls.

• [Eric VanLydegraf] If a Producer only declares non-secure or secure SOAP endpoints, that in itself takes care of one or the other, if both are supplied and the Producer is interested in the mixed secure transport style than we need to workout how that works just as you mentioned in the previous comment.

• Keep as is



• Old text: [entire section]

• Proposed text: [move to chapter 6]

• Reasoning: UserContext is not used for the service description interface.

• Accept

Change Request #76• Spec & wsdl / 5.1.18 / Page 27 / Line 12


• Old text: userContextID: This key ...

• Proposed text: replace key with ID

• Reasoning: The ID description states that an ID is unlikely to be used as a key. However, this ID is likely to be used as a Key.

• Accept

Change Request #39• Spec & wsdl / 5.2 / Page 29 / Line 3• Requested by: Michael Freedman• Old text: Faults: Security.Accessdenied,

Security.InvalidUserCategory ...• Proposed text: Remove AccessDenied,

InvalidUserCategory, InconsistentParameters, AuthenticationFailure, and MissingParameters.

• Reasoning: None of these faults appear to have meaning in the conetxt of a getServiceDescription call.

• [Eric VanLydegraf] MissingParameters may apply as RegistrationContext could be null, but the Producer may requireRegistration=true.

• Accept

Change Request #2• Spec / 5.2 / Page 29 / Line 11-14• Requested by: Rich Thompson• Old text: “Producers may also find it useful to restrict the information

returned to those portions of the service that the registration context will allow the Consumer to access on subsequent invocations. Producers using various security standards (e.g. WS-Security or SSL) to secure the communication should delegate this access control issue to the relevant security context.”

• Proposed text: (delete these 2 sentences)• Reasoning: When our security people read through the spec, they found

these two sentences not useful for several reasons, primarily:1. They don't really say anything beyond the sentence at line 7.2. By raising the question of delegating such decisions without fully specifying how

such delegation would work, the spec does more to confuse than to help.3. It really isn't the role of the WSRP spec to define how implementations will also

support various security standards.• Accept

Change Request #54• Spec / 6.1.1 / Page 30 / Line 30• Requested by: Michael Freedman• Old text: A unique, opaque string the Consumer

MAY ...• Proposed text: A unique to the registrationContext,

opaque string the Consumer MAY ...• Reasoning: This isn't a globally unique string -- its

merely unique to the registrationContext.• [Rich Thompson] alternate proposed: An opaque

string, unique within the registrationContext, which the Consumer MAY ...

• Accept alternate

Change Request #55• Spec / 6.1.1 / Page 30 / Line 31• Requested by: Michael Freedman• Old text: ... Consumer MAY supply as a reference to

this use of the Portlet.• Proposed text: ... Consumer MAY supply as a

reference to its use of this Portlet.• Reasoning: I found the first sentence confusing. I had

trouble understanding whether this applied to the Consumer vs. the Portlet. I should probably take a grammar class -- but instead suggest replacing with "its" to make this clear.

• Accept



• Old text: Since this reference may be used as such a key, its length MUST be less than 256 bytes and Consumer SHOULD keep it as short as possible.

• Proposed text: Since this reference is a Key, its length is restricted to 255 bytes. Consumer SHOULD keep it as short as possible.

• Reasoning: I like it better ;-)

• Accept

Change Request #40• Spec & wsdl / 6.1.2 / Page 30 / Line 27• Requested by: Michael Freedman• Proposed text: add a secureConsumerCommunication boolean field• Reasoning: How does a Producer determine they were called via a secure

channel? I.e. does JAX-RPC and other webstacks provide the equivalent of an isSecure() call or do we have to pass this information?

• [Eric VanLydegraf] This is always a problematic area, the security infrastructure should provide the security context, aka the transport is the only one that really knows, having anybody state the security setting is unverifiable information which defeats itself as far as security is concerned. The isSecure() is a good example of the infrastructure providing the information, as it does know exactly how the request was received. The web stacks will have to do the same thing or some other network or software infrastructure will have to enforce the security requirements, because by the time the SOAP endpoint hands off the request it is too late.

• Keep as is

Change Request #57• Spec / 6.1.4 / Page 31 / Line 19• Requested by: Michael Freedman• Old text: Note that any key caching systems use

locate this markup ...• Proposed text: Note that any key used by the caching

system to locate this markup MUST include the MarkupParams structure that was current when the content was originally cached.

• Reasoning: I like it better ;-) • [Eric VanLydegraf] I have suggested a fix for this one

as well change request #16, but I like yours better so would promote this one over mine.

• Accept

1 of 2

Change Request #16• Spec / 6.1.4 / Page 31 / Line 19-20• Requested by: Eric van Lydegraf• Old text: “Note that any key caching systems use locate this

markup later MUST always include the MarkupParams structure that caused the markup fragment to be generated.”

• Proposed text: “Note that any key caching systems that retrieve this markup fragment MUST always include the MarkupParams structure that was originally used to generate this markup.”

• Reasoning: The sentence was hard to understand, but my offered replacement is my understanding of the intent of the sentence. I'm sure better alternatives can be found.

• See #57 (ok)• Separate point … UserScope of “other” => Consumer should

look in the extensions field for additional information. If no user scoping for caching the markup is established, the Consumer SHOULD NOT cache the markup.

2 of 2

Change Request #41• Spec / 6.1.5 / Page 32 / Line 18-47• Requested by: Michael Freedman• Old text: • Proposed text: • Reasoning: How do these values relate to the Portlet's

needsSecureCommunication flag? I.e. are subsets of these NIL depending on whether the needsSecureCommunication is none or always? If so don't we need to rework the meaning of defaults? If not how does the Consumer reconcile the Portlet flag and the URLs it writes?

• Handled with earlier resolution

Change Request #42• Spec & wsdl / 6.1.5 / Page 32 / Line 18• Requested by: Michael Freedman• Old text: namespacePrefix• Proposed text: remove this field• Reasoning: We intend to allow portlets to cache this

structure on a session basis. This field appears to break this -- i.e. its value is related to the consumer instance of the portlet not the portlet instance itself. I suggest we just direct folks to use the portletInstanceKey in RuntimeContext. We should also require this later be passed when templates are required to be passed.

• Accept (impacts namespace sections ….)

Change Request #77• Spec / 6.1.5 / Page 27• Requested by: Andre Kramer• Old text: secureDefaultTemplate field MAY provide a

first level override ...• Proposed text: secureDefaultTemplate field MUST be

used as the default for all secure URLs that the Portlet writes. If not present a fault is thrown by the Producer if the Portlet attempts to write a secure URL.

• Reasoning: Dangerous to fall back to non-secure if consumer does not supply any reliable way to secure requests. So we do need the RequiresSecureCommunications fault?

• Accept … impacts both default definitions



• Old text: [R] boolean secureClientCommunication

• Proposed text: move this field to RuntimeContext

• Reasoning: This information is likely as important to action handlers. It seems better suited if carried by the RuntimeContext vs. the MarkupParams

• Keep as is



• Old text: [R] string markupCharacterSet

• Proposed text: [R] string markupCharacterSet[]

• Reasoning: This provides HTTP equivalent function. Also, JSR 168 supports API for acquiring more then 1 character set.

• Accept … order == preferred order

• make optional … UTF-8 default is always available

Change Request #58• Spec / 6.1.8 / Page 34 / Line 40• Requested by: Michael Freedman

• Old text: This field contains the opaque navigational state for this Portlet either from the appropriate URL parameter or the most recently returned value for this End-User.

• Proposed text: This field contains the opaque navigational state for this portlet. To exist, navigational state must be set explicitly on each request either by setting its value upon return from a blocking action or in a non-blocking or render URL.

• Reasoning: Clarity. • [Eric VanLydegraf] Note CR#15 shows we have two ways in the spec for

dealing with this, one is empty string default action and the other is keeping previous value around to pass along.

• Accept

1 of 2

Change Request #15• Spec / 6.1.8 versus 10.2.1.1.1• Page/Line: 34/40-42, 60/37-42• Requested by: Eric van Lydegraf• Old text:• Proposed text:• Reasoning: Sec 6.1.8 states that either the

parameter supplies the navigationalState or the most recently returned value for this End-User is used. Section 10.2.1.1.1 says if the parameter is missing supply an empty string.

• See #58

2 of 2

Change Request #59• Spec / 6.1.8 / Page 35 / Line 13• Requested by: Michael Freedman• Old text: An array of modes which the Consumer is

indicating as available to be requested as a newMode in InteractionResponse.

• Proposed text: Current set of modes the Producer MAY request changing to. Can be used to specify a mode change either via an InteractionResponse or within an URL written into the response markup.

• Reasoning: I like it better ;-)• Accept … wordsmithing still allowed

Change Request #25• Spec / 6.1.8 & 6.8 & 6.9 / Page 35 /Line 31• Requested by: Eric van Lydegraf• Old text:• Proposed text: “STRONGLY RECOMMEND that for custom

modes, windowStates, userAuthentication that URI's or prefixes be used as future specifications may add more constant string values that risk nameclashes and difference of semantic meaning.”

• Reasoning: We've never spelled out how the custom string values are to be set, so we risk that future additions to our constant list will clash with custom values in implementations, but with URI's or prefixes (dash or colon style) we distinguish custom values from the WSRP constants.

• Accept (appropriate rewording for 6.8 & 6.9) (done)• Move userAuthentication to UserContext from MarkupParams

Issue #191 Resolution• Replace “markup” field with a mutually

exclusive pair, “markupString” and “markupBinary”.

• Accept

1 of 2

Change Request #78• Spec & wsdl / 6.1.9 / Page 35 / Line 38• Requested by: Andre Kramer• Proposed text: [O] Markup markup

where:<complexType name="Markup">

<sequence><any namespace="##other" />

</sequence></complexType><element name="markup" type="types:Markup" minOccurs="0"/>

• Reasoning: We cover non-XML text with:<element name="markupString" type="xsd:string" minOccurs="0" />

and binary markup with:<element name="markupBinary" type="xsd:base64Binary" minOccurs="0" />

This "any" allows XML to be inlined naturally.

• Ask WSDL subgroup to check out using [CDATA[“the markup”]] instead. If this works, the spec should recommend it.

2 of 2



• Old text: "various characters will likely need to be escaped"

• Proposed text: "various characters will need to be escaped using XML entities"

• Reasoning: Clarify

• Accept

Change Request #33• Spec / 6.1.12 / Page 38 / Line 10-18 & 29-30



• Reasoning: Text was not removed when these moved to the interactionResponse field.

• Accept



• Old text:

• Proposed text: [O] boolean rewriteRedirectURL

rewriteRedirectURL: If redirectURL is non-null then this boolean directs the Consumer to apply consumer URL re-writing if true (default is false). The redirectURL value MUST be a Resource URL (10.2.1.1.3).

• Revisit for v2

Change Request #45• Spec & wsdl / 6.1.15 / Page 39 / Line 9• Requested by: Michael Freedman• Old text: [O] NamedString mimeHeaders[]• Proposed text: [O] NamedString

mimeAttributes[]• Reasoning: We have avoided using the term

Headers elsewhere in the specification [i.e. clientData field in MarkupParams]. Shouldn't we avoid it here as well?

• [Eric VanLydegraf] ? mimeValues• Accept - mimeAttributes



• Old text: [R] string interactionState

• Proposed text: [O] string interactionState

• Reasoning: Why is this a required field. I.e. why pass "" when there is no state?

• Accept … navState as well

Change Request #60• Spec / 6.1.16 / Page 39 / Line 42• Requested by: Michael Freedman• Old text: [Mike ...] • Proposed text: Common user agents (web browsers) encode

posted data in the character set of the response that generated the page the form is on. As the Producer is ignorant of this encoding and the Consumer is required to encode passed parameters consistently (with the SOAP message), Consumers MUST ensure that form data is properly decoded before it is passed to the Producer.

• Reasoning: I figure we will debate whether this is a MUST or a SHOULD. Problem with SHOULD is that Producers can't be reliably written. Problem with MUST is the Consumer may not be able to always determine what character set they received from the user agent.

• Accept

Change Request #100• Spec & wsdl / 6.2 / Page 40• Request by: Alejandro Abdelnur• Current: getMarkup() and performInteraction() are 2 distinct operations.• Proposed: Combine them in a single operation, drop current getMarkup()

and rename current performInteraction() to getMarkup().• Reasoning: The non-blocking interaction was added for the purposes of

aligning WSRP and JSR168. However, it does not address the problem. JSR168 does not have the concept of non-blocking interaction. JSR168 allows properties to be modified during a getMarkup() call, regardless of the user request being targeted to the portlet of being just a refresh (the user request targeted to another portlet).

• Note: Resolution of Issue #122 at Nov. F2F explicitly was unwilling to do this combination. Compromise was that only the pushing of state to the Consumer is not allowed. Clone-on-write semantics???

• Keep as is



• Proposed text: [insert sentence] "Portlets indicating the cached markup can be used SHOULD also supply a new CacheControl with a new expiry for the markup."

• Reasoning: Clarify

• Accept



• Old text: When the MarkupParams structure supplied for generating the markup changes, the Consumer MUST treat the cached markup as if the expires duration had already elapsed.


• Reasoning: The old text implies only piece of content is cached per Portlet. The new wording tries to avoid this

• Accept



• Old text: This operation also carries the semantics of blocking ...

• Proposed text: This operation is distinguished from performInteraction() in that both the ... is blocked.

• Reasoning: I like it better ;-)

• Accept

Change Request #62• Spec / 6.3.2 / Page 41 / Line 41• Requested by: Michael Freedman• Old text: Since this operation .... • Proposed text: Note, if the Producer chooses to use

the optimized form of this operation and return markup directly, care must be taken to ensure the markup is generated with the navigationalState that will be returned from the operation and not the navigational state that was passed to it. This ensures consistency when the optimization is not used and the Consumer invokes getMarkup() after performBlockingInteraction() returns.

• Reasoning: I like it better ;-)• Accept

Change Request #80• Spec & wsdl / 6.5 releaseSession / Page 43• Requested by: Andre Kramer• Old text: • Proposed text: SessionIDs may be set to null in

releaseSession() calls. In which case, the Consumer is signaling that any underlying HTTP session is no longer to be considered active. The Consumer may want to release any session identifiers it caused to be established in the scope of the HTTP session, independently of the HTTP session (but is likely to be supplying portletInstanceKeys).

• Revisit releaseCookie() for v2

Change Request #124• Spec / 5.1.2, 5.1.3, 5.1.4 + / Page 20 / Line 1 +• Requested by: Sasha Aickin• Old text: bytes• Proposed text: characters, we STRONGLY

RECOMMEND these characters be chosen from the first 127 characters of the Unicode characterset. Not following this recommendation will likely lead to information being lost as the Consumer stores and retrieves the value. (ednote -> equivalent in the various sections)

• Reasoning: XML strings conceptually really just have characters, not bytes. If, for example, a Producer creates a key in XML that is 255 bytes in Shift-JIS, the key might not be 255 bytes in UTF-8.

• Accept

Change Request #69• Spec / 6.6 / Page 44 / Line 5-16


• Old text:

• Proposed text: [delete after "porttype."]

• Reasoning: I don't agree with the recommendation on not swapping from non-secure to secure and vice versa.

• Section reworded … check RFC# & insert cross reference

Change Request #103• Spec / 6.7.1, 6.7.2,6.7.3 / Pages 44,45,46• Requested by: Subbu Allamaraju• Old text: ["value" columns for getMarkup /

performInteraction / perfomBlockingInteraction rows in tables on these pages]

• Proposed text: Producer provided sessionContext / sessionID

• Reasoning: The current description "Producer Offered Portlet or Consumer Configured Portlet" on "sessionCotext/sessionID" in these tables is unclear and seems incomplete.

• Accept

Change Request #97• Spec / 6.8 and 6.9 • Requested by: Subbu Allamaraju• Old text:• Proposed text:• Reasoning: JSR168 specifies modes/states in

uppercase while WSRP does the opposite. It would be nice to make mode/states uppercase.

• Note: Resolution to Issue #136 said to use camel casing.

• Keep as is – Mike to request JSR to sync with this

Change Request #70• Spec / 6.9.4+ / Page 48 / Line 17


• Old text:

• Proposed text: [Delete 'solo' window state]

• Reasoning: Not different enough from 'maximized'.

• Keep as is

Change Request #7• Spec / 6.10 / Page 48 / Line 36-42• Requested by: Subbu Allamaraju• Old text:• Proposed text: [addition] Sophisticated producers may

completely ignore user categories and instead rely on authenticated user and/or consumer identity for personalization of behavior and/or markup.

• Reasoning:– Sophisticated producer-consumer implementations may choose to

propagate authenticated end user security context using some (unspecified) security mechanism. With such a security mechanism in place, a producer may choose to use the authenticated principal and roles for personalization in place of userContextID and userCategories.

– I suggest that this section mention this possibility. This would also address sophisticated implementations that rely only on authenticated user identity and roles for personalization.

Sentence modified live.

Change Request #5• Spec / 6.10.2 / Page 49 / Line 22-34• Requested by: Subbu Allamaraju• Old text: The whole section• Proposed text: Delete this section• Reasoning:

– The standard category names are very similar to standard security roles in application servers. This list is prone to misinterpretations.

– This section reads "These definitions suggest progressively restrictive levels of access ..." implying that producers may use these categories for authorization. However, from what I understand, the user categories are intended for personalization and not authorization.

– This section sends confusing signals and leaves scope for misinterpreting the spec. I suggest to delete this section.

• Move to Appendix B (reworded as well)

1 of 3

Change Request #104• Spec / 6.10 / Page/Line: 48/29-30 and 48/32• Requested by: Subbu Allamaraju• Old text: The Producer's ServiceDescription MAY

declare support for user categories including both the standard user categories and any additional user categories it defines. ... Producers that use user categories (standard or custom) SHOULD ...

• Proposed text: The Producer's ServiceDescription MAY declare support for user categories it defines. ... Producers that use user categories SHOULD ...

• Reasoning: Refer to change request #5 (drop standard user categories). The text above needs to change if we agree to #5.

• Keep as is

2 of 3

Change Request #63• Spec / 6.10.2 / Page 49 / Line 25• Requested by: Michael Freedman• Old text: These definitions suggest progressively

restrictive levels of access to the potential functionality of the Portlet and are provided accordingly.

• Proposed text: These definitions suggest progressively restrictive levels of content and are provided accordingly.

• Reasoning: User Categories don't carry security semantics so mentioning access control is inappropriate.

• Covered in rewording for #5.

3 of 3

Change Request #49• Spec & wsdl / 7.3 / Page 51 / Line 27


• Old text:

• Proposed text: remove Security.AccessDenied, Security.AuthenticationFailure, Security.InconsistentParameters faults

• Reasoning: They don't seem to be appropriate.

• [Eric VanLydegraf] same as previous - push to transport.

• Accept



• Old text:

• Proposed text: The Consumer is strongly encouraged to re-try deregister() invocations that failed due to network problems (at a later time) or to seek administrative intervention.

• Keep as is

• Drop Security.AccessDenied fault



• Old text:

• Proposed text: Any Producer that clones portlets on performBlockingInteraction() or performInteraction(), via the CloneOnWrite mechanism (6.3.3) SHOULD support the releasePortlet() operation.

• Reasoning: Cross dependency of optional and required factors.

• Accept

Change Request #83• wsdl for 8.1.4 - PortletPropertyDescriptionResponse


• Old text: [O] ModelDescription

• Proposed text: Make minOccurs="0" in the wsdl as well.

• Accept



• Old text:

• Proposed text: Note that changing a property’s value could impact the value of any of the Portlet’s properties.

• Accept

Change Request #64• Spec / 10.2 / Page 58 / Line 15 and throughout


• Old text: interaction URLs

• Proposed text: portlet URLs

• Reasoning: We already define/use the term interaction. I seems inconsistently used here to refer to all type of URLs whether interaction URLs or render URLs or resources.

• Accept (& portlet URL parameters)

Change Request #35• WSRP spec / 10.2.1 / Page 60 / Line 16• Requested by: Alejandro Abdelnur• Old text: "wsrp-rewrite?wsrp-urlType&name1=value1&name2=value2

.../wsrp-rewrite"• Proposed text: "wsrp-rewrite?wsrp-urlType=value&name1=value1&name2=value2 .../wsrp-rewrite"

• Reasoning: This would allow implementations that handle the type as a parameter not to have to parse the parameter string. Would imply the following as well:

• Section: 10.2.1.1 / Page 60 / Line 26-27• Old text: "This parameter MUST be specified first by replacing the string

“wsrp-urlType” in the template above with one of the following values."• Proposed text: "This interaction parameter MUST be specified first when

using the template above and the value selected from the following definitions.“

• Sections 10.2.1.8 & 10.2.3• Accept

Change Request #65• Spec / 10.2.1.1.3 / Page 61 / Line 21


• Old text: , the Consumer MUST a value of "".

• Proposed text: , the Consumer MUST supply a value of "".


• Accept

Change Request #85• Spec / 10.2.1.1.4.2 / Page 61 / Line 42


• Old text:

• Proposed text: The default value for wsrp-rewriteResource is true.

• Reason: Default could be false, but still seems somewhat unclear how to use URL templates for resource writing.

• No … require both wsrp-url and wsrp-rewriteResource when urltype=“Resource”

Change Request #66• Spec / 10.2.2 / Page 63 / Line 17• Requested by: Michael Freedman• Old text: Producers and Portlets ... may provide

better page load performance to the End-User • Proposed text: Remove this sentence or rewrite

section to incorporate: "On the other hand, using Producer URL writing may have a negative impact on the cachability of content."

• Reasoning: Shouldn't encourage folks to use Producer URL writing for performance reasons as this may have the opposite effect.

• Reworded live

Change Request #50• Spec / 10.3 / Page 67 / Line 2• Requested by: Michael Freedman• Old text: • Proposed text: • Reasoning: This section says the Consumer is

required to remove the namespace encoding even from HTML form fields. Though we discourage its use, Consumers will have to parse the form field names anyway just for the rogue portlet. This impacts performance. Anyway we can "prohibit" its use in form fields -- maybe by telling the Producer that the Consumer won't remove these prefixes?

• Reworded live

Change Request #98• Spec / 10.4


• Old text: [tables for tags]

• Proposed text: [inline]

• Reasoning: Inconsistent. Suggest to list the tags inline.

• Accept

Change Request #105• Spec / 12 / Pages 74-81• Requested by: Subbu Allamaraju• Old text: [Entire chapter]• Proposed text: [Move 12.40 to section 5, and delete the rest]• Reasoning: Some of the data structures defined here (12.7,

12.8 and 12.11) duplicate text from previous sections. The only section required here 12.40 (profile) which could be moved section 5 (discuss in the

• context of UserContext). With these changes, we can completely delete this section.

• [Rich Thompson] Alternative: Change style into a table and make it a part of Chapter 4 ... just lists the data types (alphabetically) with hyperlinks to the correct sections

• Try alternate (comment that chapter 4 is non-normative)• Decided instead to move it to an appendix … add references to

section numbers for the sake of printed copies.

Change Request #106• Spec / 13 / Page 81, "edit" mode description• Requested by: Subbu Allamaraju• Old text: Portlet is expected to render markup

useful for End-User personalization• Proposed text: Portlet is expected to render

markup useful for customization.• Reasoning: Per the definition of view mode

(6.8.2), this mode is meant for customization of a portlet and not End-User personalization.

• Systematically change throughout document– Customize => end-user (logically) sourced settings– Personalize => system sourced settings

Change Request #3• Spec / 15 / Page 83 / Line 9• Requested by: Rich Thompson• Old text: "" (suggestion is appended)• Proposed text: "The WSDL for a Producer service

endpoint MUST import http://www.oasis-open.org/committees/wsrp/v1/WSRP_v1_Bindings.wsdl ."

• Reasoning: This fundamental requirement has been stated in committee meetings, but is not currently reflected in the spec as a concise conformance statement.

• Keep as is

http://www.oasis-open.org/committees/wsrp/v1/WSRP_v1_Bindings.wsdl

http://www.oasis-open.org/committees/wsrp/v1/WSRP_v1_Bindings.wsdl

Change Request #101• Spec / Appendix A / Pages 85-87


• [delete] Administrator, Authorization, Consumer Application, Credential, Customer, Event, Identity, Sign-On, Sign-Off, Party, Site, System/System Entity, User, Username/User Identity, WSIA Web Service, Window States, WSIA Interfaces

• Reasoning: Aren't relevant to the current draft

• Accept – leave system entity

Change Request #107• Spec / Appendix A / Page 85 - "Browser"


• Old text: Browser

• Proposed text: User-Agent

• Reasoning: A more formal term

• Accept – and throughout spec

Change Request #108• Spec / Appendix A / Page 85 - Consumer


• Old text: A business entity ... creating Consumer Applications

• Proposed text: A system entity invoking Producers in a manner conforming to this specification. For example a portal …

• Reasoning: Accuracy

• Accept

Change Request #109• Spec / Appendix A / Page 85 - End-User


• Old text: "specific Browser"

• Proposed text: [delete 1.] & "specific User-Agent"

• Reasoning:

• Accept

Change Request #110• Spec / Appendix A / Page 86 - "Portlet"


• Old text: Component that generates fragment

• Proposed text: Producer hosted component that generates aggregatable content and processes interactions generated from that content.

• Reasoning: Align with the portlet definition in 1.2.1.

• Accept

Change Request #111• Spec / Appendix A / Page 86 – “Producer”


• Old text: [replace current]

• Proposed text: A web service conforming to this specification.

• Reasoning: More accurate definition

• Accept

Change Request #112• Spec / Appendix A / Page 86 - "Session"


• Old text: A lasting interaction between ...

• Proposed text: A finite duration interaction between ... [or something equivalent]

• Reasoning: Sessions normally exist for a finite time

• Accept

Change Request #113• Spec / Appendix A / Page 86 - "Site"


• Old text: ... or it may encompass multiple administrative domains, as may be the case at an ASP site

• Proposed text: ... or it may encompass multiple administrative domains.

• Reasoning: ASP is a new term here.

• Note: #101 proposes deleting this term

Change Request #114• Spec / Appendix A / Page 87 - "Window States"


• Old text: Max, min, normal, detached

• Proposed text: An indicator of the amount of page space that will be assigned to the content generated by a Portlet.

• Reasoning: Align with the definition in 6.9

• Note: #101 proposes deleting this term

Change Request #115• Spec / Appendix A / Page 87 – “Portlet Mode”


• Old text:

• Proposed text: [add Portlet mode]

• Reasoning: Missing

• Keep as is

Change Request #116• Spec / Appendix A / Page 87 - "XML Namespace"


• Old text: [last sentence]


• Reasoning: Necessary?

• Accept … add hyperlinks to spec for this and XML. Change “A collection of names” to “A name” … make verbs singular.

Change Request #102• Spec / Appendix A / Page 85


• Old text: a system entity ... service. Contrast with Browser and Customer.

• Proposed text: A system entity ... service.

• Reasoning: Consistent capitalization and drop 2nd sentence as it does add anything other than requiring additional definitions.

• Accept … check whether we really use this in the spec.

Change Request #8• Spec / Appendix C / Page 89• Requested by: Rich Thompson• Old text:• Proposed text: Indicate the membership of the WSIA

committee at the time the spec becomes a committee spec in the same manner as is done for the WSRP committee on page 90.

• Reasoning: Such inconsistency is in bad taste. I think it is valuable to list everyone who was involved, but the format should also indicate who actually had a vote when the spec was finalized.

• Accept

Change Request #11• WSRP spec / Title page & Appendix C

– Requested by: Alan KroppOld text: "Vignette, Inc.“Proposed text: "Vignette Corporation“

– Requested by: Yossi TamariOld text: "SAP Portals“Proposed text: "SAP" ... for all SAP members

– Requested by: Shumakher, GennadyOld text: "Shumaker, Gennady“Proposed text: "Shumakher, Gennady“

– Requested by: Michael FreedmanOld text: Michael Freedman, Oracle Proposed text: Michael Freedman, Oracle Corporation

– Requested by: Subbu AllamarajuOld text: BEAProposed text: BEA Systems Inc

– Sun Microsystems– Plumtree Software– WebCollage– Joseph Stanko– Ross Fubini instead of Ross Rubuni– TIBCO Software Inc. replaces Tibco– Citrix Systems, Inc– Rex Brooks, Individual– Aditi -> ‘r’ at end of last name– Add Michael Young, Plumtree Software– Reed Elsevier (no dash) – Eric van Lydegraf on WSIA as well

Change Request #10• wsdl and xsd files / Version comment


• Old text: "0.89"

• Proposed text: “0.91"

• Reasoning: Accuracy of the comment

• Accept

Change Request #13• WSRP spec; Page/Line: 2/16, 8/17, 16/23,

74/32, 83/6,8,16,27

• Requested by: Eric van Lydegraf

• Old text: [tabs]

• Proposed text: [space]

• Reasoning: better for reading and printouts

• Left justify

Change Request #125• Spec / 3.5 / Page 14 / Line 4-5• Requested by: Gil Tayar• Old text: ..as the Consumer must explicitly invoke

deregister() to terminate a registration scope. This scope is referenced throughtout the protocol using registrationHandle. The producer optionally exposes this scope by declaring support for the Registration portType.

• Proposed text: This scope is referenced throughout the protocol using registrationHandle. The registrationHandle is created and destroyed using either in band mechanism, i.e. by declaring support for the Registration portType, or by out of band mechanism, whereby the registrationHandle is created and destroyed by means outside this specification.

• Accept

Change Request #126• Spec / 6.1.9 / Page 36 / Line 2• Requested by: Gil Tayar• Old text: This field MUST be specified

whenever markup is returned.• Proposed text: This field MUST be specified

whenever markup is returned, and if the markupBinary field is used to return the markup, the mime type MUST include the character set for textual mime types. In this particular case this character set MAY be different than the response message.

• Accept

Change Request #127• Spec / 6.1.2 / Page 30 / Line 31• Requested by: Gil Tayar• Old text: The intent of this reference is to allow

the Portlet to namespace multiple instances...• Proposed text: The intent of this reference is to

allow the Portlet to namespace multiple instances in an optimal manner...

• Accept (done)• Add namespacePrefix to RuntimeContext

(move templates over as well) … may change per request. Must be provided when templates are provided.

Performance impacts of wsrp-rewrite token

Cryptic token is only marginally faster than wsrp-rewrite. Keep as is.

Documents

WSRP Specification Work January Face-to-Face. Resolved Change Requests 1: Identifier 6: Delete Role from Glossary 9: Property Type reference 12: Missing