W3C XML Protocol teleconference, 9th May, 2001

1. Roll call

PRESENT 42/36 EXCUSED REGRETS ABSENT

2. Agenda review, call for AOB:

 David Fallside: Outlined agenda.
 No AOB

3. Approval of minutes from 2nd May telcon

 Approved - no amendments.

4. Review action items.

 AI1) David Clay 280301: Finished and posted to group. Waiting Feedback
      Pending
 AI2) David Clay 280301: Finished and posted to group. Waiting Feedback
      Pending
 AI3) Jeff Kay et al 110401: Closed. Will be raised again if issue.
      Done 
 AI4) Hugo 260401:  Done
 AI5) Henrik/MarkJ 020501:Done
 AI6) Gudge 020501: Done
 AI7) Henrik 020501: Pending
 AI8) Henrik 020501: Revised wording
     Done

6. Part 1

 Issue: "mustUnderstand" Attribute
 Gudge's proposal posted to list and included in agenda announcement e-mail.

 DavidF: We could:
  1. Make it a normative part of the specification.
  2. Make it a non-normative part of the specification (& therefore
     a responsibility of a higher layer)
  3. Document in archive but not be part of the specification.

 Noah: had sent a response.  Concerned about consideration in isolation 
  from consideration of ordering and processing by intermediaries.

 Gudge: acknowledge his proposal doesn't guarantee intermediary has 
   processed "mustUnderstand" correctly.

 Noah: Need to know what problem "mustUnderstand" is solving.  What 
  "mustUnderstand" means is the "SOAP sender is in trouble if 
  the target processor does not do the requested processing"

 Henrik:  should processing be different at the end as compared to an 
     intermediary?  Gudge's proposal can accommodate an intermediary 
     not doing something at the end.

 DavidF:  Gudge's proposal gives a solution to processing at the end.  
     Need proposal for ordering.  Carry Gudge's proposal forward 
     and solicit solution to the second part (i.e. ordering and 
     processing by intermediaries).

Action: Noah: First draft of second part by Friday.

 Noah: Solution to the second part may provide a solution for which 
  the first part is just a specific situation.

6. Part 2.

 Glen Daniels: Summary.  Concern about level of detail in "mustUnderstand" 
     fault.

Action: Glen: By Friday will summarize issue and post to Noah for incorporation.

 Gudge: Can't put header fault information in the "detail" element.  Can 
   only be used for fault information related to the body.

 David Orchard: mustUnderstand led to very binary faults.  There may be 
      partial failures (e.g. during security processing).  
      Concerned about creating a sibling element to "detail" 
      for header faults. Use namespace qualified child elements 
      of "detail"?

 Noah: Observation of SOAP specific - schizophrenic.  Body and header 
  are symmetric in that the body is just another element but 
  asymmetric in that a fault in the body is different to a fault 
  in the header.  Should decide either to be symmetric (i.e. body 
  and headers are the same in every aspect) or asymmetric (i.e. the 
  body and header are different).

7. SOAPAction - Issue 95 & 22


 DavidF: Should either continue with proposal or delete SOAPAction 
    completely from specification.

 Q: Why SOAPAction exist?

 Henrik: Concerned about a lot of duplicated discussions.  Should the 
    group used for discussions be more restricted?  Discussions 
    should concentrate on providing specific proposals for 
    wording. Should refine guidelines for discussions and 
    progressing issues.  Marc Hadley and others have provided 
    input to original proposal to clarify edge cases.

 Jeff Kay: Should remove SOAPAction.

 Gudge: Made a proposal to revert back to SOAP method name as in SOAP1.0.
   Why did it change from 1.0 to 1.1?

 Henrik:  SOAP interface and method in 1.0, became SOAPAction in 1.1 so 
     it was less oriented to RPC.  It is meant to supply a hint 
     about the contents.

 Noah: Is SOAPAction deterministically or non-deterministically related
  to the body?  This was originally targeted at performance by 
  providing information about the body without having to process 
  the whole message.

 DavidF: Need the motivation for creating SOAPAction.  It also needs to
    be considered in the wider context of other transports.

 Mark Nottingham: mime content-type could provide an alternative to 
        SOAPAction.

 Henrik:  content-type has no mechanism for nesting content-type.  
     Also SOAPAction is used to indicate this is a SOAP request
     (coming in on the same URL and port).

 David Clay: Is there a compatibility issue if SOAPAction is removed?
   Why not use different URI to identify different use?
 
 DavidF:  Need motivation for SOAPAction.  Compatibility - should it
     be considered?  Role is not just to ratify SOAP.

Action: Henrik: Include the motivation for SOAPAction in the proposal 
      and distribute to dist-app

8. Issues:


 DavidF: 10 issues are of editorial nature.  Will assign en-masse to
    the editors.  The Issue list maintainer will assign the 
    issues to the editors.

9. Agenda for F2F


 DavidF: Need to start thinking about the agenda.  Needs to be stable
    by the 29th May.  Send any agenda items to DavidF ASAP.  
    Would like to concentrate on proposals for resolving issues.

10. AOB

None. Closed