Re: [Sip] comments on draft-ietf-sip-info-events-01

Eric Burger Mon, 17 Nov 2008 09:05:38 -0800

SUBSCRIBE/NOTIFY didn't specify it because (1) the Event: header as specifies ensures only a single payload and (2) implementations may find themselves hopelessly broken when a legal, RFC 3261, multipart payload shows up.


INFO has to specify it so we do not barf.

The "what" the INFO document is doing that SUBSCRIBE/NOTIFY did not have to do is explain why we have INFO at all.


On Nov 17, 2008, at 10:50 AM, Hadriel Kaplan wrote:

I'm with Jonathan - the latest INFO draft is 41 pages long. RFC 3428 for MESSAGE method was 18 pages long. The entire Subscribe/ Notify RFC 3265 was only 38 pages long.

Something ain't right.

Of course a SIP message can have multiple bodies. That doesn't mean we have to define the whole thing or make it explicit in this doc. If Sub/not didn't specify it, why does INFO have to?


-hadriel

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
DRAGE, Keith (Keith)
Sent: Monday, November 17, 2008 10:47 AM
To: Jonathan Rosenberg
Cc: IETF SIP List
Subject: Re: [Sip] comments on draft-ietf-sip-info-events-01

Is this a concern just for legacy usage or is there a wider concern.

draft-ietf-sip-body handling updates RFC 3261:

------------------------------------------------------------------------

SIP Working Group G. Camarillo Internet-Draft Ericsson Updates: 3261, 3204, 3459 October 29, 2008

(if approved)
Intended status: Standards Track
Expires: May 2, 2009


    Message Body Handling in the Session Initiation Protocol (SIP)
                 draft-ietf-sip-body-handling-04.txt
------------------------------------------------------------------------

4.2.  Mandatory Support for 'multipart' Message Bodies

For all MIME-based extensions to work, the recipient needs to be able

  to decode the multipart bodies.  Therefore, SIP UAs MUST support
  parsing 'multipart' MIME bodies, including nested body parts.  In
  particular, UAs MUST support the 'multipart/mixed' and 'multipart/
  alternative' MIME types.
-------------------------------------------------------------------------

As this draft is hopefully going to get published before or at the same time as info-events, I would expect all new info package implementations

to support - afterall, it is mandatory.

regards

Keith

-----Original Message-----
From: Jonathan Rosenberg [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2008 3:35 PM
To: DRAGE, Keith (Keith)
Cc: IETF SIP List
Subject: Re: [Sip] comments on draft-ietf-sip-info-events-01



DRAGE, Keith (Keith) wrote:

To comment on the multipart body question below, my

understanding of

the requirement from the previous discussion is that it

does not come

from the need to send two info packages at the same time.

Rather it comes from the need to send an info package plus

some other

associated but yet to be described message body that happens to be
needed to be sent at the same time (e.g. info package containing a
Geolocation header pointing to a geolocation body in the

same message).

If we could eliminate this, we could get rid of it, but I

suspect we

cannot.

Given this, the support of multiple packages comes for free, so why
eliminate it.


Free? Certainly not.

If, as an implementor, all I care about is INFO, and I don't
have any other use case for multipart (which, as of now, are
mostly niche uses and are not common), I'll now NEED to
implement multipart for INFO.

So, I don't have a problem saying that INFO can contain
multiple bodies as any message can, but I do have a problem
with the idea that the INFO framework ITSELF allows multiple
packages per INFO.

-Jonathan R.


--
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[EMAIL PROTECTED]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Re: [Sip] comments on draft-ietf-sip-info-events-01

Reply via email to