Re: New AFTF draft.

Herve,

Please see below.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

"Herve Ruellan" <ruellan@crf.canon.fr> wrote on 09/10/2002 12:03:57 PM:
<snip/>
> > Yes, I think I agree with the note, but I fear that because it is
> > just a note, it diminishes its importance. Maybe if instead of a note,
> > it were a part of the normative prose that would make me feel better.
> 
> I think we can make this note not a note (does it make sense?), that is, 

> just remove the "Note:" at the beginning of the paragraph.

Works for me, thanks.

<snip/>
> 
> I think that these points are captured, without as much precision, in 
> the sentence (from 6. Implementation):
> "A means by which the primary and secondary parts are made available to 
> the receiving party."
> 
> We could expand this sentence to be more specific. However this should 
> be carefuly crafted not to rule out the possibility of just sending the 
> SOAP message containing external references to the other parts which are 

> retrieved using a classic HTTP GET.

Actually, the way I's like to see it, the ONLY way that the application 
accesses the
representations of the resource at a URI would be through (e.g.) HTTP GET 
and the binding
provides the equivalent of an entity resolver to the application 
that returns the bits from an "attachment" part or off the network as 
befits the
situation. That way, the feature is transparent to the application, which
IMO is as it should be. The carrying of attachments is mostly an 
optimization
of sorts, but there are properties of the Web that are inherent in the way
that resources are accessed which would be lost if they weren't applied
consistently.

> 
> > What is currently specified suggests (to me) that the *means by which
> > the secondary part is dereferenced* is left entirely up to the
> > application-level code, which doesn't seem right to me. To my mind,
> > this is the responsibility of the implementation of the SOAP binding
> > to provide this service. Otherwise, you end up with application code 
> > tightly coupled with the specific protocol (DIME, MIME, etc.) used
> > to transmit the compound SOAP message (yuch!)
> 
>  From my point of view, the spec is clear about this. However I'm ready 
> to add some text for making it clearer, but I'm not sure what to add and 

> where.
> 
> Regards,
> 
> Hervé
>