Re: Reqs/AM - Comments/Questions

Doug,

Thanks for your careful review of the requirements & AM documents. Further
comments below.

Henrik, there may several new issues below. Look for the ISSUE tag.

Jean-Jacques.


Doug Davis wrote:

> Requirements:
> - R703b Requirements for Encapsulation of Status
>   What other types of status (besides success/failure) is this
>   requirement talking about?

I believe this requirement is about status information, for example the
progress made up-to-date by a long running request; but I do not think this
has been widely debated.

> - R802
>   Need to define "processing" - does having to XML parse the message
>   mean "process"?  There's been some discussion on the soapbuilders
>   mailing list about what SOAP processing nodes can and can not do
>   to certain parts of a SOAP envelope.  Defining "process" in XMLP
>   might help clear some of those up.

I think "processing" goes further than just parsing, and really means acting
upon parts of the message (processing zero or more blocks, adding one ore
more blocks), and possibly generating a response.

> - R400
>   So why not split it into 2 different specs?  One for generic XML
>   messaging and one for data encoding.  Some groups may not want to
>   implement the entire XMLP/SOAP spec.

I think it has been suggested by at least some people that the encoding of
choice for XMLP ought to be that of XML Schema. Other people have pointed
out that XML Schema currently did not support arrays and structs.

> - R604
>   HTTP->SMTP->HTTP
>   Need to make sure that there is a mechanism to reacquire the XMLP
>   equivalent of the SOAPAction HTTP header (if there is one) during
>   the SMTP->HTTP conversion.

Yes, there should be an equivalent of SOAPAction for all bindings, if we
want to support the SMTP->HTTP scenario. <ISSUE1/>

>  Related to this is the question of
>   what exactly the SOAPAction header is supposed to be used for?
>   Targeting or routing to the target service?  Simply a filtering
>   mechanism for firewalls?

The SOAP/1.1 spec suggests it is used by firewalls to filter unwanted
messages. My understanding is that the SOAPAction header tries to capture
the semantics of the message, although that may be hard when several
unrelated blocks are included in the message. SOAPAction may bear some
ressemblance to the SOAP Actor attribute, but I do not think it was
originally conceived for making targeting/routing decisions.

>  Does it really serve any purpose at all
>   since its only for HTTP transports?  Soapbuilders is talking about
>   this one right now and there's a split between how people are using
>   it - XMLP should try to clear this up.
>
> - 6.1 Glossary
>   - Missing XMLP Processor

Which version of the glossary are you looking at? The XMLP/SOAP spec[1]
contains a definition  for an "XMLP/SOAP processor".

>   - XMLP block & XML handler
>     This needs to be an M-N relationship.

For targeted blocks, the relationship is currently M-1 (processed blocks are
removed from the message). For untargeted blocks, the relationship is M-N
(untargeted blocks are never removed from the message, although they may be
processed as a result of processing targeted blocks).

>     Why do the requirements require or talk about XMLP handlers?
>     This seems like an implementation detail.  XMLP processor might
>     or might not have the notion of handlers I think the spec (and
>     the requirements list) should avoid defining impl. details.

The WG has decided recently that, for that very reason, there would be a 1-1
relationship between a module and a handler. (At least conceptually;
implementations may decided otherwise.)

> Abstract Model:
> - Overall
>   I'm a bit confused about the purpose of this document.  I read
>   the abstract and it seems like it implies that this _isn't_ an
>   API definition doc, but then what is it?  This doc seems like a
>   really good starting point for either the spec or an API doc
>   (or both), but if we're going to say that its not then who's
>   going to use this doc in the future?

It was originally modelled after the IEEE 802.11 abstract model, and tried
to describe the *conceptual* services that would be provided to an
application by the XMLP layer. A description of the interesting operations
was provided to avoid handwaving, and provide a more formal approach. It was
never intended to be an API.

>   Assuming I'm just missing the point  8-)  and there is a need for
>   this doc, and its not defining an API then I'm really confused by
>   things like the XMLP_UnitData Operation section.  When it talks
>   about things like the XMLP_UnitData.receive being invoked by the
>   receiving XMLP processor this seems to imply an implementation
>   detail (or API) rather than an abstract view of things.
>
> - 2. XML Protocol Abstract Model Overview
>   - XMLP Handlers should be an implementation detail.  XML blocks
>     should be targeted by using the XMLP equivalent of the SOAP
>     ActorURI and it should be up to each XML Processor to decide how
>     that Actor is interpreted.  It could be the entire processor or
>     a particular module (ie. handler) in that processor or even a
>     group of handlers.

Some people believe an XMLP processor should be a standard component
(similar to an XML parser) that dispatches blocks to modules/handlers
according to well-known (normative?) conventions. In that model, processors
do not do any processing on their own. Other people view this as an
implementation issue, and consider that at least some processors will
process blocks directly, for example on resource constraint devices.

>     We need to be very careful about this one - defining handlers
>     could lead to some problems, lets say we have an XMLP message
>     like:
>     <env>
>       <header mustUnderstand=1>...DigSig stuff...</header>
>       <body>...</body>
>     </env>
>     and neither the header nor the body are targeted (ie. no actors).
>     This means that they're implicitly targeted for the final
>     destination of the message

My understanding is that non-targeted header blocks are never processed,
unless referenced by at least one targeted block.

> - is this the final XMLP processor or
>     the final XMLP handler?  From the Abstract Model doc it seems like
>     its the final XMLP handler.

I think this issue is still being debated. (The AM may also need to be
reconciled with spec.)

>  But people may choose to implement
>     pluggable handler to process (and remove) certain headers.  So
>     a DigSig handler sees a MustUnderstand header and processed it, but
>     since it wasn't targeted for him (that handler) the DigSig
>     handler should not remove the header.  So when the final handler
>     gets the message it will fault because 1) it will see an MU header
>     that it doesn't understand and 2) because the message will have
>     already been DigSig processed.  The only other choice would be
>     to put all of that logic in the final XML handler which makes it
>     much less pluggable/clean.

I do not think this will occur in practice, unless the block is targeted at
the final destination, in which case the final destination will have to know
how to process the block anyway.

>     I would really prefer if we leave the notion of handlers up to the
>     specific implementation and make the XMLP version of Actors be
>     just a URI that is up to the XMLP processors to interpret as they
>     see fit.
>
> - 3.1.1 Correlation of Sending and Receiving XML Protocol Applications
>   - Why is Correlation special?  Why is this one field pulled out
>     into the APIs?  Can't the same argument be made for any field (ie.
>     user-id)?  Would it be cleaner to define "well-known" headers or
>     Actor URIs for this purpose - that way everything about the message
>     is kept inside of the SOAP Envelope.

Correlation was brought out so we could deal with 2-way messages. We need
2-way messaging (at least) for RPC.

> - 3.2 Operation Parameters
>   - ImmediateDestination - is this like the SOAP Actor URI?

Maybe. (It may be one of these areas where there is still some discrepancy
between the spec and the AM.) <ISSUE2/>

> - 4.1 XML Protocol Message Routing and Targeting
>   - One XMLP block could be "processed" by more than one handler.

Yes; see above.

> This
>     M-N relationship needs to be allowed/discussed.  This is true in
>     SOAP as well, except when blocks are targeted.
> - 4.2 XML Protocol Modules and Message Processing
>   - Bullet 5 - "When a block is selected for processing...it is
>     removed" - this is a much stronger statement than in SOAP. This is
> only true for targeted blocks not all blocks, do we really want to
> say this?

You are right, this is a bug, it should say: "When a targeted block [...]".
<ISSUE3/>

> But then I guess it depends on how we define
>     "processing".  A logging header may be processed by many different
>     XMLP processors but may never get removed until the final
>     destination - is this an error?
>     Need to define "referenced" vs "processed".  Does that imply read-
>     only?

I do not think untargeted, referenced blocks are meant to be read-only, but
this probably needs to be stated. <ISSUE4/>

>  What about Digital Signature/Encryption processors - they
>     need to be able to rewrite blocks that are not targeted them.
>   - Bullet 6 - the order of the XML Blocks defines the order of
>     processing?  Very strong statement - do we really want to say this?

I think this is still being debated. This may be out of scope. <ISSUE5/>

>   - Bullet 7 - Does the fault happen immediately or can we wait until
>     the end of the current XMLP handler/processor?

My understanding is that a fault is a failure that cannot be recovered from,
so processing of the message at that node will fail immediately.

>  Do we allow multiple
>     faults to be returned?

One (fatal) fault, but several errors, I believe.

> - 5.1.1 Introduction
>   - Figure 5.1 should show XMLP Handlers may generate output -  ie. may
>     talk directly to the bindings.

I think handlers are not supposed to talk directly to bindings, at least
conceptually. They should fill in a binding template, and pass it down to
the XML layer for doing the actual binding.

> For example, in a multi-cast XMLP
>     processor a message may be sent out over several different binding,
>     each one done by a different XMLP handler - the XML processor
>     doesn't really get involved since it probably only knows about the
>     single incoming and single out-going message - but that's probably
>     an implementation choice.

I believe this scenario is supported by the current model (XMLP layer,
binding template).

> - 5.3 Attachment of Arbitrary Content
>   - "The core XML protocol messaging services intrinsically handle
>     arbitrary attachments through the use of the Attachments parameter".
>     Unless I missed it we don't ever really talk about this parameter
>     any place else - its in Operation Parameters chart but not in the
>     APIs themselves.

This looks like a bug. <ISSUE6/>

> thanks,
> -Dug

[1] http://www.w3.org/2000/xp/Group/1/04/17/xmlp-soap-01.html

Received on Monday, 23 April 2001 06:28:05 UTC