Re: [Sipping] I-D Action: draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt

Paul Kyzivat <pkyzivat@alum.mit.edu> Sat, 03 December 2011 18:11 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: sipping@ietfa.amsl.com
Delivered-To: sipping@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9086021F9296 for <sipping@ietfa.amsl.com>; Sat, 3 Dec 2011 10:11:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.541
X-Spam-Level:
X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzetZlMzQMqZ for <sipping@ietfa.amsl.com>; Sat, 3 Dec 2011 10:11:25 -0800 (PST)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id C9FC221F9295 for <sipping@ietf.org>; Sat, 3 Dec 2011 10:11:24 -0800 (PST)
Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id 4hyq1i0011wpRvQ5DiBQfU; Sat, 03 Dec 2011 18:11:24 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta18.westchester.pa.mail.comcast.net with comcast id 4iBN1i00K07duvL3eiBNXQ; Sat, 03 Dec 2011 18:11:24 +0000
Message-ID: <4EDA6648.2040109@alum.mit.edu>
Date: Sun, 04 Dec 2011 02:11:20 +0800
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: John-Luc Bakker <jbakker@rim.com>
References: <20111202210806.7950.76133.idtracker@ietfa.amsl.com>
In-Reply-To: <20111202210806.7950.76133.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: sipping <sipping@ietf.org>
Subject: Re: [Sipping] I-D Action: draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Dec 2011 18:11:25 -0000

I'm commenting on this on the (now obsolete) sipping list because this 
has sipping in its name. This may not be the best place. I suppose an 
alternative is rai.

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 body

Of 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@ietf.org 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@ietf.org
> 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
>