OASIS Web Services for Remote Portals (WSRP) TC

OASIS WSRP TC Meeting

Hathorne, November 4 - 8, 2002

Chairman: Thomas Schaeck, IBM

Meeting Issues .ppt

Agenda

Mon, Nov 4th

Tue, Nov 5th

Wed, Nov 6th

Thu, Nov 7th

Fri, Nov 8th

Monday, 11/4/02

Roll

Welcome
Elect new secretary
Vote on remaining technical issues, so editors can create 0.9 specification
Need host for January F2F, West coast. (Friday)
Introductions

JSR/WSRP sync

Focus on these first, so that Stefan (other JSR lead) can participate.
Alej: Can we use the approach suggested by the JSR spec leads' email, that breaks these into three broad topics?
Mike F: Certain callers have made themselves available for issue 133, so we should start with that one...then suggest the approach in the email.
Refer to F2F slide presentation for discussion points on the following issues

#133 extensions typing (correlated 93, 121)
Rich: Array of <any>, structure pushed in a level for interop with JAX-RPC reference impl.
Alej: Will WSRP define suggested schema for String and String[]?
Rich: Yes
Alej: Then JSR has no problem with the mechanism.
Mike F: We want String[] and PropertyList (name-values).
Rich: Both are in the current wsdl. The schema will become a separate file that gets imported.
Rich asks David (Oracle) for his thoughts on <any> element: JAX-RPC requires <any> element gets wrapped in a grouping element. Otherwise, happy with the idea of XMLSchema for typing.
Andre: <any> doesn't give any interop. Really limited to manipulating them as XML elements, and parsing.
Gil: But that's true of any extensibility mechanism. Issue 133 seems settled?
Mike F: We had a discussion on Thursday about modifying the structure of <any>.
Gil: That's issue 93.
Rich: Another open question: how many vendor implementations inherit the JAX-RPC RI's limitation with respect to <any> deserialization? We should keep the indirection in the extension structure.
David: The wrapper element could be nillable? MinOccurs=0 may be a better choice.
Andre: Because the style of wsdl we're using, nillable elements could be skipped by certain stacks (.NET?) during proxy generation.
Gil: What is the reason for nillable? Use minOccurs=0 to define something is optional.
Rich: These sorts of refinements are being worked out by a sub-group.

#121 user info extension
Alej: JSR defines no required user attributes. A portlet can expose various named user attributes, that must then be mapped by a portal. If the extension is <any>, custom deserializer required.
Carsten: No custom programming...you could use XPath to traverse the XML.
Gil: The difficulty here is that WSRP is taking a document/literal approach, and Alejandro wants a 'pure' rpc approach.
Rich: At a philosophical level, this is the basic question for all three of these issues. Consensus seems to be that we leave things as is.

Mark 133, 93, 121 resolved.

#132 Valid portlet modes/window states
Mike F: JSR and WSRP approaches are not mutually exclusive.
Carsten: The JSR also uses this for determining cacheability?
Mike F: Let's not focus too much on specific JSR functionality. JSR is an external "reviewer" of this spec.
Gil: This seems difficult, if not impossible, for WSRP. Consumer semantics cannot be easily transmitted to the Producer (without a full XACML).
Mike F: Disagree that this is not representable. Do we want 3rd party vendors to just use extensibility?
Gil: What's the proposal?
Rich: (from slide) two independent arrays, allowable window states and allowable portlet modes.
Alej: If arrays aren't present, then implied semantic is all modes/window states are allowed.
Mike F: Producer meta-data indicates cacheability in the session?
Thomas: These aren't likely to change often, so caching makes sense.
Sasha: Is this a MUST for the Producer? If not, don't understand the need for this.
Mike F: The point is to narrow the choices the Producer makes at the point of the request. The spec already states that the Consumer can reject any requested mode/window state transition.
Raj: Producer can choose to return any combination of mode/window state from request to request.
Mike F: Yes.
Sasha: This seems confusing, since we're agreeing to different semantics for JSR and WSRP.
Mike F: True interop will require that the information gets passed. However, this doesn't need to be specified, it's more of an implementation guide.

Resolution
Add arrays to MarkupParams. Add entity metaData. Shoulds => assist in generating UIs valid for the End-User.

