[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] draft-ietf-sip-info-events-00: multiple packages per INFO
Hi,
Doesn't the body handling draft say that one MUST be able to parse
multipart message bodies?
So, I don't think we should forbid the usage of multiple packages. There
MAY be use-cases where it is useful, so...
I also think that the negotiation of multipart support is more generic,
so such mechanism should not be bound to INFO packages.
Regards,
Christer
-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
Paul Kyzivat
Sent: 21. lokakuuta 2008 17:45
To: SIP IETF; Eric Burger
Subject: [Sip] draft-ietf-sip-info-events-00: multiple packages per INFO
Re the question about multiple packages per INFO:
There MUST be exactly one Info Package type listed per Info-Package
header. Multiple Info-Packages per INFO message are disallowed.
[EDITOR NOTE: Really? Why not multiple Info-Packages, in a
multipart/mime? Well, I thought of one: From sip-bounces at ietf.org Wed Oct 22 00:53:04 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 745FD3A6A19;
Wed, 22 Oct 2008 00:53:04 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id F1EED3A6A4D
for <sip at core3.amsl.com>; Wed, 22 Oct 2008 00:53:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.206
X-Spam-Level:
X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.043,
BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id MxNOEbEmkZ1e for <sip at core3.amsl.com>;
Wed, 22 Oct 2008 00:53:02 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62])
by core3.amsl.com (Postfix) with ESMTP id DA64D3A6A19
for <sip at ietf.org>; Wed, 22 Oct 2008 00:53:01 -0700 (PDT)
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
B3BB3215D6; Wed, 22 Oct 2008 09:54:10 +0200 (CEST)
X-AuditID: c1b4fb3e-aef86bb00000537b-f9-48fedc22ef61
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
A18C220109; Wed, 22 Oct 2008 09:54:10 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
Wed, 22 Oct 2008 09:54:09 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 22 Oct 2008 09:54:09 +0200
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0889E49A at esealmw113.eemea.ericsson.se>
In-Reply-To: <48FDEAD8.8010803 at cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] draft-ietf-sip-info-events-00: multiple packages per INFO
Thread-Index: Ackzi6XrNIT2zGxYSj2+GSTrqqgYJAAj0PhQ
References: <48FDEAD8.8010803 at cisco.com>
From: "Christer Holmberg" <christer.holmberg at ericsson.com>
To: "Paul Kyzivat" <pkyzivat at cisco.com>, "SIP IETF" <sip at ietf.org>,
"Eric Burger" <eburger at bea.com>
X-OriginalArrivalTime: 22 Oct 2008 07:54:09.0941 (UTC)
FILETIME=[5DCF7C50:01C9341B]
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [Sip] draft-ietf-sip-info-events-00: multiple packages per INFO
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
Hi,
Doesn't the body handling draft say that one MUST be able to parse
multipart message bodies?
So, I don't think we should forbid the usage of multiple packages. There
MAY be use-cases where it is useful, so...
I also think that the negotiation of multipart support is more generic,
so such mechanism should not be bound to INFO packages.
Regards,
Christer
-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
Paul Kyzivat
Sent: 21. lokakuuta 2008 17:45
To: SIP IETF; Eric Burger
Subject: [Sip] draft-ietf-sip-info-events-00: multiple packages per INFO
Re the question about multiple packages per INFO:
There MUST be exactly one Info Package type listed per Info-Package
header. Multiple Info-Packages per INFO message are disallowed.
[EDITOR NOTE: Really? Why not multiple Info-Packages, in a
multipart/mime? Well, I thought of one: it is hait is hard to disambiguate.
For example, take an INFO message with an Info-Package: key_image,
caller_picture. I then have a multipart/mime with, you guessed it,
an image/jpeg and an image/jpeg. I would offer we do allow this and
require the MIME parse order of the body match the order of the
Info-
Package enumerations; if you have too many packages or body parts or
they do not align, you barf. However, I timed out on this and thus
we will have to wait for the next version for me to flesh this out.
If we do do this, then we'll reference RFC 3261 as updated by
draft-ietf-sip-body-handling to require multipart MIME handling.]
How about defining an initial package type of "multipart". It allows
only content-type multipart/mixed. Then each contained type must have
its own Info-Package header. If you want to allow multiple packages per
INFO then you need to negotiate support for "multipart". Or maybe we
require support of multipart if you support any other package type.
Thanks,
Paul
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
sip-implementors at cs.columbia.edu for questions on current sip Use
sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
rd to disambiguate.
For example, take an INFO message with an Info-Package: key_image,
caller_picture. I then have a multipart/mime with, you guessed it,
an image/jpeg and an image/jpeg. I would offer we do allow this and
require the MIME parse order of the body match the order of the
Info-
Package enumerations; if you have too many packages or body parts or
they do not align, you barf. However, I timed out on this and thus
we will have to wait for the next version for me to flesh this out.
If we do do this, then we'll reference RFC 3261 as updated by
draft-ietf-sip-body-handling to require multipart MIME handling.]
How about defining an initial package type of "multipart". It allows
only content-type multipart/mixed. Then each contained type must have
its own Info-Package header. If you want to allow multiple packages per
INFO then you need to negotiate support for "multipart". Or maybe we
require support of multipart if you support any other package type.
Thanks,
Paul
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
sip-implementors at cs.columbia.edu for questions on current sip Use
sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip