My 2 cents Issue #1 Yes
Issue #2: Yes let's register the legacy packages. It indicates a seriousness about this as an update to INFO for continued usage and compliance with the standards usage of that method which hopefully over time will cause existing applications to be updated to comply with the new negotiation mechanism (similar to the evolution from strict routing to loose routing). It will also provide an example of how its done (IANA registration template to copy etc). Some message examples using the mechanism with an existing package can also help here too. Andrew ----- Original Message ----- From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> To: SIP IETF <[email protected]> Sent: Fri Aug 01 16:00:53 2008 Subject: [Sip] INFO issues: (1) Package Support Detection and (2) InfoPackages for Legacy Use The current text states that if a UA does not support receipt of any Info Packages, it MUST drop the Info-Recv header. Likewise, if the UA does not support sending any Info Packages, as would be the case if a UAS does not support any of the Info Packages offered by the UAC, it MUST drop the Info-Send header. As an extreme example, if a UAS does not want to send any Info Packages to a UAC and simultaneously the UAS does not support any of the Info Packages offered by the UAC, the UAS will have neither an Info-Send nor an Info-Recv header. In this case, the UAC cannot disambiguate between a legacy UAS and an Info Package-aware UAS that simply does not want to receive INFO messages. Issue #1: Is this a problem? On the one hand, one could argue a UAS that does not support any INFO packages may still support proprietary INFO packages or the legacy, standards track INFO usages. On the other hand, one could argue a UAS that supports INFO packages yet does not want to process the requested Info Packages needs a way to communicate that to the UAC. In this case, the easiest solution (which also works for the legacy interoperability case) is for the UA to include an empty Info-Recv or Info-Send header. Thus the "yes / no" question here is, Should we change the text to mandate Info Package-aware UAs to use empty Info-Recv and Info-Send headers to indicate the desire to not receive or not send Info Packages, respectively? Issue #2: If we answer in the affirmative on Issue #1, then we need to port the existing, standards track usage of INFO, namely SIP-T (RFC 3372) for ISUP and QSIG (RFC 3398). This has the added benefit of providing instant examples of the Info Package framework. Moreover, it populates the IANA registry with meaningful entries. I would volunteer to do that work, unless someone else feels strongly they want to do it. Thus the "yes / no" question here is, Should we port RFC 3372/3398 to the new Info Package framework, finishing to coincide with the completion of the Info Package framework? I.e., as a coherent whole, yet as two or three separate documents. _______________________________________________ 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 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________ 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
