Action Item,
Service Abstracion - Henrik
-> happy with changes suggested
-> Marc Haddley has more on #6
multicast related some progress.
mapping AM, no progress
Mark's comment were on section 4 not 5
Stuart will be on holidays, need another editor during that time.
-> Mark Jones volonteer
MH: not huge comments on 5.1 comments were on some bindings used.
5.0.5 quite happy with it (binding consideartion section)
the only real question were on message exchange patterns
the other question was about error handling, what errors should we handle.
HFN: on the first part of it clarification of primitives start_req and
confirmation. what is the notion of the pipe?
MH: it depends on the underlying protocol. In beep you can make a connection
with a channel.
HFN: it is something the binding done or present in the message?
MH: the processor got to tell the binding somehow where you send the message.
see the discussion about routing part of the envelope or not.
HFN : from a mesaging POV, we don't have a channel concept.
MH: you want to remove open and close connection entirely?
HFN: yes
DF: to recap, connection is done below the underlying protocol box.
MH: how about SMTP?
HFN: fairly different, because it is not stateless, you have
connection/identification...
JJM: difference req/resp and req/multiple-resp ?
There is currently an asymetry there. Operation are not done in the same
order
MH: I have to add a comment
HFN: saying that it is just an example
SW: not restrictive.
HFN: diag 5.1 (binding model) [lost comment]
Action ITEM Marc H Introduce chimes (sp?) in 5.1 and introduction
text by friday.
HFN: 2nd para after paragraph (XMLP_DATA) is not mentionned anymore.
last paragraph in that section, we use host in the IP definition of it,
not node (see RFC723)
MJ: did we remove node?
W: node is used from time to time, but node is now defined.
HFN: last comment, term "targeted" may be replaced by "intended for"
3.1.1
HFN: what support means there?
3.3
HFN: In 3.3, I would add identidy, "sent on behalf of"
SW: it already says where the message comes from.
HFN: is it from a ip address? email address?
SW: To will be an URI, From
HFN: you have a To and a From, and it goes through many hops, From should be
from henrik
SW: that was the intent of From:
HFN: so immediate destination is a path?
SW: ongoing discussion if it is first-class or module, for now it is a module.
JJM: main one is about intermediary forward, fault discard the message.
is it the case for all failures or just some of them?
HFN: SOAP has a middle way, the message can fail, it is not garanteed that you
will have a status. If it fails it won't go any further.
Should we need a Status primitive?
JJM: what do you mean by fails? if it is just a block failing
HFN: fault IS fatal.
MJ: you can add block saying that a block is broken, but not issue a fault.
SW: regarding Status. remove the intermediary and add forward to main (@@
catched right? @@)
HFN: we only have one main operation with 4 primitives (including forward)
SW: forward don't process.
MJ: if I try to send a message to someone. 1/routing level, we should know
where to send the first message, then in the envelope, we should address
many hops, dependencies and such. How those two parts are correlated?
how the XMLP layer knows what is the correlation.
SW: 4.2 address that
HFN: the AM provides just a skeleton. There are lost of thing that is not
known when you send a message.
DF: one way of dealing with that would be the FAQ approach, ie: clarify when
needed.
HFN: that was the SOAP approach.
MJ: headers/body/attachements -> blocks, unless there is a compelling reason
for not doing so.
HFN: 2 issue,
* body may be a spaeicl header (see SOAP),
* we have this tight coupling with blocks, handlers, and mapping to SOAP
was difficult, it would be nice to have it changed to make mapping to
SOAP easier
There is one receiver per block, the body only intended for the final one
MJ: in the abstract model we then don't need to make that distinction.
HFN: fine. my main concern is handlers which can't be mapped to SOAP
MJ: SOAP don't have a notion of module right?
HFN: it has a notion of modules but not the handler one.
JJM: moving 5.2 to 5.1
MJ: that's fine
JJM: and remove references to http
HFN,MJ: it is just a name, not linked to http.
JJM: we can perhaps use xmlp:
JJM: text about SOAP won't stay here, we can put the references in italics
SW: remove head/body distinction, open discussion around targetting,
couple of editorial actions
HFN: I will do some changes wrt SOAP.
Discussion of document layout, removal of section 6, remove the word strawman...