Christer Holmberg wrote:
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".
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.
I think so, yes. At least I can't remember having seen different values
being used in INVITEs and INFOs.
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...
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.
I don't think the info package specifcation should "update" the RFC it
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.
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
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip