None
SW: Would like to get initial comments from people, and major issues.
HFN: Only had time to skim hrough the document.
SW: To take this document as input to the next f2f meeting, we need it
to be stable and represent consensus. If neither is achieved, then I
will need help from the group.
MG: The decision will be easy to make: either yes or no.
MG: Happy with the document. Lovely colours, BTW. XMLP_Data.confirm:
isn't the path missing?
SW: Yes, this is a bug.
MG: Reasonnably happy with diagram 2.1.
MH: The document looks good in B&W as well. Major issue: error
handling and propagation of failures. This is related to
intermediaries as well.
SW: It's a placeholder for now, not the group consensus; needs
elaboration.
MH: Regarding the note above figure 3.3: there's the example of an
intermediary normalizing Unicode.
JI: This is a heated issue.
SW: Let's come back to it later.
MH: That's all.
JI: Great job! More work needed on figure 3.3. Also should take a
representative number of scenarios, and map them to the AM.
SW: A lot of work!
JI: It probably only involved modifying figure 2.1, for example
replacing handlers a, b, ... by encryption intermediaries; etc. Should
consider only the most representative scenarios.
SW: Useful; but let's differ it to after the f2f meeting, where
scenarios will be discussed anyway.
SI: Great colours on my monitor! Thanks for the work! No major issues.
We should take this to the 2f2 meeting as is. Maybe some terms need a
better, less fuzzy definition, e.g. modules?
SW: We'll come back to it.
YL: Really good document! Should expand section 5.2. Also, current
discussions on the mailing list may impact parameters, body,
extensions, and interactions between them. We need also to discuss
about orthogonality of extensions and then decide what would be
in the core description of the payload versus the extensions. Ex:
is caching part of the core or not? -> possible interaction with
extensions.
SW: AMG allows the two options being currently discussed.
YL: Maybe more clearly separate the 2 options in the document?
JJM: Good document. Several points. Figure 2.1: shouldn't the arrows
be unidirectional, e.g. Block1 (Block1 is not being returned to
handler a, isn't it ?) ? Also, thinking about the relationship between
handlers and blocks, isn't the relationship many-to-one only, i.e. a
given block can only be targetted at single handler within a given
application?
HFN: Example of a MessageId block; several handlers within one
application will need to look at it.
JI: [[lost comment]]
HFN: It's up to the implementer to suport extensibility. How many rules
to support parallel exection? Use XML to provide ordering (via
nesting), or have a rule to specify "A or B before go to C" ? Would
favor the simplest model possible.
SW: Info is in the message itself.
YL: With extensions, can support "A or B then C".
JJM: Back to figure 2.1, shouldn't the arrow for Block3 be one way?
HFN: Agree.
JJM: Figure 3.6: doesn't the confirm imply there's a "hidden"
UnitData.response?
SW: Not necessarily. [[probably missed some of the discussion here]]
JJM: Should replace BxxP by BEEP.
SI: Yes, the name has been changed.
HFN: Lots of work. Regarding section 1: we now have two sets of
definitions. Strongly suggests we merge this section with the
glossary, otherwise we'll have two terminologies for the WG.
MG: We could go the other way.
HFN: We could also have a separate document.
SW: No dissention in principle; we need to resolve this issue.
HFN: It's not only a duplication of terms; but we have slightly
different versions of the same terms. This needs to be resolved before
publishing next Monday.
YL: Discuss during the f2f meeting.
HFN: Propose to add the missing terms from the glossary to the AMG
document; and copy/replace the duplicates.
SW: Already pointed out in the introduction.
MG: Not Accurate or correct enough.
HFN: Right way to move forward: remove duplication.
SW: Terms and diagrams in glossary sometimes conflict each other.
HFN: Can't we fix it?
SW: Yes, but there's a lot of rewriting work required. Leave minor
inconsistencies for now.
HFN: At least remove the obvious dups.
SW: Leave in, but strike them out for now.
HFN: Ok.
SI: Why is there a problem duplicating? Shouldn't we just add a
stronger introduction?
HFN: Problem with duplication.
SI: [[lost comment]]
SW: Glossary not yet finished, will be discussed at the next f2f
meeting. Just recognize there is an issue. The terms in the AMG
document are not a verbatim copy of the terms in the glossary; there
are semantical differences.
JI: Ultimately, we want one glossary.
SW: Agree, but [[lost comment]]
HI: In ideal situation, we would merge the two by Monday. Just strike
for now, and discuss during next f2f meeting.
SW: Let's continue by email. HFN to propose a stronger note + shadding
of the glossary.
HFN: Section 2: diagram very close now. Some comments as JJM: dotted
lines should be one way. Plus show path going from 1st to 3rd
application.
SW: An end-to-end line?
HFN: Yes, in the XMPL + UPL layer.
SW: Ok. Tried to cut the figure to the bare minimum.
HFN: Section 3, introductory paragraph: we're defining a protocol
only, not an API.
SW: A protocol presents services, an abstraction of these services.
HFN: Deciding how messages move back and forth is not a protocol
issue.
SW: Disagree.
HFN: [[lost comment]]
SW: Not discussing RPC here.
HFN: We don't want to say here whether it's 2 way request-response, or
best effort, eg. retry 5 times, etc. Request-response is an API. What
if [[lost comment]]
MG: Section 3 is an abstract definition; it's providing 2 different
ways to look at the protocol.
SW: One abstract view with 2 operations.
MG: Could have [[lost comment]]
SW: Yes, but not gone there.
SI: Model [[lost comment]]
HFN: Can't fully do this in terms of messages crossing the wire.
Should be able to map [[lost comment]]; but modelled according to what
we have on the wire. An API is not capable of modelling a state
machine.
MG: Request indicates things that should be in a message; not an API.
Isn't what you had in mind, Stuart?
SW: Precisely.
HFN: So what is the difference between ImmediatePath as header?
MG: Fine; just an implementation detail. Only says messages need this
information.
HFN: Yes, we need to describe what is in the message.
JI: Most valuable: abstract model. Might think of it as an
implementation, but should refrain from it. Wished had this from the
beginning for ebXML; would have been easier that way.
SI: No one is proposing the definition of an API.
HFN: Have protocol messages already. Instead, should talk of
header-body.
JI: Headers and bodies are more concrete implementation details.
HFN: We should decribe things in terms of a protocol, not an API.
SW: You're concerned about the way services are presented?
HFN: Yes.
JI: The AMG document expresses the way XP processor layer interacts
with the transport. Henrik it taking an application oriented view;
problem implementing later on.
NS: Compliments. Figure 2.1: does this represent concurrent
operations?
SW: Limited amount of info possible in 2D. Shows the flow of a single
operation.
NS: Ok. Also, the reader might get the impression there are always
intermediaries.
SW: No, that was not the intent.
NS: [[lost comment]]
SW: Good point.
NS Arbitrary layering?
SW: Examples?
NS: Routing, targetting.
NS: Section 3: need to show abstract message on message flow.
SW: Abstract message is the aggregation of To, Header, Body and
Attachements. Whether it's an HTTP header or not is not important
here; implementation detail.
HFN: Protocol binding?
JI: Have to drop off, sorry.
SW: 1/4 of an hour left. Can we take this document to the meeting?
Take people off the contributors' list if not ok?
HFN: Two disclaimers: 1°, the glossary. 2°, section 3, from HFN point
of view, is a questionable way of describing something which is
useful.
SW: Common way of doing things, eg. IEEE 802.
SW: People's opinion?
MG: Ok.
MH: Ok.
JI: [dropped off earlier; by email]
SL: Ok.
YL: Ok.
JJM: Ok
HFN: Ok if the 2 disclaimers above + status (ie. not endorsement by
subgroup) are added.
NS: Ok if audience is the WG. Should remove [[lost comment]]
LT: Ok to move forward.
SW: Ok, as you might guess.
SW: Send in typos before the week-end, if possible. Actions? Next
steps?
LT: Usage scenarios?
SW: After the f2f meeting.
SW: Any AOB?
[silence from the audience]
[end]