|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
ISTM that there are three degrees of freedom here for identifying how to process these bodies:
- content-disposition - content-type - the actual content of the bodyOf these, the content-disposition is the most heavy weight in terms of mechanism, while the actual content of the body is the least heavy-weight.
So, I wonder why you have chosen to use one content-type, that seems to already contain distinct representations for the differing behaviors of interest, and yet use distinct content-dispositions. I think you could use a single content-disposition and get the same effect.
I guess multiple content-dispositions might make sense if they are processed by different entities, so that only the intended entities need decode the body. It would also make sense if the same identical body representation was processed differently based on the content-disposition. But I don't think either of those is the case here.
So I would find it helpful if this draft explained why it chooses to use multiple content-dispositions.
I also think it would be useful to say something about how you expect the handling parameter to be used with these dispositions. If handling=required (the default) is used, then any UA that gets this must fail the request unless it is able to handle the body. If handling=optional is specified, then that need not be so.
Thanks, Paul On 12/3/11 5:08 AM, internet-drafts@xxxxxxxx wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Specification of 3GPP IM CN Subsystem XML body handling Author(s) : John-Luc Bakker Filename : draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt Pages : 7 Date : 2011-12-02 This document registers new disposition-types for the Content- Disposition header field that apply to the application/3gpp-ims+xml body used by 3GPP. The applicability of these content-disposition values are limited to 3GPP IMS. The application/3gpp-ims+xml body has the following three distinct uses: (1) for redirecting the emergency session to use a different domain (e.g. using a Circuit Switched call), (2) for delivering user profile specific information from the SIP registrar to an Application Server, and (3) for causing a UAC to attempt to re-register with the IMS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@xxxxxxxx https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP