[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes Feb 14th
_________________________________________________________________ Martin Chapman Consulting Member of Technical Staff Oracle P: +353 87 687 6654 e: martin.chapman@oracle.com
Draft Minutes WS-CAF conference call : 14 February 2005 ---------------------------------------------------------------------------------- Meeting was quorate. See attendace data on calander event fro this meeting: http://www.oasis-open.org/apps/org/workgroup/ws-caf/event.php?event_id=4148&; Peter Furniss (Choreology) agreed to scribe. The agenda was approved then Martin summarised what was in it. Minutes from f-t-f not yet consolidated. Review of f-t-f --------------------- Eric's summary: Most of the time was spent addressing and trying to resolve ws-cf issues. The plan is to get an updated editor's draft to be progressed at New Orleans. Closed out a number of issues, and discussed how to progress the specification. Worked out draft schedule for ws-ctx and ws-cf drafts, incorporating resolved issues. Next draft is planned 11 March 05 and then again a week or so before next f-t-f, for possible approval then. Many issues did not require discussion, some did. Editors had a lot of action items. Separate editors' calls since to apportion and progress that work. Review implementation sub-team ----------------------------------------------- (not time for this at f-t-f) Since Malik left, this group has not been very active. Request for someone to run this sub-group. Anyone like to volunteer today? Mark volunteered Kevin (Connor - who was not on the call). Mark proposed Kevin Connor; seconded Pete Wenzel. APPROVED, NEM CON. Simeon reported informally: not much since Washington DC (no meetings since then). Not yet updated to new schema and WSDL (lack of support for WS-Addressing spec), nor got a context-manager using app. ACTION: Kevin Connor (as sub-team leader) to work out plan and report to next meeting. WS-Context issues ---------------------------- Some issues form Anish Karmarkar (Oracle), not yet in bugzilla, but document referenced on agenda. Refer to: http://www.oasis-open.org/apps/org/workgroup/ws-caf/email/archives/200501/msg00032.html 1) The normative WSDL (and schema) is a separate file, which is good as tools can access just the WSDL and process it. But the same normative WSDL (and schema) should be included in an appendix to make the spec complete. If using XML, this will require just a simple tweak to the XSL (and result in just one WSDL source -- reducing maintenance problems). RESOLVED at F-T-F. 2) The spec does not use the standard OASIS format which contains line numbers. EDITORIAL 3) Section 1 (heading) is missing, the spec starts straight with 1.1 EDITORIAL 4) Appendix A should not be section 9? EDITORIAL 5) In "Note on terminology" it says: "Namespace URIs of the general form "some-URI" represents some application-dependent or context-dependent URI as defined in RFC 2396 [3]." Doug: is this editorial, or a proposal about the terminology. Mark: it is just editoral AGREED EDITORIAL (Replace "some-URI" with "http://example.org/..."; and http://example.com/...) 6) Section 1.1.1 Prefix Namespace table should be expanded to include the prefix "soapbind" and "soap" and an entry for wsrm referencing scheme. Also the prefix "tns" has the namespace "targetNamespace. The tns entry should be moved outside the table with an explanation since "targetNamespace" is not a namespace URI. EDITORIAL 7) Section 2, line 2: s/operations/interactions EDITORIAL 8) Page 6, line 2 talks about SOAP messages. Is the specification independent of SOAP? It certainly seems like it is independent of SOAP, but there are statements like the one on page 6, line 2 which leads one to believe that this is meant only for SOAP. If the core part of Context is independent of SOAP then it would help to clarify this and specify a SOAP mapping in a separate section. It would also help to make some statements about SOAP 1.1 as well as SOAP 1.2. RESOLVED at f-t-f 9) Section 2.2, page 6 does not say anything about WSDL 2.0. It would be good to separate WSDL 1.1 and 2.0. The normative WSDL is indeed 1.1, but the wording in section 2.2 talks about WSDL generically. Previous decision was to target WSDL 1.1. EDITORIAL CLARIFICATION/restatement 10) Section 2.3 (page 6), refers to WS-CAF. This is the first reference to WS-CAF. It will throw-off the reader unless she knows the name of the TC. Suggestion: s/WS-CAF/this specification. EDITORIAL, but the text needs to explain what the CAF family is. 11) Figure 1 (page 6), the title "service-ref Element" is incorrect. There is only a complexType defined in the figure. EDITORIAL 11) Figures/XML snippets typos: some of the xml/wsdl/soap snippets are not valid XML. Verifying the examples with a parser would help avoid typos. Examples of invalid example: page 6, figure 1, last line (closing '>' missing) page 9, figure 5, 6th line (invalid schema type) EDITORIAL 12) Consistent indentation in the examples would help readability. EDITORIAL 13) In the spec text using a different font/bold/italics/emphasis for XML element names/attributes would also help readability. It would also help to prefix the element names/attributes with the "ctx:" prefix (or whatever is appropriate). EDITORIAL 14) page 7, first paragraph refers to "WSRef defined in WS-Addressing" (WSRef is used again in the following paragraph as well). I suspect the first occurrence really means wsrm-ref:reference-scheme and the second occurrence means a 'Web service reference'. EDITORIAL: Covered by existing issue on WS-Addressing 15) page 7, 2st para: s/reference schema/wsrf-ref:reference-scheme EDITORIAL 16) Figure 3, page 7: (dup of 17) 17) Figure 3 and figure 4, page 7, it is not clear to what the prefix "ex:" refers. EDITORIAL 18) Page 7, paragraph right below figure 4 says: "A service that requires a service reference element MUST use the mustUnderstand attribute for the SOAP header element within which it is enclosed and MUST return a mustUnderstand SOAP fault if the reference element isn't present and understood." I don't understand what this means. How does MU header help here? Discussion - not clear. FILE AS AN ISSUE ACTION: Greg and Doug assigned to provide solution. 19) It seems like the design point of the specification is one-way messaging, which certainly makes sense. But the normative WSDL that is provided essentially prevents someone from using SOAP-over-HTTP request-response MEP. For some operations like get timeout this may indeed be feasible. Is that really the intent? Covered by ISSUE 124 (discussed at f-t-f) 20) page 8 is blank EDITORIAL 21) page 9, bullet regarding context-manager -- It is not clear whether this element is required to be present if it is pass-by-reference. It is clear that if this element is present then it is pass-by-reference. EDITORIAL - clarify prior agreement. 22) page 9, bullet required timeout -- what are the units here? seconds? Why not dateTime? Or option for both? FILE AS ISSUE 23) page 9, bullet required wsu:Id -- why is this needed? Why not have attribute extensibility (xs:anyAttribute) and leave it at that. PREVIOUSLY DISCUSSED (Tony's comments) - relates to WS-Security and signing of headers. Tony agreed that there was a point to using wsu:Id even though it maps directly to xml:Id because of expected security tool behaviour. DUPLICATE OF CLOSED ISSUE 24) figure 5, page 9 -- why is element extensibility (xs:any) at the beginning of the sequence? The norm is to place element extensibility at the end of the sequence. DISCUSSED - Tony: believed forced by XML schema and extensibility rules as the 'any' is in the element which is being extended. Also putting at the beginning or the end helps with 'particle attribution' problems as there is a defined boundary before or after the 'any' and that just leaves the following or preceding element to worry about. Doug: requirement is that receiver must be able to distinguish what fills the 'any', if anything, and arbitrary number of existing preceding and following elements so ordering does not really help on this. Other specs have their extension point at beginning or at end - no "normal" pattern. STATUS QUO AGREED. 25) figure 6, page 10 -- having arrow-heads on the lines would help readability. EDITORIAL 26) page 10, paragraph below figure 6 says: "If the context-manager is dereferenced, it MUST return the entire current contents of the context, i.e. the values corresponding to the context's ContextType elements held by the context service at the point of receiving the dereference message." Seems too strict. How about: When the context-manager is successfully dereferenced to get the contents of the context, the context-manager MUST return the .... OR If the context-manager is dereferenced to get the contents of the context, the context-manager MUST return the current contents of the context or fault, i.e. ... The concern is that the statement as stated in the specification is too broad. It does not take into account the fact that the invoker may not have the right privileges or some other security related problem. EDITORIAL 27) page 10 says: "A service that receives less than the minimum context MUST return a mustUnderstand exception when the mustUnderstand attribute is present." Why? This seems like an abuse of MU fault. Or is this talking about a ws-context specific MU fault. I assumed it meant a SOAP MU fault. FILE AS ISSUE 28) section 3.1, page 10 says: "As mentioned earlier, ..." include a reference to the right section. EDITORIAL 29) section 3.1, page 10 says: "These semantics are indicated in a context by a protocol identifier representing the protocol type of the activity." add "by the ctx:type element" for clarity. EDITORIAL 30) page 11, 2nd paragraph leads me to believe that multiple ws-context SOAP header blocks are allowed in a SOAP env. Is that correct? EDITORIAL - yes multiple ctx are allowed, clarify 31) page 11, 3rd para: s/which may be/which may vary from EDITORIAL 32) Section 3.2, page 11 There seems to be some misunderstanding of how SOAP MUs work. A SOAP MU says to the actor/recipient that you must understand what this header block means which typically means understanding the header block QName and recognizing what the specification related to the QName requires the processor to do. It is possible that while processing the header block there may be problems/faults such as not understanding the identifier type (which is an extensibility point in the header block). In such cases, the process will throw some header block specific fault and not an MU fault. FILE AS ISSUE 33) figure 7, page 12 Extraneous 'CTX' in the title EDITORIAL 34) figure 7, page 12 All application specific URI should use http://example.org/... or http://example.com/... URIs and not http://docs.oasis.org/... URIs EDITORIAL 35) Section 4, page 13, reword line one. EDITORIAL 36) page 13, 1st note: add a forward reference to the right section EDITORIAL 37) Figure 8, page 13, the dotted arrow is titled "context generated" this title is misleading. It should be "Context Manager generated". EDITORIAL 38) page 13, 1st bullet (regarding getContents): s/it/ContextManager EDITORIAL 39) page 13, 1st bullet (regarding getContents): where are the faults sent? To the same place as where the context contents would have been sent? Or is this binding/MEP dependent? I assume that this is binding/MEP dependent. COVERED IN ISSUE 225 (?) (up to addressing scheme to deal with this) 40) I assume that for the context-manager operations some form of message correlation is required (part of the call-back mechanism) i.e., [Relationship] property in WS-Addressing or RelatesTo property in WS-MessageDelivery. This would also require that message identifiers also be present. ALREADY COVERED - 41) Figure 9, page 14: it seems odd to define a separate message type and an operation for every fault. Can this be combined into one? COVERED BY ISSUE ON FAULT ARCHITECTURE (209, 238?) ACTION: all to have action to look at WS-RF base faults) 42) Section 5.1, page 15 says: "... there is no notion of automatically informing services when a specific state is entered." It would be worthwhile to mention that other specs may define how this is done and as far as this spec goes it is out-of-scope. REJECTED 43) Section 5.1, page 15, 1st paragraph below the XML snippet says: "The namespace attribute is used by referencing specifications to qualify the value of the status string." Why is this a NS rather then just a URI. If the status values are namespace qualified then why not have them as QNames? RELATES TO ISSUE ??? / or July f-t-f 44) Section 5.1, page 15: given that the namespace attribute is optional, what happens if it is not specified? Are the values specified in the spec (activity.status.ACTIVE etc) in no-namespace? FILE AS ISSUE 45) Need more example SOAP messages for context manager and context service (at least in the appendix) -- would help readability/understanding. EDITORIAL 46) section 5.2, page 16 says: "Since the Context Service maintains information on multiple activities, an activity context MAY be present on some operation invocations to determine the appropriate activity on which to operate." Why is the activity context not always required? How does the service figure out the context with it? OPEN ACTION TO PRODUCE TABLE OF WHICH NEED/MAY/DO NOT NEED context Meeting closure At this point the meeting was out of time and so was closed. Mark agreed to complete this exercise and propose whether each of the remaining issues from Anish can be dealt with be the editors, or need discussion by the group. ACTION: Mark to assign propose which of Anish's issues 47 to 57 can be dealt with by the editors and which need discussion by the group. APPENDIX Anish's issues 47 to 57 47) Section 5.2, page 16 the text uses the terms UserCTXService and CTXService where as figure 11 uses UserCTXServicePortType and CTXServicePortType. 48) Section 5.2, page 16, last sentence: s/we shall describe the interactions in the following section/the interactions are described in the following section 49) Page 17, bullet regarding (UserCTXService): a) It is not specified which operations in UserCTX correspond to which operations in CTXService (other than being obvious from the names) b) It seems strange to define an operation for every fault. Can this be combined. c) There is no explanation for the fault operations. d) What is special about no permission faults? There are several security related faults that can occur. It is not clear why no permission fault is the only one included. e) How are faults that are not listed in the spec dealt with -- is there a generic fault operation? 50) Page 17, begin: s/If nesting of activities is not supported by the implementation/If nesting of activities is not supported by the implementation and there is a nested context specified 51) page 17, begin: What fault is thrown if -1 is specified for timeout and the implementation does not support the semantics of -1? Is it timeOutOfRangeFault? If so, the name of the fault is misleading. 52) page 18 and 19: A better name for 'setTimeout' and 'getTimeout' operations would be 'setDefaultTimeout' and 'getDefaultTimeout' 53) page 19, getTimeout says: "This need not be the value associated with the current Activity, however." It is unclear what 'current Activity' means here. 54) Section 6, page 20, 2nd line: s/SOAP header/SOAP header block 55) Section 6, page 20: Why is wsu:Id special? Why not use attribute extensibility? 56) Section 6, page 20 says: "In addition to any authorization checks it may perform on the sender of a message, it is RECOMMENDED that applications services perform checks that contexts were created by authorized issuing authorities." Is there any guidance that can be provided here? 57) Section 7, page 21 says: "All messages based on the normative WSDL provided in this specification MUST be augmented by a Web services addressing specification to support callback-style message exchange." The normative WSDL is not included in the spec. ACTION: Mark to propose way to dispose of remaining issues from Anish AOB ------- none, meeting adjourned.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]