[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sipping] 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 at ietf.org [mailto:sipping-bounces at ietf.org] On Behalf Of Paul Kyzivat 
Sent: Friday, October 24, 2008 2:56 PM
To: DRAGE, Keith (Keith)
Cc: sipping at ietf.org
Subject: Re: [Sipping] 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 ng-request at ietf.org?subject=subscribe>

Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: sipping-bounces at ietf.org
Errors-To: sipping-bounces at ietf.org



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 at ietf.org [mailto:sipping-bounces at ietf.org] On Behalf Of Paul Kyzivat 
Sent: Friday, October 24, 2008 2:56 PM
To: DRAGE, Keith (Keith)
Cc: sipping at ietf.org
Subject: Re: [Sipping] 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 leastat 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 at cs.columbia.edu for questions on current sip Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP


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 at cs.columbia.edu for questions on current sip Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP