XML Abstract Model Subgroup telcon, Jan 30, 2001

Attendees

Look at the major elements in the current drafts. Major parts missing, or new
contribution. How do we manage the document.
then more technical discussions.

Why do we need an abstract model?
SW: In summary, the XML Protocol abstract model establishes a
set of useful concepts for developing.  The abstract model contributes to
the XP design work.  The subgroup agrees with the objectives and role of
the abstract model.

SW: iterations of the document for the f2f meeting
    plan is to have somthing by feb 9. Meeting: weekly? more?
OH: it is better to do this too often, then changed according to this.
SW: weekly ok? -> taking that offline. tentative plan for one week.

Document check:
* start is a diagramatic overview
* largest part is then abstract processing model, major part of the draft.
* how module processing is done in the layers
* operation through intermediaries.
* bindings, pretty small as of now. (interesting stuff here should be donw wrt
  payload/attachements)

SW: The diagrams and terms in this document need to be aligned with
    the glossary of terms in the XML Protocol Requirements.  Are the major
    elements in the current draft?  Are there parts that are missing or
    need to be added?
LT: The XML Protocol Abstract Model document is well formatted.
    The subgroup discussions may lead to adding or changing some items in
    the document.  Overall, the document looks pretty good.

MB: sec 2 maybe too details (strawman definition for XP).
JJM: detail in the section is about right, thinking about parameters and 
     their meaning is useful.
 

AMG Process

Current plan is to distribute a revised draft of the XML Protocol Abstract
Model document before the F2F meeting (2/9).  Should the subgroup have one
or more weekly teleconferences? If so, when would be a convenient day and
time?

OH: It would be better to schedule the telecon often.  It would be
    easier to cancel a scheduled telecon than to set-up a new one.
SW: The discussion on telecon scheduling will be taken offline (in
    consideration of a full 90-minute agenda).  Based on the e-mail
    responses, there are 5 people would be available for a 2/1 telecon.
    Tentative telecon plan is a week from today.

SW: I can continue editing, but other contribution are welcomed. The subgroup
    members could be noted as editors to the document.
MB: It is not clear whether they should be called editors or not.
    people should contribute, but calling editor or not is not clear.
MB: we can have contributor/editor at the end
-> SW continues to be the editor.
NS: is it a standalone document? Where does this document fit in the family of
    XML Protocol documents?
SW: it could be a roadmap for the documentation, an introduction for a bigger
    document. 
NS: it is then quite standalone then.
LT: Will the document be published internally (i.e., W3C and XP WG)
    and/or be made available publicly?
SW: XP WG has not decided what to do with this document, we will sort this out
    at the f2f when we will have something more robust
LT: looks good.

6: 
Described: 2 best-effort services, datagram (one way) and req/rep.
Path is pulling intermediaries into a kind of layer. 
Inclusion of the notion of path pulls thinking of intermediaries down into the XP layer.
May be better to think of intermediaries as being above the core XP layer.
Might (usefully) lead to separate working on a message routing/path module
above the core rather than integral to.

initiating client -> responding client through intermediaries.
message routing and/or processing?

OH: agree, not end to end directly (hope I got that ok).

(SW got caught up in some local administrative difficulties over the room he
was using!)

SW: partial pb through intermediaries, should we dig into that?
is best effort good enough? or should we have mechanism in the XP layer to
select reliability. reliability, order-delivery and such.
MB: just the word reliability is overused.
JJM: it would be good if we have something that could be extended for QoS, it 
     should not be in the core system.
JJM: about intermediaries and doing hop by hop instead of end to end, do you
     have SMTP in mind or not? (error messages).
SW: from the XP point of view, you address only the next hop in the chain, so
    thinking about PATH is separated from the core. Mark was using the word
    "terminate", the hop may interact with another node, but we don't have the
    notion of PATH.
SW: for reliability of in-order, if we have to say simgle hop or along a path,
    things can get pretty complicated.
NS: According to the diagram on page 1 (Abstract Architecture), the abstract
    model suggests that there is a routing intermediaries and then a connection
    is maintained as point-to-point
SW: the notion is XP is a layer to something that uses it, it is client not in
    client/server but for the program.
MB: I would just add hook for transport intermediaries
NS: The Abstract Architecture diagram shows a single request-response client 
    dialogue. It should show multiple response clients such as for multi-cast.

SW: ACTION, introduce transport intermediaries into the diagram

SW: Can't think of a good example for request/response pattern multicast... how
    do you know when you've had all the responses you want/need.
JJM: example for multicast, you schedule a meeting, you send a request to
     multiple people and you do the chenges only if all the responses are 
     reused.
SW: we have to take care of failure pb.

sec 3, message processing and module processing.
XP module has both syntactic elements and behavioural elements.

SW: tried to descibe the Apache SOAP 3.0 Axis architecture that appears
    builds chains of inbound and outbound handlers to process extension
    elements (cf. XP_Blocks). The processing chains being part of the local 
    configuration rather than being influenced by the 'shape' of a message.
MB: trying to integrate source routing might be better suited
SW: only few comments about XP blocks processing, distinction btw a module
    processor and an XP processor.
OH: sounds like a reasonable start.
NS: Stuart, at what point do you see the message encryption occurring in your
    abstract model?

SW: at the moment, it is somthing the application is doing before giving it 
    to the application layer -> application semantic.
SW: if you have an HTTP binding, if you have http basic auth how you get the
    credential? -> binding context is a 'bucket' for carrying useful context
    info that lower layers may need to operate, userid/password, certificates
    for SSL etc, and (not discussed) inbound context such as authenticated 
    userinfo that could effect the response.

NS: There needs to be an end-to-end secure XML protocol message flow and then
    determine what is handled by XP.  I looked at SSL as an example protocol
    external to this message flow.

SW: the  the protection of the encryption is removed to talk to the actual
    processor (http server ex).

MB: want to reuse part of intermediary model of HTTP as it is well understood
    and well defined.
NS: Section 4 & 5, Message Processing shows only request-response flows.
    Should this effort be expanded to cover the conversational flow/sessions?

SW: session/conversation is not handled yet should we do it?
SW: SOAP is intrinsicly req/resp especially with the HTTP binding.
OH: right

OH: we can say atomic interaction is one way
SW: I want to keep for now both one way and req/resp to clarify things.
LT: this document is independant of what SOAP does.
YL: connection and conversation would fit nicely in a module and demostrate
    the fact that extensions are orthogonal.
SW: is packaging (binary attachements) related to binding. Would like to
    position the encapuslation of multiple payloads/attachments, binary or 
    otherwise as a binding issue. Would like the basic XP service definition 
    to intrinsically support attachments/multiple payloads.

OH: we should send binary date, without encoding in b64, we have mime multipart
    mime is an envelopping protocol. It provides a way to separate the XML from
    the payload and being able to process only the small xml (ex).
OH: from the modelling point of view it is independant.
LT: in our work, we should see mapping to other underlying protocol, as we have
    to be generic.
SW: the goal is to use some references for SOAP but not doing an abstract model
    for SOAP, but for XP.

SW: aim to do more editing and get back to the group by the week end.