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. >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
