Minutes of the XML Protocol Working Group teleconference, 3 October 2001.
1. Roll call
Present 36/30
- Active Data Exchange Richard Martin
- Akamai Technologies Mark Nottingham
- AT&T Mark Jones
- BEA Systems David Orchard
- Canon Jean-Jacques Moreau
- Compaq Yin-Leng Husband
- DevelopMentor Martin Gudgin
- Hewlett Packard Stuart Williams
- IBM John Ibbotson (scribe)
- IBM David Fallside
- IBM Doug Davis
- IDOOX Jacek Kopecky
- Intel Highland Mary Mountain
- Interwoven Mark Hale
- IONA Technologies Oisin Hurley
- Macromedia Glen Daniels
- Martsoft Jin Yu
- Microsoft Corporation Henrik Nielsen
- Mitre Marwan Sabbouh
- Mitre Paul Denning
- Netscape Vidur Apparao
- Novell Winston Bumpus
- Oracle Anish Karmarkar
- Philips Research Amr Yassin
- Rogue Wave Murali Janakiraman
- Software AG Michael Champion
- Sun Microsystems Marc Hadley
- Sun Microsystems Chris Ferris
- Tibco Frank DeRose
- Unisys Lynne Thompson
- Unisys Nick Smilonich
- Vitria Technology Inc. Tony Lee
- W3C Yves Lafon
- W3C Hugo Haas
- WebMethods Dave Cleary
- Xerox Ugo Corda
Excused
- Active Data Exchange Shane Sesta
- AT&T Michah Lerner
- Canon Herve Ruellan
- Compaq Kevin Perkins
- DevelopMentor Don Box
- IDOOX Miroslav Simek
- Intel Randy Hall
- Interwoven Ron Daniel
- IONA Technologies Eric Newcomer
- Macromedia Simeon Simeonov
- Microsoft Corporation Paul Cotton
- Netscape Ray Whitmer
- Novell Scott Isaacson
- Oracle Jeff MischKinsky
- Philips Research Yasser alSafadi
- Rogue Wave Patrick Thompson
- Software AG Dietmar Gaertner
- Vitria Technology Inc. Richard Koo
- WebMethods Asir Vedamuthu
Regrets
- Matsushita Electric Ryuji Inoue
- BEA Systems Jags Ramnaryan
- Data Research Associates Mark Needleman
- Engenia Software Jeffrey Kay
- Engenia Software Eric Jenkins
- Ericsson Research Canada Nilo Mitra
- Fujitsu Limited Kazunori Iwasa
- Fujitsu Limited Masahiko Narita
- Informix Software Charles Campbell
- Library of Congress Ray Denenberg
- Lotus Development Noah Mendelsohn
- SAP AG Volker Wiechers
- SAP AG Gerd Hoelzing
Absent
- DaimlerChrysler R. & Tech Mario Jeckle
- DaimlerChrysler R. & Tech Andreas Riegg
- Informix Software Soumitro Tagore
- Library of Congress Rich Greenfield
- OMG Henry Lowe
- Propel Daniela Florescu
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