#122 Action definition mismatch (#94, 143a)
Thomas: Only state changes would be allowed that don't affect other WSRP entities.
Mike F: JSR represents actions as blocking, non-blocking. Non-blocking action is folded into the render phase.
WSRP has only blocking actions.
Rich: Does a non-blocking action return modified navigational state?
Mike F: No.
Rich: Then Producer could deterministically map between two action protocols. (Option 2 on the slide).
Many: What's the use case for this?
Mike F: JSR has determined that you can only dispatch to a servlet/jsp from getMarkup. This is in addition to the efficiency question.
Andre: This is also important for legacy considerations.
Gil: I still don't understand the reasoning.
Mike F: JSR is designed so that servlets/jsp's can only be executed from a getMarkup. So, render() was designed to model both non-blocking actions as well as rendering.
Gil: What is a non-blocking action?
Mike F: An action that only changes navigational state. So the first level optimization would be to allow performInteraction to return markup. The next level would be to introduce a new operation ("performNonBlockingAction"?), which would be parallelizable.
Rich: This would also require distinction between blocking and non-blocking action urls.
Mike F: If markup is being returned, then Consumer MUST ignore navState, mode/window state, etc. Producer SHOULD set these to null.
Gil: We should draw a 2x2 matrix: Affects Consumer (Y/N) x Affects Other Entities (Y/N)
Rich draws 2x2 matrix to represent the different approaches.
Yossi: What is the reason for restricting mode, window state, etc?
Mike F: Because the Consumer may not be in a state that permits a mode/window state transition. Besides, there's benefit to being overly restrictive in the beginning, and we can relax these later.
Rich: Let's stop here, and move on to the selection of a new secretary.
Rich and Mike will work up the various proposals.
Mike F: We should agree in principle to support non-blocking actions, and the leave the question of 'how' until we see the various detailed proposals. JSR wants to release a new spec at the end of the week, and this is a critical issue.
Rich: Consensus appears to be in favor, so JSR should proceed. We'll look at the detailed proposals tomorrow.

New Secretary (through the next F2F)
Steven Smith has graciously volunteered.

#126 upload data in both markup operations
Alej: This is dependent on the outcome of 133.
Gil: Why? Especially if we choose to model non-blocking actions in getMarkup.
Rich: So we can return to this.

#123 portlet modes per markup
Mike: Forwarded a couple of proposals to dimension allowed modes by markupType in the metadata.
Gil: So we'd need to forward this information per request?
Rich: No, this is entity metadata.
Thomas: So this is necessary to permit portal to render the portlet correctly, with proper controls/decorations.
Sasha: Are Consumer-supported modes showing up in multiple locations?
Mike F: This is Producer-supported.

Resolution
-move metadata into an array of structures where each structure is per markupType & contains validModes and validWindowStates.

• String markupType
• String[] modes
• String[] windowStates
• Extension[] extensions

#124 window ID
Mike F: Want to defer discussion on this. This is a very similar debate as the question of carrying groupID, and would prefer we settle that first.

#152 consumerVendor field format
Gil: What is this field?
Rich: Consumer sending information about itself to the Producer.
Mike F: Major (only?) use case here is for sending information about an extension.
Gil: rename to consumerAgent.majorversion.minorversion.
Sasha: Should explicitly state in the spec that there is no compatibility implied by the version numbering.

Resolution

• rename to consumerAgent
• productname.majorversion.minorversion other_words

#125 clone-on-write
Rich: Goes over the 0.8 tri-state entityStateChange semantic.
Mike F: Fault followed by retry is no longer required? JSR would want a way to signal that it didn't want to receive a fault if this was the semantic.
Rich: That is correct, as of 0.8.
Mike F: Then the JSR would be satisfied with this as the resolution.

#127 setting properties not defined in type definition
Gil: What is the use case for this?
Mike F: There are portal vendors who already have this capability in their products.
Sasha: Like a links portlet, and new links are added as new properties.
Mike F: Should there be a return indicating that the model has changed?
Rich: That seems like a backdoor to eventing.
Bruce: The statement in the spec regarding completeness of the model description should really address how the desire to make it as 'static' as possible.

#119 Naming of modes and window states (#136)
Gil: There was no email commentary on 119.
Gil: These should be namespaced to the specification.
Rich: But these are values...but you namespace the tags.
Sasha: Values should be QNames.
Andre: See this as more of an issue for the customized ones.
Gil: It would be complicated to require namespacing for values. Not sure about consistent stack support.
Sasha: It would be better for extensibility. Would like to vote?

Vote
Change values for modes/window states to QNames?
Yes: 7 No: 10 Abstain: 5 Not Present: 3

Resolution

• Drop redundant portion
• Make lower case

#115(2nd)
Sasha: Would rather go with something more specific to WSRP. 'markup-' is too generic.
Thomas: 'fragment-'?
Mike F: What about 'portlet-'? 'markup-fragment'?

Resolution
'fragment-'

Pending resolutions

19 initEnvironment verbiage
Andre: Wanted hints
Rich: better defined semantics.

23 markupParams has requestParams
Mike F: Pending discussion of new action model

84 Add string clientAuthType
Alej: the set of possible types is extendable?
Rich: Yes

90 when do templates get sent to Producer
Rich: In markupParams

104 Multiple means of Consumer supplying profile ID
Yossi: Present wording in section 10.2 is ok, might want to change SHOULD (require end-user to supply identification...) to MAY.
Rich: No objections.
Mike F: Why 'require'? Shouldn't it be 'request'?
Rich: Particularly if it becomes MAY.
Mike F: Carrying user ID in the protocol is still very ambiguous.
Rich: Currently carried as profile key.
Mike F: Does the spec give enough semantics for Producers to reliably establish user identity?
Yossi: We said we'd use WS-I for this.
Mike F: Not yet available. In the interim, it would be better for us to more tightly define this. Such as a Principal ID.
Yossi: Conceptually, such a Producer is operating in an extended manner.
Sasha: What Mike wants is a key that's tied to LDAP, or some other external system?
Mike F: My basic question is whether the Producer has access to the Consumer's authenticated user ID. Effectively, the answer right now is no. The Consumer is free to send anything it wants, according to the spec. So why should the spec say anything about user ID now? Just rely on vendor extensions for now, and eventually standards (SAML, etc) will catch up.
Yossi: (in response to proposed renaming to principalID). Think it's unwise, there's some debate about the meaning of principalID.
Sasha: Agree with Yossi. Also, we also use 'profile' extensively.
Alej: But this is not interoperable.
Mike F: Since it's part of the userContext, why not just call it ID?
Resolution
Rename to ID, remove extra verbiage.

105 releaseRefHandle?
Rich: Currently no such operation. If we want to have it, it would go in the markup portType
Mike F: Not in this version. Want to see justification...why wouldn't timeouts handle the cleanup of old transient state?
Andre: Disagree.
Mike F: Not really opposed to its inclusion, other than this adds additional implementation. Spec should be clear as to what effects on the entity, if any. Would look a bit better anyway, since most refHandle operations end up being side-effects.
Rich: Would prefer we wait until our in-depth discussions tomorrow.

106 entityHandle definition within registration context
Gil: Even if relationship is created out-of-band, this context still exists.
Mike F: We don't require registration. Nor do we require that a Producer somehow distinguish between different Consumers.
Rich: Could be that the scoping here is really to the Producer. If an optional registration context exists, then that could be the narrower scope.
Raj: Why would a Consumer need to worry about registering with a simple service?
Rich: It wouldn't. This issue was raised relative to the entityHandle returned by cloneEntity().
Resolution
Add language for the no-registration case

108 entityStateChange defaults to OK
Rich: Default==Fault leads to a great deal of work.
Mike F: 'Fault' is easier to debug. 'OK' could mask bad writes. But everyone will be setting this explicitly anyway.
Andre: 'OK' as default is the common runtime case.
Rich: We could make this required, and have no default. Force an explicit setting.
Resolution No default, force explicit setting

109 clone-on-write refers to entityHandle
Rich: We may revisit this, and add an operation that refers to session clone.

