Keith,
IMO sending two info packages in separate INFO messages should produce
the same behavior as sending them in one. Except perhaps for order of
processing. If we choose to define sending two in one INFO, then I think
we need to specify how the ordering is supposed to work. (E.g. that they
should be processed in the same order as they appear in the multipart,
and that in such case the behavior MUST be the same as if they were sent
in separate messages in that order.)
The one advantage that comes to mind is that if you can't do this, then
you really need to wait for the round trip of one info before sending
another, which could be inconvenient and delay inducing if you get the
data for more than one at the same time.
But we could certainly just decide not to define that now, and leave it
till later to decide if sending multiple packages is useful.
An problem with defining this is that it introduces another sort of
error to handle if one package can be dealt with but another cannot.
I guess I'd be inclined not to define it for now.
Thanks,
Paul
DRAGE, Keith (Keith) wrote:
Christer said in reply to me:
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.
That was not an answer to my question.
What I was trying to get to was whether providing two INFOs each containing one package provided the same solution as one INFO containing two packages (and assuming anyone has a use case for two packages on the same dialog - something I don't believe I have yet seen presented to the list - did I miss it somewhere).
If the answer is yes, then it becomes a matter of deciding whether we want one solution or two to be documented, and if one, then which one.
If the answer is no, then we need to understand the why and wherefore of those
differences before deciding what documentation to provide.
Regards
Keith
-----Original Message-----
From: Christer Holmberg [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 22, 2008 6:20 PM
To: DRAGE, Keith (Keith); Paul Kyzivat; SIP IETF; Eric Burger
Subject: RE: [Sip] 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
