W3C XML Protocol Working Group teleconference, 26 October 2001

Minutes of the XML Protocol Working Group teleconference, 3 October 2001.

1. Roll call

Present 36/30 Excused Regrets Absent

2. Agenda Review

David added to agenda issue 70 see item 5a below

AOB
     David F
     1. New WD published yesterday
     2. Call out to list for encoding TF. Responses from:
          Paul Cotton
          Jacek Kopecky
          Marc Hadley
        Planned call later this week
     3. Updates to issues list
        A number of issues assigned to groups e.g. ETF, editors
        30 or so left after assignment
          12 near completion
          19 issues to be considered, (in the next 7 telcons)

3. Approval of minutes

approved as posted

4. Review action items

     Paul Cotton - pending
     Chuck Campbell - done
     Editors - done
     Paul Cotton, Report from Query - pending
     Mark Nottingham, Internet draft for 427 HTTP status code - done
     TBTF, SOAPAction as a property/feature - pending
     Marc Hadley = done
     Hugo/editors - done
     Editors - done
     Editors RPC - done
     Hugo, Schemas for pub - done
     Hugo, IPR - done
     Hugo, IPR for test suite - done
     Chris Ferris, rework proposal - done

5. Status report

     TBTF, Stuart
          Telcon to discuss revised message exchange proposal and Henrik's
          posting
          Differing views on transport and binding framework
               Abstract/Architected vs Structured Table of contents approach
          Stuart/Oisin/Marc voluteered to further develop framework
               Completed review of draft with Noah
          Next call on Friday
          Two documents will be produced
               Binding description
               Remaining text fragments
          Posting to list tomorrow
          No comments or questions from WG

     Conformance, Hugo and Oisin
          Pinged Henrik and Paul re. SOAPBuilders tests from MSFT
               Now working on obtaining more formal agreement
          IPR issue to enable global public call for tests
               Looked at Henry Thompson's work on Schema
               Still working on a proposal document
          Oisin working on updated testable assertions doc
               Also an extended description of tests

     JohnI, Usage Scenarios
          Update to list by Monday
               Including only those scenarios discussed at recent San Jose F2F
          Contributions for other use cases welcome
          Paul Denning questions whether usage scenarios should be in
          primer
               JohnI action to contact Nilo to figure out possible
          positioning

5a. Issue 70: Definition of an intermediary

          The email comments raised against against closing the issue are
          editorial rather than substantive change
          Proposal to close 70 with proposed text in XMLP Comment
               MarkN and DougD to take up editorial suggestions with
               editors
          WG agreed to close issue 70 without dissent

6. Issue 12

          Chris Ferris has submitted rewritten text incorporating all
          changes agreed to in previous telcon
          Chair notes we were close to agreement at end of last telcon
          Mark Nottingham - Do we need to say something more about 300 codes
          Henrik says the requirement in 2616 ? is bogus!
               Don't need to add to wording
          Mark N concerned that the proposed text may lead to confusion
          Henrik - our text is informational. A problem with 2616 and not ours.
          Stuart - likes the structural flow created by incorporating the
          3xx codes, thinks that noy having the section section would confuse

          Proposed to close issue 12 with posted text and (i) 3xx
          redirection text included, and (ii) editors to clarify '405 method
          not allowed' section
          WG agreed to this proposal without dissent
          Chris Ferris action to submit resolution text to xmlp-comment

7. Issue 4

          Marc Hadley has posted a proposal for resolution of this issue
              Aside: he suggests we rename it as "the issue that would not die"
          Proposal summary is that "DTDs and PIs should not be in SOAP
          messages, and upon receipt of a DTD or a PI, SOAP receivers can 
          ignore or send a fault
          Marc clarified text of the proposal email: "it" refers to the DTD
          or PI, but NOT the message
          Concerns that if msg has a DTD, sender expects the DTD to be
          processed
          This affects following infoset - receiver sees different message
          Concerns about how practical for a parser to ignore DTDs
          Suggestion from Marc to reformulate proposal
               Split issue into 2 - OK in XML spec to ignore PIs
               Sender MUST NOT include DTD, receiver MUST fault if present
               Sender SHOULD NOT include PIs,receiver SHOULD fault if present
          Chris F - Why not "MUST" for PIs? For example: Sender MUST NOT
          include PIs, receiver SHOULD ignore if present.
          Henrik - asks whether there is input from XML coordination group?
          Perhaps W3C has views on longterm plans to phase out PIs and DTDs
          DavidF - suggests asking W3C reps
          Hugo - not aware of any plans
          Yves - Avoiding PIs should be the best option, I am not aware of
          any plans regarding DTDs
          Marc - reminds WG that the point of issue 4 is what a receiver
          should _do_ if it receives a PI or a DTD

          WG generally agrees that a receiver MUST fault on a DTD

          Marc - no real model for localisation of a PI
          David F - checks on representation of PIs in the infoset
          Gudge - PIs are represented, they are scoped to the containing
          document or containing element
          Marc - discussion on PI scoping
          David F - Can we say anything meaningful about PIs ? It seems the
          choices revolve around MUST/SHOULD and fault/ignore
          Chris F - Original proposal was "MUST ignore for receiver"
          Henrik - Does SOAP processor ignore and pass PI to an application?
          We don't want PIs to impact SOAP processing
          Stuart - how about MUST not generate and take a tolerant view if
          you receive them?

          David F - suggests SOAP message SHOULD NOT contain PIs, receivers
          MUST ignore a PI

          Proposal:
               (i)  SOAP messages MUST NOT include DTDs, and SOAP receivers
                    MUST fault if they encounter a DTD
               (ii) SOAP messages SHOULD NOT include PIs, and SOAP
                    receivers MUST ignore any PIs they encounter
          WG agreed without dissent to this proposal and to close issue 4
          using it
          Marc action to produce resolution text.

8. Issue 134 - support for XML Base

     Stuart - Has some feedabck on this issue from HP implementers: it is
     better to include base within SOAP - do it right the first time
     Mark N - what are the benefits of including xml:base?
     Gudge - it resolves relative URIs
     Dave O - they also make it slightly easier for an infoset definition
     of SOAP, xml:base uri called out in infoset
     Gudge - turns the question around: is there any reason why we should
     NOT include  xml:base?
      ??? - has a fuzzy feeling about increased complexity for small devices
     Doug - why do we have to say anything about it?
     Henrik - we have to make a stand (statement) on it. If we want to have
     a base uri for a message, this is how to do it.
     Gudge - if we think anyone will send base uris in a SOAP message then
     this is the way to do it
     David O - notes that we only need to consider xml:base on SOAP
     elements, not other (application specific) elements.

     David F - What are the implications of using it?
     Gudge - processor will resolve relative uris
     Henrik - if we don't allow it, then extensions might choose to allow them.

     Dug - what about devices that choose to ignore it ?

     David F - Question to be answered
          What is our relationship to XML Base spec ?
          Need to see a proposal for supporting XML Base - or use Noah's
          proposal
     David O and Gudge volunteered to write a positive proposal by Monday.

9. Issue 14. SOAP versioning

     DavidF: there is push-back from Larry Masinter on our resolution for
     this issue: he wants a more general versioning mechanism
     DavidF: WG options:
          (i) This is all we will do, or
          (ii) Describe a more general purpose mechanism

     Henrik - not sure we can say anything more than we do now.
     Stuart - not sure that cproposed mechanism will cover all future needs

     WG agrees, without dissent, to respond to Larry Masinter saying we
     consider issue closed, becuase we consider the scope of the mechanism is
     only 1.1 to 1.2, and we have provided a mechanism to cover the scope of 
     the problem
     Gudge action to formulate and send response

10. Issue 139 Define SOAP Application

     Chris F has published a proposal. Unfortunately he had to drop off the
     call so we postponed discussion.

11. Issue 138, use of xml/text. Discussion postponed due to lack of time.

12. Issue 140 default/anonymous actor

     Stuart - issue is how would a default actor know it was that actor
     Stuart and Jack - it's heading for closure .....
     Stuart - Jack's response it doesn't say anything more about any other
     actor .... transport endpoint may influence what actors are present
     Stuart has composed text, Jack happy with it, they both would prefer
     to add it as explanatory text to the spec
     Some discussion about whether the anon/default actor has a name, after
     all it is called the "anonymous" actor
     Stuart sent to list today
     DavidF action to add 140 to next weeks agenda