Minutes of XML Protocol WG telcon 2/21/2001

Roll call

Active Data Exchange     Richard Martin  principal
Allaire   Glen Daniels   principal
AT&T Mark Jones     principal
AT&T Michah Lerner  alternate
Bowstreet Alex Ceponkus alternate
Canon     Jean-Jacques Moreau principal
Commerce One   David Burdett  principal
Compaq    Kevin Perkins  alternate
Compaq    Yin-Leng Husband    principal
DaimlerChrysler R. & Tech     Mario Jeckle    principal
Data Research Associates Mark Needleman  principal
DataChannel    Brian Eisenberg     principal
Engenia Software    Eric Jenkins   alternate
Group 8760     Dick Brooks    ebXML contact
Hewlett Packard     David Ezell    principal
IBM  John Ibbotson  principal
IBM  David Fallside chair
IDOOX     Jacek Kopecky  principal
Intel     Randy Hall     principal
Interwoven     Mark Hale principal
Library of Congress Ray Denenberg  principal
Lotus Development   Noah Mendelsohn      principal
Matsushita Electric Ryuji Inoue    principal
Microsoft Corporation    Paul Cotton     alternate
Microsoft Corporation    Henrik Nielsen  principal
Mitre     Marwan Sabbouh principal
Mitre     Paul Denning   alternate
Netscape  Ray Whitmer    alternate
Netscape  Vidur Apparao  principal
Novell    Scott Isaacson principal
OMG  Henry Lowe     principal
Oracle    David Clay     principal
Philips Research    Amr Yassin     alternate
Philips Research    Yasser alSafadi      principal
Rogue Wave     Patrick Thompson    alternate
SAP AG    Volker Wiechers     principal
Sun Microsystems    Marc Hadley    principal
Tibco     Frank DeRose   principal
W3C  Hugo Haas alt team contact
W3C  Yves Lafon     team contact
WebMethods     Randy Waldrop  principal

IDOOX     Miroslav Simek alternate
Active Data Exchange     Eric Fedok      alternate
Allaire   Simeon Simeonov     alternate
Bowstreet James Tauber   principal
Canon     Herve Ruellan  alternate
Commerce One   Murray Maloney alternate
Engenia Software    Jeffrey Kay    principal
IBM  Fransisco Cubera    alternate
Interwoven     Ron Daniel     alternate
Library of Congress Rich Greenfield      alternate
Oracle    Jim Trezzo     alternate
Rogue Wave     Murali Janakiraman  principal
Sun Microsystems    Mark Baker     alternate

DevelopMentor  Martin Gudgin  principal
Akamai Technologies Mark Nottingham      principal
Calico Commerce     Rekha Nagarajan      principal
Cisco     Krishna Sankar principal
DaimlerChrysler R. & Tech     Andreas Riegg   alternate
DevelopMentor  Don Box   alternate
Ericsson Research Canada Nilo Mitra      principal
Hewlett Packard     Stuart Williams      alternate
Jamcracker     David Orchard  principal
SAP AG    Gerd Hoelzing  alternate
Software AG    Michael Champion    principal
Unisys    Lynne Thompson principal
Unisys    Nick Smilonich alternate

Epicentric     Dean Moses     alternate
Epicentric     Bjoern Heckel  principal
Fujitsu Software Corporation  Kazunori Iwasa  principal
Fujitsu Software Corporation  Masahiko Narita      alternate
Informix Software   Charles Campbell     principal
Informix Software   Soumitro Tagore      alternate
IONA Technologies   Oisin Hurley   principal
IONA Technologies   Eric Newcomer  alternate
Progress Software   Peter Lecuyer  alternate
Software AG    Dietmar Gaertner    alternate
Vitria Technology Inc.   Waqar Sadiq     principal
Vitria Technology Inc.   Richard Koo     alternate
Xerox     Tom Breuel     primary
XMLSolutions   Kevin Mitchell principal
XMLSolutions   John Evdemon   alternate

Review of the agenda

Approval of minutes from last week telcon

Minutes were approved

Action items

Comments on DS8  scenario - stricken - will be discussed today
805/807 to become part of requirements - done
Henrik - SOAP issue list to be included in XML Protocol issues document - done
Henrik - put pointer to SOAP issue list - done
David Clay - strengthen wording on early uniform normalization and
handling included data - done

Report on status of SOAP specification document

Response to Character model document

revised text posted -
Noah has suggested small changes  -  suggestion was made to either expand or
remove last sentence. - it was agreed to remove it
Paul asked how many comments were in reply - asked that the comments be
numbered -some identification of comments  will be done - they will be
numbered ant title will be added
Question was raised as to whether the text "as necessary" was clear enough
there was some discussion of this - there had been some agreement to split
things on header/body axiom - Noah raised some concern about this in terms
of the fact that the header to one system might be the body to another -
would prefer to be more vague.  Henrik agreed with this. Noah raised issue
of an xml file server which may not want to take responsibility for
normalizing data it has received.  Issue was raised that this happened
because xml was used for the envelope - suggestion was made to not use the
word header. - Henrik raised issue of term as necessary since it could
argued it was always necessary - suggested revision was to change 2nd
sentence in 3rd paragraph to normalize parts of the message as appropriate

Noah suggested (with some assistance from others) - An xml protocol
processor may normalize those portions of the message on which it acts
directly, and will defer to applications any normalization that may be
required for processing payload(s) - question was raised as to why "may" was
used. Noah asked about an xml processor sending on the wire messages  - was
this for outbound or inbound messages?

Noah - do we make a statement about what senders do? Currently response is
ambiguous about whether we are talking about senders or receivers.  XM
processors are encourage but not required to normalize data for messages
they are sending - text above should apply to receivers of data.

Suggestion was made to separate payload from headers - Noah believes there
are no normalization required for the xml protocol header elements - at
least not currently in SOAP. Question came up whether this might apply for

Question came up about whether we allow non normalized data in SOAP body?
David F believes this had been resolved in earlier discussion - David F
asked about how we should treat 2nd case  where body of message is XML? -
are we responsible for that or not  - Noah believes this was what the above
discussion was about

Noah suggested one possibility was to say nothing about senders and use text
above for receivers - other option was a symetrical view for both sender
and receiver.

David F mentioned we need to deal with agenda item 7 at some point - he is
inclined to continue with character model discussion since we need to have a
reply by end of week.

Discussion continued on character model document

Question was raised as to whether normalization in regards to XML Protocol
elements was a non issue or not sicne all elements defined were in US-ASCII
- what effect dis this have extentions - could we make a design decision at
this point to say that we will only define elements in US-ASCII - what about
status or error messages?

Suggestion was made to respond to I18N that based on current design and
where we are in designing protocol it might be that normalization would not
be a problem with protocol element. David F suggested we tell I18N that in
general we do not feel it is XML Protocol's responsibility to deal with payload - we
are in favor of normalization of protocol elements but we agree too early in
design to say anything more specific - Noah suggested we state we are still
in early design phase and that we have tentatively decided that we don't
think normalization of xp elements were needed but that we believed that
payload normalization was not something we believed was XML Protocol's responsibility
(or words to that effect) - also that we tentatively agreed to take
responsibility for normalization required for limited things like status
and error messages where required.

Noah proposed revised text as follows in place of current comment #3 :

Para #3: The XML Protocol Workgroup is still in the design process.
Tentatively, we propose to adopt the following design direction:

a) Our fixed vocabulary (e.g. ENVELOPE, HEADER, etc.) are expected to be
expressible in US-ASCII for which no normalization issue exists.
b) With respect to other control information generated or acted upon by the
XMLP Processor itself (e.g. text status messages), we expect to require
early normalization by senders, but no renormaliztion by receivers.
Receivers may reject unnormalized control information.
c) The XML Protocol Processor  will defer to applications any normalization
that may be required for sending and/or receiving application payload(s).
Reason: Consider the example of an XML Protocol message containing a very
large >>XXX deleted the word text XXX << payload  >> being sent for
storage in a filesystem:  we do not believe either from a performance or
philosphical point of view that it should be the responsibility of the
transport or communiction layer (XML Protocol) to manipulate the payload in
such a circumstance. <<

Proposal was made  to accept Noah's suggested text above as response to
- It was suggested that this comment be moved to the top of the comments -
David F suggested that this might be all the comments we needed to send in
Noah believed current comment #4 could stay in which referred to optional
attribute about normalization.

David F proposed Noah send his text to private list and David weave it in to
existing text and post it back to WG - and WG sign of on it - David F asked
whether there was any strong objection to this as a response modulo the fact
that they havent seen the actual text. Deadline will be 2/22 noon pacific
time for comments or objections.  - small editorial changes can be made
modulo David's time by noon tomorrow pacific - the language Noah used
specifying US-ASCII will be corrected to reflect what ever the proper
language should be - David asked that cut off be changed to 3pm pacific
tomorrow - agreed