115 GET forms disallowed in markup where there's url rewriting
Gil: Disagree here, we're closing the door on a whole set of legacy applications. If the Producer is url-rewriting, then it could do GET forms, encode hidden fields. If Consumer is url-rewriting, then it wouldn't be possible, so those apps need to be re-implemented.
Rich: What you're asking for is a statement that describes the consequences for implementers?
Sasha: If the Consumer is 'well-behaved' and encodes its params before the query string, then GET is supportable.
Yossi: Would like to analyze this better, and truly distinguish supportable from un-supportable uses of GET.
Rich: The Consumer has to help out by declaring its urls are GET safe.
Rich: Should add paragraph to section 9 describing difficulties in using method==get and registrationData field for methodGetSafe.
Gil: It will be difficult for the Consumer to pre-determine that it's GET-safe, so why have this metadata?
Yossi: Encoding params in the path isn't good HTML practice.
Sasha: That's only one proposed solution. There are other solutions (e.g., morph to POST), so there is no reason for the spec to disallow GET forms.
Gil: Registration is optional, so how does a Producer get this metadata from unregistered Consumer? This is a more general problem, not just related to GET safe.
Rich: If this is required information, then in-band or out-of-band the information needs to be conveyed to the Producer.
Andre: Wouldn't it make more sense for this to be entity metadata anyway? (e.g. usesMethodGet)
Joe: Doesn't adding more metadata like this (i.e. flags to signify different types of behavior) make interoperability more complicated?
Sasha: Short answer: Yes.
Andre: To maximize interop, use POST.
Straw vote:
Entity metadata to indicate it sends back GET: 6
Require consumers to make method GET safe: 6
GET shouldn't be there: 1
Thomas: It would be ideal for Producers to use POST.
Sasha: One of the benefits of GET is for bookmark/refresh.

Tuesday, 11/5/02

Roll

Unfortunately, I lost the detailed notes from this day of the meeting. Please refer to the slides for the issues discussed today.

Wednesday, 11/6/02

Roll

#97 Caching proposals
2 proposals. 1. Schema in 0.7 and 0.8 2. Modified proposal from Yossi that treates items from current draft as scopes and introduces InvalidationKeys.
Gil: Common web app caching mechanism is not expiry, but invalidation based.
Carsten: That's why the proposals contain cache hints. The "input space" is too large to calculate a key.
Gil: Hinting is a good approach, though there is no certain algorithm that's going to cover.
Sasha: Actually expiry caching is used extensively. (if not modified eTag). This introduces a "round-trip" for validation.
Mike F: Yossi's proposal is for invalidation-based caching.
Sasha: Haven't figured out how invalidation-based scheme intersects with validation/expiry mechanisms.
Mike F: Hierarchy...expiry -> hints -> state (scope) based -> "catch-all" action-based expiry (reset all). The problem with hints/state levels of this hierarchy is that it forces the Consumer to "know" details about the caches.
Sasha: Review Yossi's proposal?
Mike F: MarkupResponse includes markup scope (User, Producer, refHandle, Registration). Invalidation tag prefix returned by Producer in interactionResponse to invalidate content. Consumer matches prefix "slice" into cached content.
See Yossi's email of 9/30 for details
Gil: This is an attempt to mirror http-based caching we have today, plus adds invalidation.
Andre: Concern that the invalidation tag prefix mechanism will be difficult for developers to code to.
Mike F: When used properly, it's very performant.
Sasha: If Producer uses the invalidation scheme, the Consumer MUST adhere to it. That's going to be complicated.
Rich: That's actually true of any optional (i.e. beyond expiry) caching scheme the Producer is using...Consumer MUST adhere to it.
Eilon: Registration meta-data will help to inform Consumer what it has to do.
Thomas: No micro-flags for fine-grained cache control. All or nothing. Should simplify Producer implementations.
Mike F: So what's more elemental (in terms of industry usage today) is pure expiry, or expiry + validation (eTags). For a Producer that wants to be extremely performant (i.e., a "home page" portlet), an invalidation mechanism would be nice to have, although that's certainly a more complicated scheme for the Producer to implement.
Rich: Could a Consumer that wants to do invalidation-keying signal its capability to the Producer?
Gil: Invalidation seems like a v2.0 consideration.

#45 Signal state change in InteractionResponse
How "sticky" is navigationalState? Or, how long does the Consumer need to remember navState?
Mike F: Understand maintaining state within the context of the aggregated unit.
This is related to the question of the Consumer MUST remember the last navState, in the event no navState gets returned in an InteractionResponse. Does this potentially imply Consumer session?
Gil: No, null navState is an "alias" for "give me what I sent last time".
The other question is what the meaning of null navState in InteractionResponse means? Must it always mean the Consumer manages the navState between invocations?
Mike F: There are useful scenarios for this to actually mean "null" or no state.
Eilon: Make it a required field, so "null" is no longer available. So, return "empty" to signify no state.

