Re: [Sip] INFO issues: (1) Package Support Detection and (2) InfoPackages for Legacy Use

["Andrew Allen" <aallen at rim.com>]

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: sip-bounces at ietf.org <sip-bounces at ietf.org>
To: SIP IETF <SIP at ietf.org>
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip