Minutes of 2001-04-11 XMLP WG teleconference held on 11 April 2001

1. Roll Call:



David F. stated that we would skip agenda item 3, approval of 4/4 minutes and
         table that item for next week.
David F. described agenda item 5, indicating that the AM items appended to the
         agenda which were unassigned or would be underrepresented in this
         telecon must be reviewed and possibly reassigned.
NO "other business" items were raised for addition to the agenda.


3. Item tabled for next week.



Action items below were discussed in order based on the action item list.
Action item 1 - Henrik had not received the updates on this item from Noah 
        yet, could not confirm whether or not Noah had sent him the updates,
        so the action item was marked PENDING.
Action item 2 - Marked as PENDING per item 1.
Action item 3 - David Clay sent regrets.  It was asked if anyone could speak 
        on this.  Paul Denning noted that he had worked within the group but
        did not think that he or anyone but DavidC could fully speak for this
        item.  Item left PENDING.
Action item 4 - Henrik to send comments - Item COMPLETED.
Action item 5 - David Clay to define "module," - Item left PENDING. 
        (see item 3.)
Action item 6 - David F. indicated that it had been decided that someone was
        needed to populate the issues list generated by requirements which ARE
        met by the SOAP 1.1 spec. Item was assigned to Jacek Kopecky and 
        Jeff Kay to populate the issues list appropriately.


Mark Jones was asked to give descriptions of the issues, so that each could
        be discussed and assigned as appropriate.
Within the context of the discussion below, it was clarified that the 
        intent was to assign and act upon only issues which impacted the 
        publication of the AM document.

[Issue numbers used in these minutes refer to the order of the issues 
appearance in the telcon agenda.]

Mark J. - The first two issues are called out in the AM doc issues section, 
        the group felt these issues needed to be brought back to the WG, 
        they are unassigned. Issue 1 refers to the debate about the role of
        targeting blocks/processing WITHIN the envelope, and whether routing
        is a function handled within the envelope or not.  How does routing 
        happen? Waqar - commented, volunteered.  OWNER ASSIGNED: Waqar

Per similarity to 1, Waqar was suggested.
Mark J - Discussion from last week may have resolved issue 2.  He will clarify
        enough for AM spec to reach publication.  Thus, OWNER ASSIGNED: 
        Mark Jones

Mark J. - to clarify question, this is a design issue, questioning whether we
        should distinguish header blocks from footer blocks, or just have 
        "blocks," which are "mixed up."  SOAP does explicitly distinguish.
Mixed anon discussion ensued.  Comments that serializing return messages when
        independent handlers perform on header/body blocks is an issue.
Mark J. - we say that an intermediary should be able to identify and perform 
        on a subset of blocks which were targeted for them, must a handler 
        parse which blocks are meant for it? This may be a general design 
        issue, but may not stand in the way of publication. 
Henrik - not sure that this is an issue.  The spec says that we have to be
        able to syntactically separate or intermingle header and body blocks.
        SOAP says that you have a mechanism for sending body and headers,
        SOAP does allow intermingling, handleable as a special case of 
        headers. Abstractly, does not see an issue.  There of course might be
        a buffering issue in some cases but it is based on the semantics of 
         the features you are trying to serve.
Mark J - Are you saying that you could dispense with the idea of a separate 
        body to allow "intermingling?" 
Henrik - some things at the [handwriting issue here, my apologies - Shane] may
        be needed, could
Mark J. - Can intermediaries insert header blocks?
Henrik - we do not say that
Mark J. - If there is a distinction, buffering will be required
Henrik - what I would like to see is an example which shows that these is an 
David F. - What is the origin of this issue?
Mark J. - It looked to the subgroup like the distinction [between header and 
        footer blocks] was just "syntactic sugar," not needed in the 
        ABSTRACT model design.
David F. - perhaps it is not clear that this is an issue.
Mark J. - see section 3.2, it seems there is a distinction in the document of
        header and body in some of the language
Mark - do we need use cases, perhaps this is a farther-reaching issue than the
        AM? For example where the recipient of many blocks might need to write
        a header AND footer blocks which would naturally require some 
David F. - do we change the design at this point?  We have a requirements spec,
        SOAP, and use cases already.  There has already been a "high bar" 
        set by the requirements and SOAP.
Mark J. - do we take SOAP to be a "high bar" basis for our design moving 
David F. - YES, the AM is meant to be an abstract description of what 
        underlies SOAP.
Mark - this issue was a suggestion for the simplification of SOAP's design.  
        What do we do with improvement suggestions?
David F. - We need a good use case to show compelling need for an improvement.
Mark J. - is not simplification and clarity good [an improvement] on its own 
David - Re-cast this as a usage scenario, or see if it is encompassed by one.
        We will consider applying this if it is needed to help SOAP meet a USE
Mark J. - are usage scenarios a closed set?
David F. - the list is not set in stone, but we need to be mindful of 
Anon - S21 may fit this. [Some agreement that it pertains well to the 
        resultant buffering issue.] 
David F.  - is resolution of this issue required for the publication of the 
        AM Spec?
Mark J. - It sounds like the AM will inherit the header/body structure from 
David - We will give it to Mark to check this against F21, and will remove it
        as an AM issue.

ISSUE 4 - 
Mark J. - This concerns message construction.  It may impact serialization
        issues, passing of blocks... The AM does not say much about whether
        XMLP can construct..
Vidur - This is an implementation detail, not an AM issue, no?
Mark - yes, we have just a send primitive, is that the model
Henrik - yes, the handler is abstract, this is just an API/impl. issue
Mark J. - Well, the question was about multiple handlers constructing a 
David F. - Asks Paul Cotton for his advice in his role as Chair of Query WG: 
        Should we include this and resolution in the DOC publication?
Paul Cotton Advisor - Yes, it is always helpful to include such, inclusion 
        will help pre-empt such questions after publication.
David F. asks for a volunteer to write the rationale for the resolution, and 
        will include the originator of the issue in the list with the 
        resolution email.
Vidur - volunteers to craft the message to be logged as the response.  
Ray - The second part of the issue is resolved, but not the first part.
Paul - Are there ways of specifying where blocks go?  
Anon comments, editorialized: Yes, this is implied : Messages CAN BE FORMED.  
        WHERE they are formed is an implementation issue, as is HOW they are 
Paul - These are abstract operations, the answer is that no abstraction for 
        CONSTRUCTION is needed.

Mark volunteers to take this issue, STUART may have already have a resolution.
Mark will track.

ISSUE 6 - 
Mark J. - Chris' question is, if an intermediary has inserted a block, which 
        faults later in the chain, where does the fault flow back to?
Henrik - I can think of several NON request/response scenarios where this 
        issue is or is not decided based on the binding. [to the delivery 
ANON - What does SOAP do?
Henrik - SOAP reports that there was a fault, not what to do with it.  
        It includes a "suggestion" in the spec for the HTTP binding.  
ANON - The destination for reporting of faults is decided in implementation 
        based on needs and the binding.
Mark J. - Is this underspecified in SOAP, should it be more specified? 
        We have no general fault reporting guideline.
Henrik - In SOAP, you have a URI as part of the fault action, so you KNOW 
        where it occurred, and can handle it.
Mark J. - Can an application just target who should get the fault message?
Henrik - SOAP says, "this is how to report a fault," it does not require what
        you do with it.
Anon - The receiver doesn't know who is the originator of a given block, 
        unless it is explicit in the block.  [There was acknowledgement and 
        general agreement on this point - Shane]
ACTION ASSIGNED - Paul/Henrik to write up an explanation of the "out of scope"
        resolution to this issue.

ISSUE 7 - 
Mark J. - This concerns the Corrolation.Messageref parameter. Stuart needs to 
        craft an EDITORIAL correction to clarify the AM description.  
        Believe that Stuart has already clarified via discussion, is just an
        editorial action to get it into the AM.
David F. - could someone else look into that discussion and perform editorial
        clarification to the correlation.messageref parameter description 
        based on the discussion text?
Mark - when will comments/editorial issues be closed?  Can this wait for 
David F. - it has not yet been decided when, I think that we CAN leave it for
ACTION ASSIGNED - Stuart to perform editorial clarification for .messageref 
        parameter desc.

ISSUE 8 - 
David/Mark call for clarification on this issue, it is from Ray.
Ray - I felt that it might be a weakness in the model to abandon guidelines
        for request/response actions to model RPC and other messaging patterns,
        there is no explicit RPC support through the description of the 
        unitdata primitives only, aside from correlation and causality (one
        message arises as a result of another.)  This does not encompass the 
        deterministic nature of RPC, where if you send a request, you MUST have
        a CORRESPONDING RESPONSE, or you have no RPC.  The XMLP layer does not
        have any way of requiring a resultant message.
Henrik - you could have semantics requiring a non 1-to-1 message exchange 
        requirement, or any open ended requirement structure.  It would be a
        high level function to REQUIRE resultant messages.
Ray - the XMLP layer is not "aware" of such requirements, it does not know.
Henrik - the semantic of the application knows.
Ray - then XMLP does not know whether to keep the connection open, for example.
David F. - Doesn't RPC sit "above" XMLP?
Henrik - we decided that RPC is a module, no?
David F. - who will own this?
Ray - I can own this.


David - I propose that we set dates.  If we want to submit for publication 
        before the 20th, we must be finished by next week, so we need to stop
        accepting comments by the end of this week.
Anon conversation ensues, it was mentioned that we should have the issues
        resolved/removed and editorial comments against the AM closed, then
        allow the editors time to complete before the 4/18 telecon so that the
        AM doc can be reviewed/approved by the WG.
Deadlines were agreed for comments : Friday, April 13th at end of workday PST.
Deadline for issue resolutions/inclusions : In the hands of editors by 
        Monday Apr 16, Noon PST
Deadline for editing to be completed by Tues. Apr 17, Noon PST

It will be decided on the 4/18 telecon whether we can publish the doc.