I don't think we are talking about allowing an info package in a
non-INFO message.
Rather the question was about ISUP, and what might it look like if it
were adapted to use the proposed new info packages. The goal is to send
ISUP data in INVITE as well as in INFO. With the new stuff, it would
presumably use an info package to send ISUP data in INFO. For sending
ISUP data in other messages, it wouldn't be using info packages.
Presumably it would do as it currently does, since there is nothing
wrong or objectionable about that.
Thanks,
Paul
Christer Holmberg wrote:
Hi,
IF we want to allow info packages in non-INFO request, I think we should also allow the Info-Package header in non-INFO request, in order to provide equally amount of information.
In any case, I guess we would NOT allow it in the initial INVITE, since we don't know what the other end supports (the negotiate-before-you-send part is one of the key stones in the draft).
But, at least ISUP can also be sent in a BYE, so I guess the question is whether there are other use-cases for sending an info package associated with a call is release (a picture with a cool Good Bye/I love you/I hate you message, for example?)
Regards,
Christer
________________________________
From: sipping-bounces@xxxxxxxx on behalf of Paul Kyzivat
Sent: Fri 24/10/2008 18:50
To: DRAGE, Keith (Keith)
Cc: sipping@xxxxxxxx
Subject: Re: INFO usage: relationship of package bodies to those of other requests
DRAGE, Keith (Keith) wrote:
I was using that as an example, and I think you have missed my question.
Let me rephrase in more general terms.
If a define MIME type that is appropriate for use in an info package,
and negotiate the use of that package in a particular dialog:
- can I use bodies of that MIME type in other messages in the same
dialog?
- is that usage entirely and absolutely independent of the info
package use?
Well, I suppose the specification of the particular mime type *could*
call out that it was only intended for use in INFO packages. But that
seems unlikely, and a bad idea. (That would mean that I couldn't attach
such a body to an email message to give it to you as an example.)
The mime type should only be specifying the format of the information,
not what it may be embedded within.
In the past, we overloaded the mime type in INFO so that it specified
both what the information syntax is as well as implying how it should be
used. It wasn't so bad with ISUP, because there was also a
Content-Disposition defined for it.
So, I think you can use any mime type in any message (at least all the
ones that permit bodies.) The recipient then has to determine if it can
process the body/body-parts that it has received. In that it is guided
by the Content-Disposition, which determines which are optional and can
be ignored if not understood, and those which are required and must be
processed. If you get a part that is required, but the disposition type
and content type are such that you can't/don't know how to process it,
then you must generate an error.
All of that is independent of info packages.
In INFO, with info packages, we provide *more* information for deciding
how something is intended to be processed.
This is why, in a prior message, I pointed out that there is a lot of
similarity and overlap between content dispositions and package types.
This also presents some interesting new issues with ISUP if we want to
bring it into this new info framework:
It currently (grandfathered use of INFO) uses Content-Disposition:signal
for the its bodies that have Content-Type:application/ISUP. And it has
defined that "signal" is the *default* C-D for that C-T. The question
is, with the new info package framework, a body part with C-D:signal a
potential carrier of an info package? I think not. I think we will end
up defining *one* C-D for all info packages, and presumably it won't be
"signal". (Maybe it will be *the* meaning of "render" within INFO, or
maybe it will be a new one.)
Thanks,
Paul
Regards
Keith
-----Original Message-----
From: sipping-bounces@xxxxxxxx
[mailto:sipping-bounces@xxxxxxxx] On Behalf Of Paul Kyzivat
Sent: Friday, October 24, 2008 2:56 PM
To: DRAGE, Keith (Keith)
Cc: sipping@xxxxxxxx
Subject: Re: INFO usage: relationship of package
bodies to those of other requests
DRAGE, Keith (Keith) wrote:
I believe that ISUP interworking as defined in ITU-T
Q.1912.5 can put
an ISUP body in INVITE requests as well as INFO requests. If we now
came to define a package for that usage, what is the relationship
between the package negotiation and any bodies transmitted
in requests
other than INFO?
Is it none, i.e. they just happen to share the same MIME type, and
this is allowed?
The current usage is grandfathered.
If there is new work to update the specs for ISUP
interworking to use this new info package mechanism, then it
will have to conform to the info package spec for the parts
of the usage that utilize INFO. The same revision will have
to deal with any revisions that it deems necessary to the
conveyance of ISUP info in INVITE requests and responses. I
don't think we can concern ourselves with that here.
But at least the ISUP work was careful to define a Content-Disposition
("signal") for use with their ISUP bodies, so further work
may not be needed.
Thanks,
Paul
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current
sip Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
