Re: draft-ietf-mmusic-sip-multipart-00.txt

[Jonathan Rosenberg <[e-mail]>]

Henning Schulzrinne wrote:
> 
> "Adam B. Roach" wrote:
> >
> > The current draft for multipart bodies for SIP messages
> > (<draft-ietf-mmusic-sip-multipart-00.txt>) appears to limit
> > bodies to, at the maximum:
> >
> > 1) One section with session information (e.g. SDP)
> > 2) One section for telephony signalling transparancy (e.g. ISUP)
> > 3) One section for billing information (e.g. OTP)
> 
> Agreed. Why limit the multipart at all? Each section is identified by
> its MIME type, so they are self-identifying. If that is necessary, a
> parameter indicating functionality could be added, but I don't see this,
> as the MIME types have non-overlapping functionality. It is not likely
> that OTP will suddenly be mistaken for session information.

In fact, I would argue that no extension is needed at all for multipart
in SIP. SIP allows MIME bodies, and since multipart is a valid MIME
type, SIP supports it right now. In fact, multipart/parallel is probably
the right sub-type for what is being done here. As Henning points out,
the MIME type itself would tell a UA what to do with each part. Type
application/sdp is for session description, application/isup for isup
parameters, and application/otp for billing. Eventually, other things,
like application/cpl, may be needed too. Rather than constraining
ourselves by enumerating the specific functions the various MIME parts
provide, leave it to the type itself to indicate.

What you will need is an extension defining the semantics for processing
each type. For example, draft-ietf-iptel-sip-reg-payload defines the
semantics for application/cpl and application/sip-cgi.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: [phone]                         Rm. 4C-526
EMAIL: [e-mail]
URL: http://www.cs.columbia.edu/~jdrosen