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
