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
