Reqs/AM - Comments/Questions

I recently joined the W3C XMLP WG so forgive me for the lateness
of my note but I have a few questions (and comments) about the
Requirements and Abstract Model documents.

Requirements:
- R703b Requirements for Encapsulation of Status
  What other types of status (besides success/failure) is this
  requirement talking about?
- 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.
- 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.
- 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.  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?  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
  - XMLP block & XML handler
    This needs to be an M-N relationship.
    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.

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?

  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.

    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 - is this the final XMLP processor or
    the final XMLP handler?  From the Abstract Model doc it seems like
    its the final XMLP handler.  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 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.
- 3.2 Operation Parameters
  - ImmediateDestination - is this like the SOAP Actor URI?
- 4.1 XML Protocol Message Routing and Targeting
  - One XMLP block could be "processed" by more than one handler.  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?  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?  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?
  - Bullet 7 - Does the fault happen immediately or can we wait until
    the end of the current XMLP handler/processor?  Do we allow multiple
    faults to be returned?
- 5.1.1 Introduction
  - Figure 5.1 should show XMLP Handlers may generate output -  ie. may
    talk directly to the bindings.  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.
- 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.

thanks,
-Dug

Received on Thursday, 19 April 2001 07:15:54 UTC