wsrp specification work january face-to-face. resolved change requests 1: identifier 6: delete role...
TRANSCRIPT
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
• Requested by: Subbu Allamaraju
• 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
Change Request #28• Spec / 1.2.3 / Page 10 / Line 23
• 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
• Requested by: Subbu Allamaraju
• 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
Change Request #99• Spec / 3 / Page 12 / Line 13
• Requested by: Subbu Allamaraju
• 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
Change Request #120• Spec / 3.4 / Page 13 / Line 32
• Requested by: Sasha Aickin
• 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
Change Request #91• Spec / 3.6 / Page 14 / Line 17
• Requested by: Subbu Allamaraju
• 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)
• Requested by: Subbu Allamaraju
• 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
Change Request #122• Spec / 3.8 / Page 15 / Line 21
• Requested by: Sasha Aickin
• 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
Change Request #93• Spec / 3.9 / Page 15 / Line 35
• Requested by: Subbu Allamaraju
• Old text: Possible implementation choices include: ...[till the end of the list]
• Proposed text: [delete]
• 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
Change Request #94• Spec / 3.11 / Page 16 / Line 5
• Requested by: Subbu Allamaraju
• Old text: [entire section]
• Proposed text: [delete]
• Reasoning: What is event handling? Why should it (or not) be discussed? Suggest we drop this.
• Accept
Change Request #95• Spec / 3.13 / Page 16 / Line 31
• Requested by: Subbu Allamaraju
• 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
• Requested by: Alejandro Abdelnur
• 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
Change Request #52• Spec / 5.1.11 / Page 23 / Line 28
• Requested by: Michael Freedman
• 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)
Change Request #31• Spec / 5.1.11 / Page 23 / Line 42
• Requested by: Alejandro Abdelnur
• 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
• Requested by: Alejandro Abdelnur
• Old text: ModelDescription
• Proposed text: PropertyModelDescription
• Reasoning: Clarity
• 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
Change Request #53• Spec / 5.1.17 / Page 26 / Line 8
• Requested by: Michael Freedman
• 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
Change Request #96• Spec / 5.1.18 / Page 27 / Line 1
• Requested by: Subbu Allamaraju
• 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
• Requested by: Andre Kramer
• 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
Change Request #56• Spec / 6.1.1 / Page 30 / Line 34
• Requested by: Michael Freedman
• 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
Change Request #43• Spec & wsdl / 6.1.8 / Page 33 / Line 25
• Requested by: Michael Freedman
• 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
Change Request #44• Spec & wsdl / 6.1.8 / Page 33 / Line 28
• Requested by: Michael Freedman
• 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
Change Request #32• Spec / 6.1.9 / Page 36 / Line 5
• Requested by: Alejandro Abdelnur
• 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
• Requested by: Alejandro Abdelnur
• Proposed text: [delete]
• Reasoning: Text was not removed when these moved to the interactionResponse field.
• Accept
Change Request #79• Spec & wsdl / 6.1.13 / Page 38 / Line 35
• Requested by: Andre Kramer
• 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
Change Request #46• Spec & wsdl / 6.1.16 / Page 39 / Line 22
• Requested by: Michael Freedman
• 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
Change Request #34• Spec / 6.2.1.2 / Page 40 / Line 31
• Requested by: Alejandro Abdelnur
• 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
Change Request #47• Spec / 6.2.1.2 / Page 40 / Line 31
• Requested by: Michael Freedman
• 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.
• Proposed text: [delete]
• Reasoning: The old text implies only piece of content is cached per Portlet. The new wording tries to avoid this
• Accept
Change Request #61• Spec / 6.3.2 / Page 41 / Line 15
• Requested by: Michael Freedman
• 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
• Requested by: Alejandro Abdelnur
• 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
• Requested by: Alejandro Abdelnur
• 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
• Requested by: Michael Freedman
• 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
Change Request #81• Spec / 7.4 / Page 52 / Line 12
• Requested by: Andre Kramer
• 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
Change Request #82• Spec / 8 / Page 52 / Line 27
• Requested by: Andre Kramer
• 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
• Requested by: Andre Kramer
• Old text: [O] ModelDescription
• Proposed text: Make minOccurs="0" in the wsdl as well.
• Accept
Change Request #84• Spec / 8.5 / Page 55 / Line 46
• Requested by: Andre Kramer
• 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
• Requested by: Michael Freedman
• 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
• Requested by: Michael Freedman
• Old text: , the Consumer MUST a value of "".
• Proposed text: , the Consumer MUST supply a value of "".
• Reasoning: Clarity
• Accept
Change Request #85• Spec / 10.2.1.1.4.2 / Page 61 / Line 42
• Requested by: Andre Kramer
• 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
• Requested by: Subbu Allamaraju
• 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
Change Request #101• Spec / Appendix A / Pages 85-87
• Requested by: Rich Thompson
• [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"
• Requested by: Subbu Allamaraju
• 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
• Requested by: Rich Thompson
• 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
• Requested by: Rich Thompson
• Old text: "specific Browser"
• Proposed text: [delete 1.] & "specific User-Agent"
• Reasoning:
• Accept
Change Request #110• Spec / Appendix A / Page 86 - "Portlet"
• Requested by: Subbu Allamaraju
• 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”
• Requested by: Rich Thompson
• 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"
• Requested by: Subbu Allamaraju
• 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"
• Requested by: Subbu Allamaraju
• 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"
• Requested by: Subbu Allamaraju
• 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”
• Requested by: Subbu Allamaraju
• Old text:
• Proposed text: [add Portlet mode]
• Reasoning: Missing
• Keep as is
Change Request #116• Spec / Appendix A / Page 87 - "XML Namespace"
• Requested by: Subbu Allamaraju
• Old text: [last sentence]
• Proposed text: [delete]
• 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
• Requested by: Rich Thompson
• 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
• Requested by: Andre Kramer
• 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.