Re: INFO usage: relationship of package bodies to those of other requests

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

 




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

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux