Re: draft-ietf-sip-info-events-00: multiple packages per INFO

Hi,

>Just because SIP requires (or now nearly requires) multipart body
>handling doesn't mean that we have to define the meaning of multiple
>bodies of the same type for every usage.

Of course not. But, unless there are good reasons I don't think we should forbid it - in case there will be future use-cases where it could be useful.

>And surely there are wider things bound up here. For example is it not
>still up to the application using INFO to ensure in order delivery if
>that is what it requires. One way of doing this is to constrain the
>transport mechanism to not send another INFO until the previous has been
>acknowledged. If so, then different applications may have different
>requirements in this respect that interact.

Correct. So, this would only be used if it fulfills all those requirements.

>Why does putting two different packages in the same INFO work better
>than two different INFO messages each with their own package usage? Is
>there a desirable relationship that can be implemented between the two
>that we would otherwise lose?

Well, that brings up a good question: assuming it is allowed to send multiple info packages in a single INFO, does that automatically mean that there must be a desirable relationship? I don't think so.
 
If there is a relationship that should be described in the application logic itself.
 
Regards,
 
Christer
 
 
 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Christer Holmberg
> Sent: Wednesday, October 22, 2008 8:54 AM
> To: Paul Kyzivat; SIP IETF; Eric Burger
> Subject: 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: [email protected] [mailto:[email protected]] 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 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
> [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
>

_______________________________________________
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