Keith,
The reason for awaiting a reply before sending another INFO is because
if you don't do that, and the messages get reordered, then the last one
to arrive will fail due to CSeq ordering. That's not a good thing,
though I guess it would be simple enough to retry it in that case.
I would assume that in most cases the actual order of processing would
not matter for different package types.
Thanks,
Paul
DRAGE, Keith (Keith) wrote:
Thanks for the direct answer to my question.
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.)
Surely here you are implying that the two packages have a dependency. That's
two steps of use cases, i.e. that there is a requirement for more than one use
case in the first place, and then the use case for the two packages being
interdependent in terms of data content.
If there is not such dependency, but the two packages both require in order
delivery for their own data, then surely each package not sending the next INFO
until it has received the response for the previous one within its package is a
sufficient mechanism at the level of INFO and the body packaging.
Regards
Keith
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 22, 2008 7:19 PM
To: DRAGE, Keith (Keith)
Cc: Christer Holmberg; SIP IETF; Eric Burger
Subject: Re: [Sip] draft-ietf-sip-info-events-00: multiple
packages per INFO
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
