Subject: [Sipping] INFO usage: relationship of package bodies to those of other requests

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 24 Oct 2008 15:35:41 +0200

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?

Regards

Keith
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Oct 2008 09:55:40 -0400

> Is it none, i.e. they just happen to share the same MIME type, and this

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

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 24 Oct 2008 16:00:19 +0200

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?

Regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Friday, October 24, 2008 2:56 PM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [Sipping] INFO usage: relationship of package 
> bodies to those of other requests
> 
> 
> 
> > 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?
> 
> 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.
> 
> ("signal") for use with their ISUP bodies, so further work 
> may not be needed.
> 
> 	Thanks,
> 	Paul
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Oct 2008 12:50:10 -0400

> -	is that usage entirely and absolutely independent of the info

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

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 24 Oct 2008 22:44:14 +0200

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: [email-masked] on behalf of Paul Kyzivat
Sent: Fri 24/10/2008 18:50
To: DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: Re: [Sipping] INFO usage: relationship of package bodies to those of other requests

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Oct 2008 17:02:35 -0400

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