#100 Entity property model
Slide depicting various property structures.
Gil: The "reset" attribute on Property doesn't make sense for getProperty()?
Bruce: May just want a separate interface to reset properties to default.
Gil: for getEntityProperties, the signature includes a propertyList. No reason to include property values in this call.
Charlie: Don't recall why the working group chose this, but it should be ok to revert to a list of names.
Looking at proposal for <wsrp:localization/>
Bill: Why are we inventing a WSRP version of resource localization? Are there other standards that we should be waiting on?
Charlie: How can we go out without support for internationalization in 1.0?
Mike F: Vendors already have internationalized products, so for us to propose spec that doesn't permit portlets to make use of this capability is a non-starter.
Rich: Summary of the open questions, and we'll vote later in the week:

1. Indicate desired locale of requested descriptive resources, with localization URL that points to a structure containing full localization information? Or include full locale data for all supported locales inline when getting a descriptive resource.
2. Do we invent a new localization scheme for WSRP, or do we use xml-lang?

#91 setEntityProperties atomic?
Atomic..but not transactional.
Carsten: Difference between atomic and transactional?
Bruce: Use case for atomicity of property changes? All-or-nothing truly required?
Rich: Consumer-managed properties, especially if they're a hierarchy, is one.
Mike F: So, "synchronized" may be a better term.
Rich: Validated and synchronized update, not required to be transactional.

#120 PropertiesDescription not in entityDescription?
Gil: It's potentially too large, not all Consumers need/want property description whenever they get an entity description.
Bill: Maybe we should consider the general problem of specifying (micro flags?) what should be included in the response to any request.
Rich: Our approach has been that unless TC folks indicate something really is mandatory in a given resposne, then it gets separated (with separate API to retrieve it).

#96 Review well-known URL param names
Mike F: Don't understand 'wsia:refHandle'. The spec already mandates that the Consumer has to return the refHandle on all requests, so why does it belong in the Producer-rewritten URL?
Andre: Wondered why this wasn't entityHandle?
Mike F: It's not specific enough.
Rich: Consumer needs to supply the indirection of refHandle, since it can change on a getMarkup.

#35 Is 'recommend' strong enough for URL-encoding statement
Consumer needs to know what the character encoding of the parameters is.
Mike F: Suggested solution is to mandate that encoding, UTF-8. Consumers will therefore always know what the answer is.
Gil: This isn't important for Consumer URL rewriting?
Mike F: Not always true, there are places where the Consumer requires the Producer to do URL encoding.

2 proposed mechanisms:

1. Mandate: UTF-8
2. URL itself carries the information. Add a token, 'charset', that the Producer re-writes with the encoding.

Sasha: Dislike #2. You need to parse the URL to find the charset. Not normal behavior that off-the-shelf parsers will take advantage of.
Gil: So #2 could really be viewed as a Boolean. Either the markup is returned in UTF-8, or it wasn't.
Mike F: Correct, although you lose the particular charset in use.
Vote: 1: 1 2: 17 Abstain: 5

#138 URL templates for performInteraction?
Mike F: Think it's natural in markupParams.
Resolved: Yes

#129 Double-encoding of wsia:url
urlType==resource, so it's an embedded URL. Problem is conflicting levels of encoding.
Rich: If we change verbiage to mandate "strict" URL encoding, then double-encoding isn't needed.
Resolved: Producer does strict encoding (i.e. make it a valid query string value ... encode '&', '=', '?', ':', '/' and '?').
Mike F: For both Producer and Consumer URL's?
Rich: Since it's the template that's being replaced, the Producer must always do this.

#146 Require urlType token be at beginning of URL sequence
Efficient parsing.
Sasha: Enforcing an ordering could be a problem for debuggability.
Mike F: Not a debugging issue, since if it's missing it's easily logged/found.
Rich: Suggest: /wisa:rewrite?urlType&wsia:url...
Resolved.

#131 wsia:requestParameters should be double-encoded
Gil, Sasha: What is requestParameters again? Isn't this navigationalState?
Rich: It's where the Producer puts any "extra" query string parameters.
Gil: So these shouldn't be double-encoded.
Resolved: Change 'doubly' to 'strictly'.

#37 & 128 Using predefined namespace prefixes is unconventional
Switch to 'XXX-'
What XXX will be is for Friday.

#63 Entities / Window states
Lingering issue: What are the semantics of the Consumer refusing to change window state?
Mike F: Some confusion over window states...is it a state? Or is it a style?
Rich: It's a state that implies a style.
Mike F: Consumer refuses, then it should immediately call getMarkup.
Gil: How typical would it be for the Consumer to refuse a state?
Mike F: If the Consumer receives a request for a state it doesn't support.
Sasha: This seems very unlikely to occur. Leads to complexity on both Producer and Consumer.

#102 Difference between Edit and Config
Resolved: Drop Config

#114 Should custom roles, modes, window states be namespaced?
URI's are encouraged.
Gil: The standard roles, modes, window states aren't URI's. We're not eating our own dog food.
Resolved: Leave as is.

#48 Should an entity state that it is cloneable?
Sept F2F said No. We've also changed cloneEntity to take an entityHandle, and not a refHandle.
Mike F: So, should we recast this into "should an entity's transient state be cloneable"?
Rich: Separate issue.
Resolved: No, per 105 below.

Pending resolutions

105 Add releaseRefHandle(refHandle, registrationContext) to Markup portType
Mike F: Should it take an array of refHandles?
Resolved. ReleaseRefHandles(refHandle[], registrationContext)
Vote: Yes: 11 No: 8 Abstain: 5
Not-present voters will have a chance to vote next week.
CloneRefHandle?
Eilon: Not well named. It's the underlying entity that gets cloned, and a new refHandle gets created to reference it.
Discussion regarding the use of cloning transient state. Consumer manages property changes, user edits an entity, and entity gets cloned: should also "clone" (really, transfer) the refHandle to the new clone so that the user's current runtime state is preserved.
Resolved: Not in this version.

115 GET Forms
Proposals:

1. Consumers SHOULD support method=get
2. entity metadata usesMethodGet and URL template structure: www.consumer.com/_{wsia:requestParameters}/

Mike F: What are the use cases for supporting GET at all?
Sasha: The fact that it does have different behavior then POST, and it's heavily used today (e.g. Google).
Yossi: We will encourage Producers to use POST?
Rich: Yes.

98 Should operations (other than getProperty) return Entity property values?
No.

99 Should property operations optionally take a user context?
Yes.

#150 Use a SOAP fault to indicate a redirect
Mike F: Redirect means ignore every other param in the response. Unconventional.
Andre: .NET doesn't honor faults, or at least not very well. It would not be usual to carry useful data like the redirect URL in a fault.
Rich: The suggestion really boils down to dividing the InteractionResponse.
Mike F: Proposed SOAP fault only as a means of illustrating the issue.
Sasha: You're also supposed to send back content that could be displayed.
Resolved: Divide InteractionResponse into a choice: normal semantics or redirectURL.
(Does anyone really need new mode, new window state, etc., along with a redirectURL?)

#111 getMarkup called for MINIMIZED
Language suggestion: [see slide]

#153 Remove "extension" fields from ServiceDescription and RegistrationData
userProfileExtensions, consumerExtensions, registrationProperties in RegistrationData
registrationProperties in ServiceDescription.
Mike F: These could just live as standard extensions, and the fields should be removed.
Yossi: Makes life a bit more difficult, since Consumer now has to hunt for entity's extended user profile attributes (for example) in the extensions.
Rich: consumerExtensions was brought up long ago, not sure anyone has found a real use for it.
Charlie: registrationProperties appear to be very close to wsdl endpoint properties. We need to be clear that they are not.

Resolved: ServiceDescription.registrationProperties of type ModelDescription
Drop consumerExtensions.
Mike F: Rename userProfileExtensions to remove the "extension". (customUserProfileData?)

#118 RegistrationData.userProfileExtensions[] needs description sub-element
Mike F: Human-readable description? This should be an extension.
Resolved: Leave as String[].

#130 minimal encoding of URL rewriting params
Add ":"

#101 Valid values for MarkupParam fields in spec examples/references.
See 0.8 draft, email suggested changes to Rich.

#117 Markup interface should be first described in spec
Keep as is

#137 Require "DefaultTemplate"
Two different ones (secure/unsecured)
For case where Producer rewriting requires templates, but Consumer didn't pass any.
Mike F: Doesn't seem useful for 1.0 timeframe.
Rich: Either Consumer sends defaults, or the full list of templates (MUST)

#151 Clear list of Consumer and Producer requirements
Resolved: Separate document to provide guidance to implementers.

#139 Delete unused glossary terms
Keep 'Action' as a synonym for 'Interaction'.
Mike F: We also need a term for "portlet instance" based on yesterday's decision to optionally carry a portlet ID.

#134 use of the GUEST role
If there's no user ID, what's the value of carrying the GUEST role?
Mike F: This is a role that applies to this user, regardless of the portlet he uses.
Alej: Can a profile key be shared by multiple users?
Yes.

Thursday, 11/7/02
Roll

Rich: We resolved 31 issues yesterday...unfortunately most of them were the easier ones.
Mike F: Make sure everyone realizes that without groupID, must rely on transport level mechanisms (or extension) to support shared sessions.

#140 Internationalization
Inline vs. separate resource. Uses xml:lang, so we're not inventing a new localization mechanism.
Sasha: Set of property descriptions could change?
Rich: Yes.
Sasha: So localization resource would have to be dynamic as well, synchronization issue.
Eilon: Also since description can be filtered, localization resource would have to be similarly filtered.
Rex: Clear performance difference between the two?
Sasha: Yes, although dependent on network considerations...so it's probably a wash.
Rich: One implication of choosing separate structures is a new operation to get localization.
Charlie: "factored" inline is a 3rd approach, which includes localization resource in the same document, without localization URI.
Vote: Inline: 17 Separate: 3 Abstain: 2
Rich: 2nd question: format of the inline for tooling purposes. Won't accept xml:lang with a type attribute. So we need indirection through resources.
Vote: Indirection: Yes: 12 No: 7 Abstain: 4

#149 Should get/setProperty take locales?
Mike F: This opens the question of a user being able to have different preferences based on locale.
Gil: Oppose this layering of properties by locale.
Bruce: Haven't seen this in anyone's notion of properties.
Vote: Yes: 4 No: 14 Abstain: 2
Rich: In the get__Description operations, must take a desiredLocales[] and sendAllLocales.
Andre: Why doesn't user profile carry the user's language?
Rich: The request may not be on behalf of this user.
Eilon: Is there a default Consumer locale?
Rich: This could be the zero-th element of the array (spec should reflect that semantic).

#100 Entity property representation
Keep the reset attribute in the Property list?
Gil: The list has multiple usages, and this attribute wouldn't always make sense. If we want this capability, make it a flag or a separate operation.
Rich: Could create a <ResetProperty> sub-element of PropertyList.
Mike F: Why not a formal method?
Rich: An Edit could comprise several sets and resets, and this gets submitted as a single operation.
Eilon: Restructure PropertyDescription to make some of the attributes into sub-elements, to enhance relatedness of some of them.

#147 MarkupType in MarkupParams should be an array
Eilon: Supported markups for an entity defined?
Rich: In metadata.
Bruce: Like an http accept header?
Rich: Yes.
Vote: Make both MarkupType and Locale are arrays, and the order is by preference. Y: 13 N: 4 A: 3
Sasha: Do we allow "*" like in the accept header? (Vote: Y: 9 N: 3 A: 9) Is it a MUST for the Producer to return a markup that's in this list?
Mike F: Should leave it as mime types right now. Can always extend.
Rich: Doesn't hurt, and it carries forward well-understood mechanism (accept header).
MarkupResponse also needs a markupType and locale.

#144 define bindings for SOAP attachments (#148)
Rich: Benefit is that portions of what is transferred can use different encoding.
Andre: Are we mandating use of attachments if content is sent in a mime type that isn't in the MarkupType array from issue 147?
Mike F: No, not mandating.
May need to hold on this pending standards maturity (SOAP and DIME).
Mike F: No, we should specify bindings for both, and neither spec appears unlikely to proceed. This is very important for our (Oracle's) implementation.

#59 Interface discovery
Mike F: Don't understand the wsdl field at the entity level. Why wouldn't this be an extension?
Carsten: Interface discovery at the entity level...what portTypes are available at the entity level?
Mike F: This is not true for the WSRP portTypes, that can only be discovered at the Producer level. So for an entity that exposes custom interfaces, that should be information that's available in extensions.
Gil: This isn't a WSRP discovery mechanism. It's a SOAP mechanism.
EntityDescription: Drop: Y: 10 N: 2 A: 8
ServiceDescription: Drop: Y: 9 N: 9 A: 3

#85 refHandle/expires MUST/MAY contradiction
Consumer MUST return refHandle when Producer sends one, except in a couple of circumstances.
Gil: Should reword to explain what happens when the Consumer throws away a refHandle.
Mike F: Would be happy with same wording we use for registration. I.e. the Consumer is free to ignore the refHandle, as it is free to ignore a Producer (i.e. never deregisters, or attempts to unsuccessfully). It's important for Producers to be aware that this can occur.
Rich: releaseRefHandle may impact the wording.

#74 Should the Consumer MAY or MUST destroyEntities?
Mike F: Basic question was when the Consumer may consider that a release operation has been successful...i.e. must receive indication of success.
Sasha: There are cases that the operation will never succeed...catastrophic failure, fire, etc.
Rich: The requirement is for the Consumer to attempt to release a handle.
Mike F: Without the burden of going on to specify # of retries, and how long in between, etc.

#57 Unification of session and entity handles (#142)
refHandle.
Refined from 0.7 to 0.8 as entityStateChange proposal evolved.
Mike F: Now that cloneEntity no longer takes a refHandle, it isn't an issue.
Yossi: Combining the handles is a problem in terms of length restrictions.
Sasha: And it's complicated the spec.
Charlie: But they truly are correlated, so it makes sense for them to be combined.
Rich: Related question, that the restriction on handles doesn't need to apply to refHandle as a runtime.
Vote: Keep refHandle: Yes: 10 No: 8 Abstain: 2
Since this (and a couple of other) votes are so close, then we should open an email vote on just these issues.
Gil: There is a problem with the combination of 256 as the max length of a handle, and a vote in favor of keeping the combined handle.
Rich: The choice must be 1. sessionId < 256/split: 11 2. 4k, unified: 7 Abstain: 3

#141 IPR Statements
WebCollage will publish licensing terms.
IBM's statement pending, will probably be similar to ebXML, CPPA.

#145 Should sample implementation only implement JSR 168

Markup encoding vs. message encoding
Attachments (or new MarkupResponse field?)
Sasha: Either an attachment or base64 should solve this.

Should fault codes use our types namespace and drop the leading WSRP?
Yes.

List fault codes with operations
Yes.

Is Extension[] needed everywhere?
Specifically, includes nested structures.

Other metadata?

What does xxxx in xxxx- mean?
Gil: The basic issue is, what is the name of the final spec? This is a joint spec. 'wsrp' is too specific to portals/portlets.
Charlie: One obvious answer: wsrp.
Sasha: That it's a joint spec is unimportant.
Bill: Anything other than 'wsrp' as the choice doesn't reflect the group that created it.
Bruce: Should change the 'P' in WSRP to 'Portlets'?
Adopted
Re-vote on CSS style prefix now that we've selected WSRP: portlet-: 14 fragment-: 4 Abstain: 4

#66 Review interfaces

#104 profileKey
Mike F: Impact of SAML on user identity
Andre: Can we strengthen the "authenticated" aspect of profileKey?
Gil: That's too strong for the spec. Typical usage will be that this is an authenticated key, but that's not always the case. And even if it is authenticated, the spec can't say the Producer can rely absolutely on the Consumer authentication.

Done with issues!

Next Face-to-Face
SAP, Palo Alto, will host.

Timeline

November 22nd Draft 0.9

December 16th TC provides all editorial comments
Last additional technical issues raised by exception

January 7th Finish draft 0.91 reflecting editorial comments.
Put Draft 0.91 on WSRP web site for public comment

January 27th - 30th Face-to-Face Palo Alto
Finalize 1.0 Specification. Discuss 2.0 direction/concepts and compliance test kit, time permitting.

January 31st Release 1.0

??? OASIS Standard (~March)

WSDL Testing
Rich, Andre, David (Oracle), Richard

Conformance document
Defines requirements for a Consumer and Producer to be in compliance (Gil, lead)

JSR 168 Implementation guide
Thomas: Also an implementation guide for mapping WSRP to JSR 168 (Mike F., lead)

Adjourn