13 and 14 December 2000
Chair: David Fallside
Scribes: Jeffrey Kay and Noah Mendelsohn
Meeting location: Microsoft Corp., Redmond, WA.
These are formal minutes of the W3C XML Protocols Workgroup face-to-face meetings held on 12/13/2000 and 12/14/2000.
One note of explanation: in the following, "poll" means an informal check of the sense of the group; "vote" is a formal vote per W3C procedures -- we did not take any such formal votes.
| Wednesday,
Dec 13th |
|
| Morning Session I, 8.30a - 10.15a |
|
| Break, 10.15a - 10.45a | |
| Morning Session II, 10.45a - 12.30p |
|
| Lunch, 12.30p - 1.30p | |
| Afternoon Session I, 1.30p - 3.00p |
|
| Break, 3.00p - 3.30p | |
| Afternoon Session II, 3.30p - 5.00p |
|
| Thursday, Dec
14th |
|
| Morning Session I, 8.30a - 10.15a |
|
| Break, 10.15a - 10.45a | |
| Morning Session II, 10.45a - 12.30p |
|
| Lunch, 12.30p - 1.30p | |
| Afternoon Session I, 1.30p - 3.30p |
|
| Break, 3.00p - 3.30p | |
| Afternoon Session II, 3.30p - 5.00p |
|
Meeting started at approximately 8:40 AM.
Introductions
Review Agenda
Fallside: slight change made to agenda to have discussion of glossary in the requirements document in the first morning session, attempting to work through 4 sections in order.
Fallside: Hope to publish requirements document as a result of this meeting, in the form of a working draft that can later be revised for a variety of reasons, including future work on use cases. We will slightly quiesce requirements activity after this meeting, now we are ramping up next stage in the design process. That next step is to evaluate SOAP 1.1 against our requirements (as called for by our charter.) Note that, while it might be a good thing, we are not strictly required to have use cases in our first published req. document. At end of day tomorrow, we will consider whether the content reasonable to publish as first draft
Fallside: Future proposed meetings. 2/26&27/2001 in Boston, June 2001 in Rennes, France
Minutes from 6 December Telecon as posted (approved) and will be published
Action items from last meeting
Action item 1 on use cases are in process: Glen Daniels responds for Sim that the action items have been discussed. Question arose about whether they are at the right level of abstraction or detail.
Action item 2 on transportation is overcome by events (OBE)
Action item 3 Martin Gudgin responded that the glossary has been started.
Fallside: proposals for group to consider: 1) name choice: (a) use some combination of transfer/transport but not application or (b) pick a neutral term, 2) proposal to expand bindings to show some particular ones
Denenberg: I think we agree application is the wrong term. Neutral term doesn't have to be our own term.
Stuart Williams: This is a glossary in req. doc. Are we setting ourselves a straightjacket in our future work.
Kay: How about framing?
Ed Mooney: I liked the original application protocol.
Stuart Williams: if we use application protocol for this, we may miss it later for our own applications' protocols.
Denenberg: Application protocols should be on the top
Mark Nottingham: Maybe we should avoid the term application overall
Ibbotson: One of our use cases is an XP to kick off a transaction
Noah: Question for Henrik -- doesn't SOAP really use HTTP as an application protocol, e.g. to make our error responses HTTP error repsonses?
Henrik: Yes, absolutely that was the point." discussion with Jeff Kay follows...
Noah: ...yes, the functions found in the bindings will differ according to the carrier protocol.
Ray Denenberg: why do we want to call the lowest layer an Application Protocol?
Mark Jones: should we have a box underneath identifying the lower box
Henrik: HTTP and TCP both qualify and because SOAP can be bound to a number of things, we have a layering and it doesn't matter
Ray Denenberg: In this context is HTTP an application protocol? The lower box should read "transport or transfer" protocol.
Jim Trezzo: Classic "L" cutaway where we show HTTP and other things. Also we should stick with IETF definitions
Marwan: It would be good to show the layers below
Stuart Williams: Just identify them as underlying
Randy Waldrop: Application is typically identified with the user's code and that's what the protocol module identifies
Noah: disagrees that we should show deeper layers and the number of layers is variable
Mark Nottingham: seems we're trying to do different things: the engineers will be comfortable but the people doing apps may be confused
Lynne Thompson: who is going to be looking at this spec? Like the layers, but we don't need to go through all the layers: avoid confusing terms
Mark Jones: application is too overloaded: call it something else
Mark Nottingham: transfer protocol isn't a well defined concept
Oisin: the diagram should show not an IETF perspective but from an XP perspective, supports the use of transport or delivery, describe from the XP perspective
Dave Clay: XML protocol shows a layering where use of SSL or other authentication
Glen: colloquially might be transport, prefers to stick to a single term and define it in the glossary to identify that this is what sits below us and moves the XP
Mark Nottingham: agrees with Glen. Separate the boxes to identify the multiple bindings
Denenberg: should say transport or transfer
David Ezell: hard time reconciling diagram against the content of 7.2
Henrik: transport or transfer makes sense
Marwan: likes the idea of transport or transfer protocol, perhaps 2 layers identifying the transport being optional?
Yan: they can't be separated: transport and transfer don't necessarily sit one on top of the other
Vidur: stick with one of them and use the text to define the box
Henrik: prefers to have both transport and transfer
Stuart Williams: why stick with both? Why not use something neutral like "substrate"
Jim Trezzo: doesn't like overloading the terms but application is clearly not the right term
Henrik: concern with coming up with an unrelated term is that this is our hook into the outside world
Fallside: displaying something neutral is generally a problem
Glen Daniels: Someone mentioned splitting up the box and that would be a good idea
Fallside: proposes naming (possibly using something generic): generic term or use transport or transfer, expand the protocol binding piece, add more clarifying prose in the document
Denenberg: application is not the appropriate term, it doesn't necessarily have to be a term that we pick
Stuart Williams: this is a glossary in a requirements document, how much of a straightjacket ...
Kay: what about the use of the term framing protocol?
Ed Mooney: comfortable with application protocol: doesn't rule out transport and acknowledges that HTTP is useful
Stuart Williams: Application protocol term will cause us problems
Mark Nottingham: XP is an application layer protocol, leveraging other application protocols in some circumstances
John Ibbotson: one of the use cases is to make use of an XP message to kick off a transaction, maybe there is a role for an application protocol at that layer
Noah: views this as a strict encapsulation layer. HTTP is not a completely opaque carrier, rather this is a stylized use of HTTP, as opposed to a tunnel, which is where the use of the term application protocol. Application sending should know as little as possible about the XP, an RPC call might fail and HTTP has a notion of errors already
Glen Daniels: voting choices -- terms which have meaning outside, e.g. IETF: mutual term that we explain in the prose
PROPOSAL (Fallside): do we want a new name or an existing term
(transfer is an existing.)?
In favor of something generic
In favor of transfer or transport
In favor of breaking up the lower box
POLL: Initial vote is split ... discussion continues
Noah: we need a term and suggests "carrier" protocol
Yan: consistency is important
Henrik: would claim that all the terms are generic anyway
Mark Nottingham: in favor of transfer
David Burdett: suggests "communications" protocol
Frank DeRose: suggests we take this offline
DECISION (Fallside): We're going to take this offline: will take responsibility for collecting inputs: will select a group to put together options or a specific suggestion. We're moving on. Should have examples for each option - The bottom box should have sub boxes.
Martin: will edit the diagram
Glen Daniels: should the diagram show interactions between protocols and messages
Vidur: one can imagine protocol modules being built on each other
Henrik: SSL and S/MIME are examples of hooks and things are intended to
Jim Trezzo: if we try to convey all the flexibility in the diagram it will be cluttered. Perhaps show extremes
John Ibbotson: when we document the use cases can we reuse the diagram as part of that effort?
Stuart Williams: when we publish, we should include the definitions of Application and Protocol in the text, rather than a references
Henrik: Telecom Glossary 2000's definition is out of a proposed ANSI document, looked formal and like a good definition: the fundamental assumption is that we don't have any benefit of owning those terms. The terms we own begin with "XP".
Stuart Williams: the big problem is because the text doesn't appear there
Jim Trezzo: need a definition that appears directly in the text, not published, obscure, and these are very common definitions that we don't need to go to a outside source
Fallside: we don't need to have every single term defined for this exercise
Henrik: [ reads the definition ]
Yan: the definition is referring to something out of context
Ray Denenberg: leaving those terms blank will save us a day or two of work
Kay: should have a definition that is contextual to XP
PROPOSAL (Fallside): Should we strike the entries under the terms application and protocol for now?
POLL: large number for, no strong oppositions, some abstentions.
DECISION (Fallside): We'll decide later how we address the terms and resolve this.
Henrik: sender, receiver and intermediaries are defined further down
Glenn Daniels: is XP module defined as both the data carried in the message and the programming level it processes?
Henrik: glossary should not be an implementation module, rather it shows where the protocol is situated in the world. How that maps into specific implementation modules doesn't fall into XP's realm.
Glen Daniels: it's about the stuff on the wire
Henrik: how the sender and receiver are identified are app specific
Stuart Williams: Frank: it appears that on one level we're talking about a syntactic construct
Vidur: section above the definitions talks about mapping a syntactic construct to a processing unit
Noah: Someone has to make the code work, but that we shouldn't discuss the implementation of the processors that (or define the terminology) handle the XP message. Individual syntactic things (e.g. errors in the context of some more structure: implied state machine that we will get into), shouldn't talk about the layering at the end
Stuart Williams: there are syntactic and behavioral pieces: the term for XP module only covers the syntactic piece and doesn't have an abstract notion of function
Ed Mooney: strike the first sentence and replace with (XP module): "A means of providing the services carried by XP modules "
Tom Breuel: what about defining the module as an extension of the XP standard compatible with the standard
Henrik: are we extending HTTP or the envelope we are extending or is it something on top of it
Glen Daniels: there is a syntactic idea and XP represents a specific set of syntactic data and there is a module that deals with that thing. The issue is that there are specific behaviors that come along with it
Vidur: the terms used are processing rules versus format
Stuart Williams: used as a syntactic structure throughout the document that would need to be corrected elsewhere
Henrik: one point might be that were is this seen from: intent of putting XP has a set of processing and a set of modules that process. We don't define the state machine or talk about it at all. From an XP POV it's a bag
Stuart Williams: talking about a framework for extending XP, someone defining a signature module would have to define both syntactic and behavioral structure for that to operate. Templated notion, companion definition of the behavioral piece
Oisin: This might refer to the generic extension mechanism defined by the DR700 set.
Tom: it's not just a syntactic unit, but it's got to be compatible with everything we define. Defines one or more syntactic units that conform to the base XP
John Ibbotson: emphasize the extensibility mechanisms in the base protocol
David Ezell: comfortable only as a syntactic construct. If we need to rename then we need a new term to define just the syntactic module
Ray Denenberg: call this something different than what we have on the stack, e.g. protocol unit which has the features we're already talking about and is encapsulated in the XP message
Glen Daniels: programming module infers code
Mark Jones: Module conveys behavioral notion
Noah: see people reading the word module and thinking code, fix that word and come up with terminology later
Fallside: Proposal: find a different word for XP module which represents that syntactic thing and say that there will be something which defines the code, behavior end of things
Vidur: would we then change the previous diagram? Syntactic construct, processing rules, and then the actual code. We're mixing up the processing rules and the code. All the other things that are protocols underneath refer to syntactic construct and processing rules.
Henrik: Common notion of a protocol is that "I send you something and you send me something back". What do we see as a protocol from the XP perspective? Do we see the something like protocol units living within the larger protocol? There's nothing in the document that infers code.
Noah: this isn't about code structure, but if you look at the other things in the diagram, there are other things that imply If everything else in the suite refers to
Henrik: this is from the perspective of XP looking up, where it's looked at as a blob
Fallside: is this something that with more careful wording in the prose (perhaps a different word other than module) this problem would be fixed? In the prose it would be called out as to its use.
Glen Daniels: should there be one term and syntactically overloaded in the text?
Henrik: borrow some of the text from XP definition for use with XP module.
Stuart Williams: since we're defining a set of terms for the future, we don't necessarily have to define them now and need to understand how everything fits together.
Jean-Jacques: Might be easier for people to understand with two terms
Glen: better to have two terms
Ray Denenberg: important that we get the terminology right
PROPOSAL (Fallside): Who wants two terms (XP Module and XP Binding)?
POLL: Most want two terms, a few want one term.
DECISION (Fallside): Sentiment is that two terms should be used to distinguish between syntax and behavior . Glen will come back with a proposal tomorrow for the rework of the bottom layer of the architecture diagram. We decided that we want to have two names to capture the syntactic and implementation aspects of XP.
DECISION: (Fallside): Editor takes a to-do to come up with a proposal for the distinctions among terminologies for syntactic structures, behavioral abstractions, etc. relating to modules and extensions. He will update diagrams accordingly and bring us back a proposal tomorrow.
Glen: Reiterates that the separation needs to be made and the term module is potentially confusing for use as the syntactic term
Vidur: Separation yes, but two extensions are not mutually exclusive. Should there still be a term that characterizes both?
Henrik: All input for terminology should be in by 10 pm to Henrik tonight via the list On XP binding:
Fallside: Does this fall within the category of "module" where there was trouble. Moving on to 7.2. Discussion on 7.2
Ray: difficult to discern the difference between the xp message and the envelope. What's the distinction?
Henrik: the intent was that the envelope contains the structures of XP whereas the XP message is an instance where you stick all kinds of other things in.
Denenberg: If you can stick other things in the XP message then we should identify that because the diagram doesn't indicate
Oisin: Other stuff in the XP message, e.g. MIME where the first attachment is the list of attachments is part of the message but not the envelope. This is something we need to revisit
Henrik: No notion of XP that talks about link relationships and the like
Mark Jones: If there is data that has to be within the boundary of the XP message and if base64 is not acceptable, then is there room outside the boundary of the envelope or is this something that we have to figure out how the XP envelope can encapsulate it.
Henrik: XP message is the outer construct, which is XML. Cannot stick binary stuff in it.
Noah: In certain bindings will not be XML, e.g. HTTP. There is nothing that you can find that is in the envelope that is not in the message
Tom Breuel: Procedural suggestion - collect them all and decide how to handle them. Observation is that the diagram and the terminology where the optional data precedes the body
Martin Gudgin: This was to deal with intermediaries where they can read the optional stuff without reading the entire message.
Henrik: Agrees
Yves: Nothing precludes you from adding information at the end. If you put headers at the beginning of the message for intermediaries, doesn't preclude you
??: Was there a relationship between modules and intermediaries and is the order of modules
Henrik: Design question. SOAP guarantees no reordering but doesn't imply ordering. If the slots are dependent on each other, then they need to organize themselves where they make sense.
John Ibbotson: Would like to see in this further information how SOAP attachments fits in this model.
Henrik: The first diagram and this diagram are related in that they are showing two diagrams showing layering. The first shows layers while the second shows encapsulation. The encapsulation diagram really illustrates the first two layers in the other diagram.
Noah: Is there something that is in the message that is not in the envelope?
Henrik: No
Noah: Then why are there two terms?
Henrik: One is an instance of the other. XP Message is an instance, where the envelope is an abstraction
Fallside: Envelope is really a schema Oisin: This diagram is a solution to a requirement, and isn't appropriate for this conversation
Fallside: No problem with glossary leapfrogging the requirements.
Oisin: Proposes that we shelve this discussion until we reach the point in discussion where we talk about 701a & b. Proposes this as a new agenda item.
Ray: Need to really visit this
Fallside: Proposal - remove XP Message layer from the diagram. Proposal - make a note in the diagram that until we fill in 701* we can't publish this diagram.
Tom Breuel: Maybe if we just drop XP from Message then we achieve the results.
Yan: Shouldn't we add something to the envelope. Glen: If XP Message can have anything
Kay: This diagram is really a syntactic diagram
Henrik: Agrees that having a message as an instance in this diagram (essentially a class diagram) doesn't make sense
Vidur: This is a requirements document, so syntactic points aren't relevant
Glen: If we took out the XP message box and put the caption on the bottom indicating that the diagram represents the XP message.
David Ezell: It doesn't hurt us to have these terms in the requirements document; this would solidify confidence. Is it wrong to say that an XP message contains header information that would bind it to a protocol? The entire data stream isn't an XP message?
Henrik: XP message only contains
Noah: Proposal: delete the box and replace it with a caption defining the diagram as the XP message and explain in the prose what an XP message is.
Noah: The envelope is the frame in which the headers hang, but the envelope is
Ray: It's a mistake to try to distinguish the message from the envelope.
Mark Nottingham: The envelope implies the entire container
David Burdett: We ought to talk about attachments
Noah: Give ourselves a license to update these things as necessary. Real need for attachments and other things to be discussed, but we aren't really digging ourselves into a hole. We can settle this later.
David Burdett: It is useful to put in the glossary the idea of an attachment if only to exclude it.
Fallside: We don't have to get every one of these things
David Orchard: Should leave message to create extensibility
David Ezell: Anything could display the thing called message, such as HTTP headers
PROPOSAL (Glen): Change the illustration for section 7.2 -- delete the box for XP message and replace it wit ha caption explaining that a message is the entire unit of communication, represented as an envelope and its contents. Definitions for Message and Envelope should be updated accordingly.
POLL: Significant support, no opposition. Editor is instructed to make the change by 10AM tomorrow, 14 December.
Fallside: Should we continue with the glossary for the rest of the morning, do we want to get through the entire glossary in this meeting? Should we focus on the glossary? Or time constrain it? Concerned with trying to get the group to move on to the next steps.
Vidur: Finishing the glossary feeds into everything else that we do and will affect our other discussions. Would prefer to keep on going.
Noah: Schedule says to ship this thing quickly. Priority would be to do as little of this as people feel comfortable and move on.
Stuart: What sort of process do we imagine for doing the next set of work?
Jim Trezzo: Take this through lunch, take a break and put a time limit on. Stuff that has diminishing returns we can send off to the task force. Would rather do the breadth first approach.
PROPOSAL (Fallside): Who wants to work on glossary? Who wants to allocated a bounded amount of time to continue glossary work?
POLL: Clear consensus for time-bounded approach to working on glossary.
DECISION (Fallside): An hour break for lunch, then 45 minutes on glossary, then SOAP mapping to requirements.
Fallside: Continuing the discussion of the glossary, with 45 minutes reserved. With each of the two sections, go around the room creating an issue list for the glossary for each of the sections. This is the list for 7.3:
Tom Breuel: Still an outstanding issue of 7.2 - the ordering of the pieces of the elements
Lynn: Two diagrams showing the sender and receiver (with the cloud) and with intermediaries needs consistency
Jean-Jacques: the sentence referring to B2B sounds more like a specification than text that describes something. It's more like a use-case.
Vidur: The relationship between the sender and the receiver isn't really relevant. Does an XP receiver have a processor?
Henrik: The notion for separating the processor out from the receiver and the sender is to point out the subtle distinctions surround protocol bindings.
Vidur: An XP processor needs to process an XP message
David Ezell: Sender refers to XP binding as perform an XP binding, in receiver we refer to extracting the XP binding. The term XP message appears throughout also.
Paul Cotton: Make them parallel with senders and receivers performing an XP binding
Fallside: Hold that thought
Ed Mooney: Regrets removing XP message
Jim Trezzo: dots instead of the hard arrow in the XP intermediaries diagram.
Mark Nottingham: Distinguished between process and transport intermediaries. Another issue, bottom illustration shows sender and receiver but doesn't show that the intermediaries between the sender and the receiver or processors.
Mark Jones: Does anyone have access to any part of the message at any time or are parts targeted to specific uses? Some of the intermediaries might be sensitive to things in the XP diagram. How do entities in other diagrams relate to the XP Message/Envelope diagram? E.g. intermediaries.
Noah: Need more terms such as one way message, request response pattern, and what about the term RPC? Message pattern
Henrik: Some of these were on the original list, but were removed because it's difficult to define a message pattern without defining a message.
Noah: The point is to establish a vocabulary, prioritized by the most important things to talk about.
Fallside: Continuing with 7.4:
Fallside: Is the use of the term XP data model elsewhere in the document?
Glenn: Is there a requirement for this term? Yes.
Stuart: The term is XP data model, as opposed to data model in the abstract.
Henrik: Encoding is how we write this out. Not UTF-8, rather XML.
John Ibbotson: Clarification needed for data that we're carrying that is not XML based. We need to define other classes of data that are not XML based.
Jean-Jacques: Clarify or define application data
Vidur: We say XP data encoding but we have allowed for the possibility of multiple data encodings. Are we committed to creating a canonical encoding?
Martin Gudgin: Not committed.
Ed Mooney: The use of "link relationships" in XP data model needs to be clarified
Martin Gudgin: Link relationships are relational references
Ed Mooney: These need to be defined
Randy Hall: Does encoding mean serialization?
Noah: In Raleigh, there was discussion that we would design messages in terms of infosets. We're at risk here of doing that. If we define that, then the encoding stops at a certain level. But it doesn't identify how it's rendered. Be careful that we doing go too far in describing an encoding or serialization until we define it. Better to keep the definition looks.
Mark Jones: XP Character Encoding should be identified here also?
Noah: Why are we presuming it's characters?
Mark Jones: Because of discussion in the list.
Noah: It's in the XML definition and we can probably point to it.
Noah: Change "the XP data model" to "an XP data model". Allow for the possibility of multiple data models. SOAP has this also.
Dick: You could base 16 encode an XML document that is in UTF 16.
Henrik: The intent was to have one bucket and not talk about character encodings.
Dick: We're not granular enough, should include element encoding. The definitions are too broad. Transform encoding.
Fallside: Data encoding should be identified as a single issue to resolve
Henrik: It's an interesting problem but not necessarily one that this group should work on.
Fallside: What are the top priorities to publish the document?
Noah: The document should actually carry this list of issues. Does it make sense to have the list in the document?
Paul: The advantage of having them in the document (assuming they have a well identified key), then people can respond directly to them. Whether they are in line or as an annex, doesn't make much difference.
Fallside: In the query requirements document, issues were inserted in-line.
Paul: Both resolved and unresolved issues were published at the spec level.
Martin Gudgin: Should we number the items in the glossary?
Paul: They are numbered by name. Not necessary.
Fallside: Issue list will be put in the document and will be published in the document
Henrik: Deadline for publishing?
Fallside: To be discussed tomorrow.
Discussion of Henrik's XP In-scope Requirements Mapping to SOAP/1.1.
Henrik: Presented XP in-scope requirements mapping to SOAP/1.1. Will be posted.
Noah: SOAP has layers of function, envelope and headers. With regard to referencing an external resource, there is an answer associated with the encoding. If you want to invent your own encoding for xml format, SOAP doesn't tell you how to deal with that. This is something that we need to look at as to whether or not XP does something different.
Glen: Does SOAP define whether mustUnderstand tags get processed first?
Henrik: SOAP entities are atomic.
Noah: SOAP has no non-atomic side effects? Aren't there interdependencies between headers, caching, etc?
Stuart: Intermediaries - what is the scope of the mustUnderstand? Do intermediaries need to understand them?
Henrik: No.
David Burdett: Can't actually say that you have to process everything in the header
Mark Jones: Malformed XML faults, range from grossly defective syntax and semantic issues before you get to the first application things. Is it completely uniform?
Henrik: SOAP doesn't talk about the implementation model behind it.
Henrik: HTTP intermediaries are not SOAP intermediaries.
??: Is an intermediary allowed to transform a message?
Henrik: HTTP has a mechanism for identifying what intermediaries can and can't do.
Noah: SOAP Fault model - how does it deal with non-fatal problems with the intermediaries? How does SOAP handle it?
Noah: SOAP doesn't really have a complete request response model. It really is sort of a one way message and uses an HTTP channel for returning the error messages. XP should look to be sure that we address things like this.
Henrik: SOAP believes that this can occur using a SOAP header.
Glen: To what things does the encoding style apply? If data of an arbitrary scheme were to be included, then you could use an encoding style for everything
Noah: If no encoding style is used, then basic XML applies. An encoding style would be used to indicate a particular model, such as graph, structure, etc. for which a particular schema would apply.
Henrik: No default encoding styles are assumed.
Noah: Schema is not viewed as an encoding style. Without SOAP doing anything, this is an XML document. Encodingstyle indicates where to get the directions on how to interpret things.
Tom Breuel: DCOM via SOAP? What is the relationship between DCOM and SOAP?
David Ezell: DR303 should be dropped
PROPOSAL (Fallside): DR303 should be dropped as it is incorporated in DR301.
POLL: No strong objections - DR 303 is removed from the requirements document.
David Ezell: DR 305 facilties are what we are expecting that our end work product will contain that will help people implement features like authentication, payment, etc. A facility might be an attribute that gives you a convenient place to put a designation to explain what that feature is. Encoding is an example of that kind of facility.
Vidur: Part of the framework is a set of extensions that can be used to build XP modules?
Glen: Would like to do whatever we can to standardize on extensions where possible to convey semantics.
David Ezell: Trying to say what we expect the work product would do. How this is designed is different.
Ray Denenberg: Try to come up with a purely fictitious feature and try to come up with a concrete example.
Yan: Agrees
Oisin: This particular requirement is good, but should be taken as guidance for the 700 series of requirements where the extension mechanisms are defined. The word implementing is troublesome. We should be decoupled from the implementation in some fashion.
Frank: Is this what we talk about in XP Modules? [Could be] Doesn't this belong with the discussion of XP modules?
Mark Nottingham: There was discussion that these kinds of requirements belong in a "guiding principles" document, but that document went nowhere. Call for testable requirements.
David Burdett: Would exclude payment, but not encryption, security, etc.
Paul: Describe exit criteria.
Mark Nottingham: Exit criteria. How do we know we met our requirements?
Paul: Exit criteria don't have to be totally objective.
Ray Denenberg: A lot of the requirements talk about "should not preclude", but it's not clear whether this is a requirement proactively putting in facilities or not precluding them.
David Ezell: Cautious being proactive.
Fallside: A lot of suggestions on outcome - go to other guidance section, change the implementation wording, needs more examples. This is still amorphous. We could contemplate having another section or scope this down.
Noah: Not totally sure there is a requirement here. These may feel like good things to do, but may not be a requirement. Proposed resolution is to put on the list of things to think about during the design phase. First choice is to delete it, second choice is to downgrade.
Jim Trezza: Didn't hear any strong opposition to this. First draft leave it in, maybe associate with extensibility mechanisms.
Paul: Reminds him of a requirement "used by the desperate Perl hacker".
Ray Denenberg: "Such facilities might include" should be changed to "such facilities must include" or it should be downgraded.
Fallside: Make it not a requirement Leave it as a DR Upgrade it as an R ??: Are we going to think about really how they might be done or are we talking about possibilities?
David Ezell: this has a long heritage from draft requirements. The words are remnants of other requirements.
Fallside: Leaving this as a DR would mean that it has not reached consensus in the working group.
POLL (Fallside): Drop the DR 305 from the document entirely? 10 in favor
POLL (Fallside) Leave the DR as is for the moment? 19 in favor
POLL (Fallside): Promote to an R now? None in favor
DECISION (Fallside): Leave it as a DR is the consensus.
Fallside: Action Item to section lead (David Ezell) to continue the discussion on DR 305 and come back with a proposal for what to do with this.
ACTION ITEM: to section lead (David Ezell) to continue the discussion on DR 305 and come back with a proposal for what to do with this.
David Ezell: DR309 As long as an XP exchange is info set compliant, then you should still be able to write it in a simple fashion that very small and memory constrained devices won't dismiss XP simply because it is too big and too fat.
Tom Breuel: In principle there are a lot of things that an intermediary can do to the message. Put some bounds on what can happen to an XP message as it traverses intermediaries on its way to an endpoint.
Yan: Might be better handled in a use case to describe this.
David Ezell: Shouldn't use text to describe what we're going to design.
Ed Mooney: Would saying "the specification shouldn't preclude XP on resource constrained devices?"
David Ezell: This represents a synthesis of many wordings
Paul Cotton: What does "infoset" mean in this context? XML tells you what goes into the parser, the Infoset tells you what comes out the other side. This usage doesn't make sense.
Glen: Could be processed by simple string compares.
Martin Gudgin: Concern was that XP would allow something that was not really XML and would not conform to the infoset after you parsed it. There is a base level of entry here - if you don't understand infoset then you don't play.
Paul Cotton: Conformance is to XML 1.0 plus namespaces
Martin Gudgin: Not correct - we should be layered on top of the infoset, not XML 1.0 plus namespaces since everything else is done that way.
Noah: It should be a requirement or a goal to state that people who can only process simple messages may do so. Do nothing to preclude infoset.
Paul Cotton: Unacceptable to state that we have XP conformant product that uses ASN.1 as its transport. You cannot separate the infoset from the other specs.
Ed Mooney: If the issues is really footprint, then the wording is unacceptable.
Yin-Ling: Requirement 307 talks about the XP specification being simple to understand and implement. If the intent of 307 is small footprint, then isn't this subsumed?
Glen: This should be specifically called out.
Fallside: Proposal leave this as DR and send back to the section lead Another idea is to split out into multiple requirement No vote
Ray Denenberg: Wouldn't want the concern about intermediaries to be included as part of this requirement. Small appliance support is what this should be all about.
Fallside: Three proposed wordings? Intermediaries, Small appliances, and minimum infoset/XML support
Noah: R306 mentions resource constrained, embedded devices already.
David Ezell: R306 is more of an example
Glen: Keeping 306 as a "must" (second paragraph) makes 309 irrelevant. 306 is a more succinct description of a requirement.
David Ezell: Infoset and well-formed are there to calm the nerves of those worried we won't be compliant.
Noah: Don't confuse the bindings with the infoset. Each binding to a protocol has as its input the infoset.
Paul: The infoset is totally abstract - not an API or anything else. When you see an element, then give me an element information item. Infoset compliance doesn't mean anything in this regard.
David Ezell: The last sentence's intent is to state that we were not going to do something wild. But that's what the effect is.
Fallside: Leave this as a DR and push back to the section lead. This should include a reading as to whether R306 covers DR309.
Ray Denenberg: Read second paragraph of R306 as not part of the R306.
Fallside: Note that there was confusion as to whether the second paragraph of R306 was part of the requirement or a note against 306 or 309.
PROPOSAL (Fallside): Leave this as a DR and push back to the section lead. This should include a reading as to whether R306 covers DR309.
POLL: No objections.
Note from Noah: For the record, the 2nd paragraph of 306 is indeed part of the formal requirement on which we had voted, but Ray Denenberg (possibly among others) expressed the concern that when our email votes were cast on 306, he had mistakenly voted based on the assumption that only the first paragraph of 306 was part of the requirement. He had assumed that the 2nd paragraph was introductory to 309.
Ray: Not only should the receiver determine whether or not it is capable of processing the envelope but it should also be able to determine how the return envelope should be created. When sending an envelope, facilities should exist to optionally provide information that the receiver can use to construct an envelope that won't break the original sender.
Oisin: Compatibility information could be done by version
Glen: Would it satisfy to say that if you receive compatibility as in version information, then you are expected to reply with that version?
Ray: Yes.
Henrik: Doesn't want to get into versioning on this issue.
Noah: Starting with a notion of one-way messages and heading towards round-trips. This is premature. We should commit ourselves to considering evolvability, but not more than that. Leave issues of long-term evolvability for the future.
Jim Trezza: We are premature on the discussion of processing.
Oisin: This is just in general terms since we don't know how to do this yet. We can't yet say what the information is.
Ray: It's not the idea of round trip. It's the idea of being able to propagate what your capabilities are.
Oisin: Not precluding this since we're extensible.
Ibbotson: Concern if a receiver is making assumptions about a sender, then we are getting into symmetrical capabilities.
Fallside: This might be something that goes into an extensibility mechanism.
Ray: Will accept putting aside the symmetrical capabilities for capabilities expression.
Fallside: Other issues?
Glen: Proposes deleting the last sentence of DR702
Oisin: Agrees
PROPOSAL (Fallside): Remove the last sentence of DR702 starting with "Furthermore".
POLL: No opposition, DR will change to remove that sentence.
??: If a processor is unable to process a message, is there a requirement to return a fault?
Oisin: addressed in R700b
Henrik: If you generate a fault, what happens in that fault is undefined at the moment.
Martin Gudgin: 702 is talking about evolution, versus extensibility, as in when we come up with version 2 :-)
PROPOSAL (Fallside): Add a sentence to 702 to require generation of a fault if incompatible messages are received.
POLL: Slim majority against adding that sentence. Sentence won't be added.
Fallside: Proposal we accept this DR as an R, with the amended wording proposal from before
David Ezell: This is a particularly important requirement, but there is something in it that bothers him. We might want to adopt a mechanism rather than define one.
Glen: Doesn't think that is incompatible.
PROPOSAL (Fallside): Accept 702 as amended by deletion of sentence (see above).
POLL: Unanimous consent.
Fallside: Change R703a to say error, not status
PROPOSAL (Fallside): Change "Encapsulation of Status" in title of R703a to "Encapsulation of Error".
POLL: No dissent.
Fallside: Proposal that we accept DR811
Martin Gudgin: Intermediary processing is a can of worms that we should not deal with now.
Noah: This is a charter issue
Mark Jones: In SOAP are intermediaries a solved or unsolved problem?
Henrik: We have to have intermediary support from the beginning otherwise we won't be able to support it well later.
Fallside: The range of intermediaries specified in the charter would indicate that we have support for processing intermediaries.
Tom Breuel: The term processing intermediaries is too general Mark Nottingham: This is a hook, essentially
Martin Gudgin: Can we put something in the wording that uses our own extension mechanism to define this? Instead of as a specific requirement
Fallside: This might be a new requirement.
Mark Jones: "must" might be too strong
Glen: We already say that we must support extensibility and while there may be processing intermediaries that aren't a good idea, that doesn't mean that we shouldn't support them.
PROPOSAL (Fallside): Proposal that we accept DR811 and move it to "R" status
POLL: large majority, no strong opposition
Glen: Transfer/Transport/Application
Ray: Need a dot dot dot in the picture
Mark Nottingham: Intermediaries now use the term transport so that terminology would change
PROPOSAL (Glen):
POLL: "Carrier protocol" versus "underlying protocol":
Carrier protocol: 10
Underlying protocol: 20
Dissents from either choice: 3.
DECISION: We will discuss tomorrow when and how to do necessary editorial changes
DECISION: Diagram as edited at the meeting is accepted. "Underlying protocol" is the term adopted.
Fallside: Issue of how we relate underlying protocols to the use of the term "transport" intermediaries
Fallside: Do we need this stuff in the requirements document, given that this is already in the charter?
Mark Jones: How do we deal with out-of-scope requirements when use-cases bring up conflicts?
Fallside: The charter is non-negotiable.
Mark Jones: If we have a significant body of use cases that require, for example handling of binary data, how do we accomplish our efforts
Randy: The charter does include handling of binary data with the proviso that it is base 64
DECISION (Fallside): We will avoid attempting to change our charge (e.g. to change the charters' approach to binary data)
Henrik: Proposes deferring discussion until we have use cases to review in this regard
Stuart: DR119 is not even a requirement, not a discussion
Ed Mooney: Agrees
Glen: At this point, the requirements are already filtered.
Noah: Are you proposing we take the charter references out of all sections?
Glen: No.
Ed Mooney: It's problematic introducing out of scope requirements in the document that are out-of-scope.
Ray: How do we resolve this problem?
Fallside: Proposal to drop DR 119 out of this section - more discussion follows
Noah: How do we frame all out-of-scope issues rather than on a case by case basis? Might be of value to have a section that identifies what this group is not working on. General suggestion before we get to the individuals is that they are reworded to indicate that we are not working on them, not as "positive stated" requirements.
Glen: Some of the reasons that the out of scope stuff is there so that we don't forget that this stuff is important.
Vidur: Is there a reason why we are calling them requirement? Sounds like they are issues.
Fallside: The charter says that we will not handle binary data, but we can consider other solutions
David Burdett: Is there sufficient interest to discuss binary data? Is this a charter loophole
Fallside: As chair, makes the assumption that there is sufficient interest in binary data. What the charter talks about is how to find an implementation of binary data.
Kay: Out-of-scope issues shouldn't be listed as requirements. They should be listed as issues or should be moved from out-of-scope to in-scope.
Tom Breuel: Direct handling of binary data sounds like unencoded handling, not base64 encoding. In what cases does XP care about the binary data itself?
Henrik: We shouldn't invent new mechanisms to handle binary data.
Ray: We should go directly to DR040 and determine if there is sufficient interest and then go back to 119 and role it into DR040.
David Burdett: If you have an XML that is digitally signed without the basis for encoding it …
Fallside: What are the particulars for the requirement?
Noah: It's tricky to not think about this issue but about someone else's solution. Envisioning 119. Background - quote charter, consistent with this charter the group agrees that give consideration to use cases and think about these issues (does SOAP plus attachments meet the need?). We can invent this stuff, but nothing prevents someone from being one of those outside group that could be invented to solve this problem. Formally we're not going to invent new things …
Fallside: Noah has described what the charter might identify as other groups
DECISION (Fallside): Agrees with an interpretation by Noah Mendelsohn that that the phrase "The workgroup can consider soltuions proposed by other groups" does not prohibit members of our workgroup from, on their own time, considering a variety of solutions, perhaps formalizing them as W3C notes, which can then formally be viewed by our workgroup as such "solutions proposed by other groups". The charter clearly seems to signal that original design of such proposals should not directly be a work item for our group.
Ed Mooney: Drop DR119 and use the charter to inform our discussion of 008 and 040.
Fallside: Make DR119 opening text and add a requirement that XP must handle modular or binary data. As to the question of is there interest in doing this, we are all likely to vote "aye" for DR008.
PROPOSAL (from Glen) Take the text of DR119 and turn it into a contextual piece of this document that speaks to how we are going to approach meeting potential requirements such as DR008. We will leave it to the editor to determine how to incorporate this into the document.
DISCUSSION ON PROPOSAL
Ed Mooney: Would rather not do this until we go over all of the out of scope requirements?
Ray: This has the effect of combining 119, 008, and 040 into a requirement.
POLL: large number in favor, 2 opposed
Fallside: Opening discussion of DR008
Glen: DR008 and DR040 should be combined
Randy: Doesn't R401 cover this?
Fallside: Using Schema, we essentially handle binary data.
Tom Breuel: Can we transfer in encoded form, directly, and are XP processors expected to be able to handle binary input, as in an entirely binary encoded message?
John Ibbotson: The issue of binary data is an attachment, not something inside the XP
Noah: Various kinds of arbitrary data that we haven't covered. Suggests that we make clear in DR008 that it's not just binary but covers many kinds of data and move it up (into scope).
David Burdett: Attachments are just one solution and we need to address other solutions as well.
Fallside: We've gotten into the trap of assuming that we have separate requirements for carrying each type of data
Noah: Doesn't want to say that if this is at all problematic, then it's an attachment. Immediately assuming it's an attachment is not the right mindset.
Tom Breuel: Take the warning of DR119 seriously. Like to see the other two requirements indicate that we should use existing methods.
David Burdett: We should name the mechanisms we want to use to do what we do. We should also state that the arbitrary content can be of any size
Oisin: Why doesn't 700 cover this? Application specific content is arbitrary data and the 3rd parties mentioned in 008 are applications. We could update R700 to incorporate the content of 008.
David Burdett: 700 doesn't cover changing the information.
Mark Jones: We can tunnel whatever we want, but at some point it blows up. The point is are we doing this in a direct or fair way.
Noah: Without changing it - does that mean without encoding it?
PROPOSAL (Oisin): Delete DR040 and DR008. We will develop a proposal to update R700a to include selected aspects of DR008 and DR040 into DR700. A side effect of this will be to make those aspects into in-scope requirements. Pending formal adoption of the changes, R700a remains an R status requirement in its unchanged form.
DISCUSSION ON THIS PROPOSAL:
Ed Mooney: Just confuses things. Would prefer that 040 and 008 be addressed head on.
David Ezell: We could be adding months to our efforts
Oisin: This doesn't put it in scope, but it puts it into consideration for scope.
Henrik: Does this mean that we're really moving this into scope? Not really.
Tom Breuel: Would not be a major change to add binary and XML to this now.
Glen: We don't really have to do this now. We can let Oisin make the proposal.
POLL: Large majority in favor. Chair observes that, as a result of the previous vote, the editor has some discretion as to which section of our requirements document will carry the "contextual" text resulting from the rework of DR119.
PROPSAL (Fallside): Give section 700 lead (Oisin Hurley) responsibility to propose text to "beef up" R700A in accordance to previous proposal.
POLL: Large majority in favor
PROPOSAL (Glen): Entirely delete from the requirements document section 4.2 and DR120.
Glen: This is covered elsewhere by discussion on memory challenged devices and low bandwidth
Henrik: This is not entirely for small memory devices, but also for wireless.
Paul: No problem deleting it, because when there is a dispute we go to the charter. Some of the discussions seem to be to the contrary to the spirit of what's here, in particular the discussion of XML 1.0.
Glen: This doesn't preclude people from developing bindings that use compression and encodings …
VOTE: Large majority, one opposed - Microsoft dissents. Chair requests Henrik to send explanation to Noah and/or WG list for inclusion in minutes. Henrik has since provided the following text: "This is not a strong objection but rather an observation. While stated in the charter, I think this issue is often discussed (especially in connection with slow/low bandwidth connections) and may merit a section in the requirements document as something that we acknowledge (which should of course include a link to the charter). Note that this is not an attempt to modify the charter as stated but rather indicate the awareness of this issue by the WG. Henrik Frystyk Nielsen (Microsoft)"
Mark Nottingham: BEEP or BXXP?
Henrik: What is the requirement here?
David Burdett: Can we change this into a positive requirement which would make sure that it does not preclude binding to other requirements.
Noah: We've put pieces of the charter into a proposed requirement and then "tune it up". We've signaled in 612 that we will do an HTTP binding. Proposes dropping this.
Mark Nottingham: Supports dropping it.
Paul Cotton: Not enough must, should or may to be a requirement. If we already have a requirement for binding to HTTP, then this is redundant.
PROPOSAL: Drop (unamended) DR121 from the requirements document.
POLL: Large majority in favor
PROPOSAL (Glen): Would like to explicitly state that we will do another mapping to make sure that we are protocol independent.
Martin Gudgin: Falls into the same category as binary data, the interest is there and we will do this if there is enough time.
Glen: Proposal withdrawn
PROPOSAL Withdrawn
PROPOSAL (Martin Gudgin): Drop (unamended) DR 122 (but we will retain the identical text in the introduction to section 3.6).
POLL: Large majority in favor, no opposition
PROPOSAL: Drop (unamended) DR123 (but we will retain the identical text in the introduction to section 3.6).
POLL: Large majority in favor, no opposition
PROPOSAL (Jean-Jacques): Drop DR025 and associated issue from the requirements document.
POLL: Large majority in favor, no opposition
PROPOSAL (Jean-Jacques): Drop DR028 and associated issue from the requirements document because this is covered in R502
DISCUSSION
Martin Gudgin: R502 says that we will not preclude the development, but 028 says that we will do multicast.
Frank: Is there a difference between multicast and publish-subscribe?
Marwan: Multicast does not require a subscribe.
Noah: If we really should do multicast, then we need to beef up R502. If we're "not precluding" multicast than R502 is okay the way it is.
VOTE: Large majority, no opposition
Martin Gudgin: We should drop this because it says that we won't do it.
Mark Nottingham: Raw TCP binding is a big undertaking. Ray: It may be a large undertaking, but we don't want words that preclude it. Lost the wording about the TCP port.
Glen: Agrees. Would like to revisit the original wording. Wants to strike this as a requirement and have this text as context.
Ed Mooney: This proposed wording is the reverse sense of the original.
Henrik: In favor of dropping it. Does not want to select a port.
PROPOSAL (Jean Jacques): Drop DR022 and associated issues and section 4.3 in its entirety
VOTE: Large majority in favor, Library of Congress dissents. Ray has since provided the following formal text: "My dissent is based strictly on the "port" issue. We want XP to run directly over TCP. I am convinced there is strong sentiment for this within the working group and I'm satisfied that the requirements document covers it in general, and that section 4.3 can be safely dropped, except for the reference to port number. Admittedly the port issue is not well articulated in section 4.3 -- I would be content with a simple statement saying something like 'the WG envisions that a TCP port number will be assigned for XP directly over TCP'. I'm sure the WG believes that XP needs a well-known TCP port, but doesn't think it needs to be explicitly mentioned in the requirements document; I do think it does. Several arguments have been offered for not including the port reference; none of which convinces me, and instead, they re-enforce my opinion that silence on this issue will only confuse readers of the document who have not had the benefit of participation in the discussion. Specifically, I am concerned about the potential inference that XP is intended to run over HTTP (port 80), mainly to avoid firewalls, and that running over TCP is a degenerate case, whose mention is included as an afterthought. (Ray Denenberg, Library of Congress).
Alex: Most of these comments came from the initial face to face.
Oisin: This text is already in the charter?
Alex: Yes. This is also covered in DR305, how we do the features and so on.
PROPOSAL (Alex): Drop DR124 from the requirements document.
POLL: Large majority in favor, no opposition
Alex: Verbatim from the charter.
Glen: Prefers dropping it rather than having explicit requirements that state we aren't going to do something.
Paul: This is a non-requirement. It should go in a "non-requirements" section if anywhere, rather than called out as requirements. Preference is to list them as non-requirements.
PROPOSAL: Drop DR125 from the requirements document.
POLL: Large majority in favor, no dissent
Alex: This may be necessary for RPC.
Glen: 006 is dealt with implicitly by stating that we are going to support request response scenarios rather than intermittently connected
PROPOSAL: Drop DR006 and associated issues from the requirements document.
POLL: Large majority in favor, no dissent
John Ibbotson: This was discussed in Raleigh as part of perhaps identifying a JavaBean that might be referenced.
Paul: That's higher level semantics.
Vidur: If this means that we're passing objects by reference, then this is a non requirement.
Oisin: This recognizes the fact that there is an underlying protocol end point and then an XP processor end point that can process …
Noah: Three abstractions on the table - include in the data model an ability to specify references to web resources (a less prejudice term than objects), next level is the subset of resources that implement XP services, third level means things that have lifetimes, gc, and release semantics and we don't want to go near this. Doesn't know if we need anything in the requirements document, but if anything, only the first level would be appropriate.
Henrik: Given that there is a requirement in the 400 series and hidden in the 700 series, that we don't need to say anything more?
Noah: If we know where we're going, then do something simple and get on with it.
Tom Breuel: If we need this, then it should be driven from other parts. Would suggest dropping it as an explicit requirement.
Jean-Jacques: Believes that this has been rephrased more generally by R403.
Yin-Leng: Also in R200?
PROPOSAL (Fallside): Drop DR019 and associated issue from the requirements document.
POLL: Large majority in favor, no dissent
Alex: R807 use case overlaps this
Glen: Do we want to take a set of the use case extensions and make them part of the requirements? Proposal would be to drop this pending other requirements coming out of the use case analysis.
PROPOSAL (Glen): Drop DR027 and associated issue from the requirements document pending the potential requirements that may arise out of use-case analysis.
Glen: The requirements from use-cases is that these might be things to support.
Ray: Since this is a dominant duplicate now, what do we do about that?
Alex: Doesn't recall what the original issue was.
POLL: Large majority in favor, no dissent
Alex: This is also a use case DR805.
PROPOSAL (Glen): Drop DR031 and associated issues pending the potential requirements that may arise out of use-case analysis.
POLL: Large majority in favor, no dissent
Alex: Original intent is that we don't talk about UI. This looks like 700 and 305.
Noah: What does it mean to send an XP message to a user?
Henrik: The HTTP spec falls into the trap of saying how to interact with the user. What makes sense for specific applications is not our domain. Intent is on "should not define that UI".
Tom Breuel: We will almost certainly have requirements that preclude UI interactions. Proposes dropping it as too restrictive. Anticipates that we will define interactions where someone sends something to the recipient that causes an error that is not acceptable for the server to display to the user.
Henrik: Specific example of a fault - which might have a sentence intended for a human user - but is not a fundamental piece of making XP work.
Ray: Unclear about the discussion. Which human? The one on the sending end or the receiving end?
Henrik: Intent is to say that there is no human.
Glen: XP allows machine to machine or app to app communications without human intervention.
John Ibbotson: In this context, isn't intervention an application issue and therefore would cover this since we don't address applications.
Glen: Proposes dropping this …
PROPOSAL (Glen): Drop DR033 and associated issue with the understand the understanding that we will next discuss the other means of expressing a reluctance to require UI interactions when processing XP messages.
POLL: Large majority in favor, no dissent
PROPOSAL: End the discussion regarding UI interaction.
POLL: Large majority in favor, no dissent
Alex: Drop because this is duplicated elsewhere. It should be the higher level, not at the protocol binding level. Call out DR305.
Fallside: Two issues under DR046 was to create examples.
Frank: DR608 is downward looking. Do we need to call this out explicitly or is this handled by more general phrases?
Henrik: Should be do things in our specific layer or push it up the stack?
Mark Jones: 608 says that we shouldn't preclude it but 046 says that we should do it well.
Frank: SSL and SMIME are already presented in 608, but DSIG isn't mentioned. We should apply the should not preclude to DSIG.
Paul: What could we possibly do to preclude it?
Frank: Is this already addressed elsewhere?
PROPOSAL: Drop DR046 and associated issue from the requirements document.
POLL: Large majority in favor, no dissent
Henrik: Given the examples, drop this as a must.
Noah: This is a non-requirement, but in certain context might be needed and is a heavy burden for small devices. Believes that this is an inappropriate requirement.
David Burdett: We won't always need one, but if we do one we need to have a specific way of doing them.
Glen: This is very different from 006.
Tom Breuel: In favor of dropping it.
Henrik: What is global and unique?
Mark Jones: What are the use cases behind this? Whose job is it to arbitrate standards for URIs at this time?
Mark Jones: In the transient life of a message, having a message identifier is a good thing.
Ray: There will be modules that have globally unique identifiers that would be out of scope for this work. If we need this, then we need to define a URI scheme for this.
Tom Breuel: Intermediaries, if we think this might be useful for a large breadth of applications, then we might want to do this.
Mark Jones: This might be so ubiquitous that we might want to include this.
Noah: One thread is, aren't these things useful? Experience in building those systems shows that globally unique identifiers are neither global nor unique. Doesn't think we can actually get there. Proposes dropping it.
David Burdett: Without some way of identifying that message, problem referring to it. Problem is not how we generate unique identifiers, best effort is okay there.
Oisin: Extensibility might play into this.
Henrik: This should be dropped.
David Ezell: This should go to the URI interest group rather than coming up with a home grown suggestion.
Glen: This should be dropped based on the dropping of DR006.
Ray: Does not want to drop it and would change words to "message must have an identifier". Put a slot for an ID for someone else to define.
Tom Breuel: We should drop the requirement, but many use-cases will force the need for an identifier.
Paul: The requirement to have this feature is a solution, not a requirement. This is a constraining requirement.
Ray: Agrees with Paul.
Noah: Saying something in the requirements is a signal we will do something, not saying something isn't a signal that we won't do it.
Dick: ebXML has a message ID today, thinking of ebXML as an XP module. This was put in to detect duplicates so maybe there's a requirement to detect duplicates.
Tom Breuel: Does this mean the message from one end to the other or do intermediaries play in.
Jim Trezza: Dropping this because of RPC pairs isn't broad enough since the requirements only cover RPC pairs.
Jim Trezza: The group feels that this is more of a solution than a specific requirement.
PROPOSAL (Fallside): Drop DR051 for the reason that it appears to be a solution rather than the requirement.
POLL: Large majority in favor, no dissent
Frank: 502 says that we won't preclude interaction patterns.
Fallside: Overlap here.
PROPOSAL: Drop DR058 due to significant overlap with existing requirements.
POLL: Large majority in favor, no dissent.
Alex: Duplicate of several requirements, e.g. 305, discovery of service definitions is layered on XP as part of 700 and 305.
Vidur: Discovery of services is interesting and important but out of scope.
Fallside: Already well covered in the charter.
PROPOSAL: Drop DR065 because transaction support and security overlap existing requirements and service discovery is out of scope.
POLL: Large majority in favor, no dissent.
Alex: If we drop this one then we drop the whole section.
PROPOSAL: Drop DR069 and the entire section.
POLL: Large majority in favor, no dissent.
Vidur: We are relying heavily on the charter to clarify out of scope items. Where do we state our reliance on this? We should state this in an introduction that the charter guides our selection.
Frank: Are these going to be addressed in a different working group or activity?
Fallside: Possibly.
PROPOSAL: Drop DR126 and DR127 and section 4.5 as duplication of the charter. The editor is instructed to identify in the introduction to the requirements document that the WG charter guides the selection of requirements.
Ed Mooney: Why are we introducing it at this moment?
POLL: Large majority in favor, no dissent.
DECISION: We have reconfirmed that all of the above are informal sense of group polls, not formal W3C votes. We will therefore informally agree to include text of any emails received in relation to "dissents" in the published minutes, but unless specifically signaled by the respondents, none will be considered to be formal W3C dissents in the sense of the W3C process documents.
DECISION (Fallside): All polls above are indeed to be acted upon. The requirements document is to be updated accordingly.
Canon has offered to host the next meeting
Jean-Jacques: 2 hours from Paris by plane or 3 hours by TGV from Charles De Gaulle airport.
Fallside: the Chair accepts and puts forward a proposal from the floor for a 3-day f2f meeting to be held 5-7 June 2001 in France, and hosted by Canon.
PROPOSAL (Fallside): preference poll on week of 28 May for f2f meeting in Rennes versus week of 4 June.
POLL: Week of 28 May: 10 + 7 live with (all can live with it based on recheck). Week of 4 June: 14 + 5 (one cannot live with). Net preference is perceived to be for 5 through 7 June. Subject to a final check, chair signals that these will be the dates for a face to face meeting to be held at Canon in Rennes, France.
Martin Gudgin: Piece of code which does the processing would be called the XP handler Syntactic construct inside the message body and XP block The two together is known as an XP module
Stuart: Doesn't feel like it lines up with HTTP stack to XML protocol binding
Martin: take Glen's diagram to replace the bottom two parts of the diagram
Mark Jones: Why are we putting the syntactic name XP block on top. Would have expected XP Block in place of XP module in the diagram.
Andrew: The message as a whole is XP block?
Martin: The XP block is syntactic thing that appears inside the header or body where there may be one or more of them.
Henrik: XML protocol talks about things that we own and XP module talks about things other people are building
Ray: We're confusing protocol in the context of this group
David Ezell: First part of the diagram is appropriate, but …
Glen: Two version of this illustration will confuse people
David Burdett: We are going to tell people how to create them so they work
Ray: Thinks that this is appropriate for the requirements document
Jean-Jacques: One picture is enough. The one on the right looks like it is talking about the client, not about the wire, which is what we are focusing on.
David Ezell: Seems as though it might be appropriate to have more than block per module.
Mark Jones: Maybe we should just delete the left hand diagram showing XP Module.
Tom Breuel: XP Module
Kay: Handler seems to be the incorrect term for describing the state machine and the message patterns that would occur for particular XP blocks. This isn't really a handler, but rather what we would think of as a protocol.
Fallside: Can we live with what was proposed? We will go over this in the next 10 minutes.
Glen: There are some issues and readers will look at pictures. We need to get this as close to right as possible.
Ray: A subset might be able to put this together later.
John Ibbotson: These diagrams look more like design diagrams rather than requirements diagrams.
Noah: Any glossary we do has to give us a vocabulary.
Henrik: We don't need to come to complete agreement today.
Dick Brooks: Proposes taking them as they are
Mark Jones: Is this close that we should accept this or are these misleading.
David Ezell: Accept with the HTTP diagram normalized to Glen's diagram.
Frank: Uncomfortable XML protocol and XP module. Maybe use XP Block Protocol
Henrik: If we need to get a document out by Monday, then we need to have a version out by tomorrow night and submitted Monday.
Paul: Have the editors run this by the verification process for publishing?
Noah: Working drafts can be published and republished.
Fallside: Concern is that the holes aren't so deep …
Jean-Jacques: Better to postpone the glossary changes. There is a protocol that already uses the term "block" (BEEP); so we should use another term.
??: The picture that we had yesterday was one that some people were happy with.
Glen: Suggests making the converse proposal that some of these things might change and to request input
Fallside: Standard practice is to put a request for input on a document
Tom Breuel: Is the glossary supposed to be part of the standard
David Ezell: Accept this as proposed by Martin
Glen: Expand the binding and protocol blocks without diagram 2
Vidur: Change the definition of the handler, to something that is added to an XP processor.
Glen: You can just as well build a device that has XP Processors and handlers built into the same code
Noah: Our definition of an XP handler is an abstraction that refers to the processing of the block
Noah: Definition of an XP handler - An abstraction for the processing and/or logic required to implement a feature or function typically through the transmission or exchange of XP blocks.
Jean-Jacques:
PROPOSAL: Drop glossary, publish as it came into this meeting, publish with the changes presented by Martin. Vote once on one of these things
POLL: Drop glossary - 0, Publish without edits - 0, Publish with Martin's edits - Large majority in favor, no dissent
PROPOSAL: Affirm that editors are instructed to do those changes
POLL: Large majority in favor, no dissent
PROPOSAL: Drop header for section 4.5 (which is empty as a result of previous decisions)
POLL: Large majority in favor, no dissent
John Ibbotson: Drop the entire section and use the minutes as the placeholder
PROPOSAL: Drop chapter 4 (Out of Scope Requirements) with the implication that the text from 119 will find a home somewhere else (see earlier polls).
POLL: Unanimous
DECISION (Fallside): Editorial direction to fix broken links
PROPOSAL: Delete DR066 and DR067
POLL: Large majority in favor, no dissent
PROPOSAL: Delete DR048 and all of Chapter 6
POLL: Large majority in favor, no dissent. Editor will put a bit of explanatory text, e.g. for use case section, and maybe for wat a DR number is. Update section 2 to reference section 9.
Henrik: Chapters 8 and 9 for the moment should be left as is.
Stuart: In the 300 series there are references to the original DR numbers that need to be deleted. E.g. section heading R300 (absorbs old DRs: DR023, DR0053, DR088). We should delete the elements in the parentheses.
Noah: We should identify in "Use Cases" that this is a placeholder. We should also leave the old numbers in there also, with an explanation about where they came from.
Fallside: Put explanatory text in.
Yin-Leng: Should be put explanatory text on section 2 also?
Paul: Needs a definition of MUST, SHOULD and MAY. Look at a survey of other requirements documents. On the next round, we should look at adding this on the next round.
Henrik: We should be careful because we are placing requirements on ourselves.
Kay: This requirements document is about XP, not about the XP working group. Therefore the document should be scrubbed (not in this version) to revise requirements statements to talk about what XP must, may or shall do. Remove words like specification, etc.
Noah: We should keep the term in-scope requirements and explain it.
Noah: We should get a reading on whether the requirements document should talk about what the working grouping is doing or what the protocol is doing.
Henrik: Not saying what the document does or doesn't do, but when you put strict requirements on something we need to put it onto something.
Paul: This document should be entitled XML Protocol Draft Requirements.
PROPOSAL (Fallside) Change title to XML Protocol Requirements with the implication that this document is requirements on the protocol itself and not on the working group as a whole in any other sense.
POLL: Large majority in favor, no dissent
PROPOSAL (Fallside) Change Section 3 to "Requirements" (as opposed to "In Scope Requirements") and to instruct the editor to delete the sentence that follows as well as clean up the text that makes the distinction between in-scope and out-of-scope.
POLL: Large majority in favor, no dissent
PROPOSAL (Fallside) Submit this requirements document as amended by the changes at this face to face to the W3C for publication as a Working Draft
DISCUSSION
Henrik: Send something out by tomorrow night and review by the Sunday night so that it can be submitted Monday.
POLL: Large majority in favor, no dissent
ACTION ITEM: to David Fallside to do a legal search on the use of the term XP, e.g. trademark conflicts, etc.
Fallside: We must remember to think about time allocated to Use Cases
Glen: intro to use case discussion
David Ezell: Use cases should be an abstract representation of that real life thing. Voice of the prose should be as active as possible and the nouns and verbs should be reused as much as possible. It can be then picked apart to determine whether or not we can do it.
Henrik: Be specific and use our terminology
Noah: Certain use cases are tied to the implementation technology. You want to use the independence of the use case as a cross check … Start to map it then to your terminology and assumptions.
Ray: Number of folks interested in Z39.50 and are interested in using this over XP would be happy to create a series of use cases.
Noah: This is something that we want to have broadly applicable and will need to keep as small as possible. Develop use cases accordingly …
ACTION: to Henrik to post the SOAP/1.1 presentation
ACTION: to David Ezell as section lead to propose an eventual resolution, which could be how to take 305 to "R" status, drop it, etc. as appropriate.
ACTION: chair to do legal search on XP trademark conflicts, etc.
ACTION: there was discussion of an ongoing action to Sim Simeonov, but I don't have details.