RE: Issue 453 (use of multipart/multiplexed)

Mark,

Note that during the review of the Use Cases & Requirements Analysis 
document [1] in the Feb04 teleconf [2], it was agreed that R26 derived 
from an out-of-scope use case (UC12) and is thus now deprecated.

r, Mike

[1] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2004Feb/0047.html
[2] http://www.w3.org/2000/xp/Group/4/02/04-minutes.html


-----Original Message-----
From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
Behalf Of ext Marc Hadley
Sent: Thursday, February 19, 2004 2:15 PM
To: xml-dist-app@w3.org
Subject: Issue 453 (use of multipart/multiplexed)


I took an action to do some research into issue 453[1] which concerns  
use of the multipart/multiplexed' mechanism described in RFC 3391[2] in  
XOP. Issue 453 was raised as a result of comments from the SVG WG[3]  
who desire a means to interleave the base XML document data with its  
referenced content.

Our requirements currently contains the following:

R26: The serialization should support streaming of serialization parts,  
i.e. chunked encoding.

R26 could be taken to require some form of interleaving between parts  
but it doesn't say that explicitly.

RFC 3391 is categorized as "Informational" and contains the following  
caution:

"Status of this Memo

    This memo provides information for the Internet community.  It does
    not specify an Internet standard of any kind.  Distribution of this
    memo is unlimited.

IESG Note

    The IESG believes use of this media type is only appropriate in
    situations where the producer is fully aware of the capabilities and
    limitations of the consumer.  In particular, this mechanism is very
    dependent on the producer knowing when the consumer will need a
    particular component of a multipart object.  But consumers
    potentially work in many different ways and different consumers may
    need different things at different times.  This mechanism provides no
    means for a producer to determine the needs of a particular consumer
    and how they are to be accommodated.

    Alternative mechanisms, such as a protocol based on BEEP which is
    capable of bidirectional communication between the producer and
    consumer, should be considered when the capabilities of the consumer
    are not known by the producer."

The XMLP WG needs to weigh this caution against the expressed need of  
the SVG WG when deciding how to proceed.

Some possible resolutions:

(i) Say nothing about RFC 3391
(ii) Include some information about RFC 3391 in XOP but speifically  
exclude its use in MTOM.
(iii) Include some information about RFC 3391 in XOP and allow its use  
in MTOM

Regards,
Marc.

[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x453
[2] http://www.ietf.org/rfc/rfc3391.txt
[3]  
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Dec/ 
0003.html

Received on Thursday, 19 February 2004 15:03:36 UTC