Subject: [Sip] INFO event package: C-D value always "render"?

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 7 Dec 2008 18:50:18 +0100

Hi,

Somewhere in the small thread about multiple packages in an INFO there
have been statements that a body part associated with an INFO package
must have a Content-Disposition "render" value.

However, when reading RFC 3204 (MIME for ISUP/QSIG) it says that the C-D
value is "signal".

So, if we want to define an info package for ISUP transport I guess we
would have to allow "signal", because I don't think we want to update
3204...

Regards,

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 7 Dec 2008 14:46:25 -0500

Yeah I said in one of those emails that the default is "render", but the package could define it's own C-D's it supports, specifically due to the "signal" case.  Or we could just grandfather that one and say no more unique C-D's for packages.

-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Sunday, December 07, 2008 12:50 PM
To: SIP List
Subject: [Sip] INFO event package: C-D value always "render"?

Hi,

Somewhere in the small thread about multiple packages in an INFO there have been statements that a body part associated with an INFO package must have a Content-Disposition "render" value.

However, when reading RFC 3204 (MIME for ISUP/QSIG) it says that the C-D value is "signal".

So, if we want to define an info package for ISUP transport I guess we would have to allow "signal", because I don't think we want to update 3204...

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Dec 2008 09:28:00 -0500

> However, when reading RFC 3204 (MIME for ISUP/QSIG) it says that the C-D 

Good point. I knew it defined that disposition, but didn't remember it 
used it in INFO. But since it makes it the default disposition for the 
type, I guess it probably would be used for INFO.

> would have to allow "signal", because I don't think we want to update 

That's not strictly true. When the new package was defined it could 
specify that "render" be used for INFO even if "signal" is used when 
sending the same body in an INVITE.

But frankly there is no benefit to defining a package for this use, over 
just continuing with the legacy usage. That's because the usage also 
includes sending the same bodies in INVITE, etc. So the negotiation 
mechanism comes to late to add any value.

But I will respond to the general point in response to another of your 
messages.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 8 Dec 2008 19:05:59 +0100

Hi, 

I think so, yes. At least I can't remember having seen different values
being used in INVITEs and INFOs.

I don't think the info package specifcation should "update" the RFC it
refers to for the body part.

>But frankly there is no benefit to defining a package for this use,
over just continuing with the legacy usage. That's because the usage
also includes sending the same bodies in INVITE, etc. So the 
>negotiation mechanism comes to late to add any value.

I agree.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Dec 2008 09:56:04 -0500

> refers to for the body part.

Well, maybe not if the document stood alone. But doesn't that doc define 
the *use* in sip as well as the mime-type and C-D? I would think that 
document would have to be revised anyway to introduce the use of info 
packages for that purpose. So changing the C-D to be used when sending 
an info-package would not be an unreasonable thing to do.

Nevertheless, I think I am ok with info packages defining the C-Ds their 
parts use.