SIP
Click on the red underlined text to get to the source
... The IETF's Session Initiation Protocol (SIP) [3] was originally
developed for initiation of multimedia sessions ...
... multimedia, voice over IP, IP telephony, and SIP have become quite
popular, both inside IETF and with other standards groups ...
... IETF and with other standards groups, and the
applications of SIP have grown. One result of this popularity has
been a continual flood of suggestions for SIP ...
... SIP have grown. One result of this popularity has
been a continual flood of suggestions for SIP modifications and
extensions. The task for IETF management ...
... extensions. The task for IETF management of SIP has been to keep the
protocol development focused on SIP's core strengths and the
...
... management of SIP has been to keep the
protocol development focused on SIP's core strengths and the
applications it does best.
...
... SIP Working Group has been chartered to be the "owner" of
the SIP protocol [3], as long as the working group exists. All
...
... 3], as long as the working group exists. All
changes or extensions to SIP must first exist as SIP Working Group
...
... working group exists. All
changes or extensions to SIP must first exist as SIP Working Group
documents. The SIP ...
... SIP Working Group
documents. The SIP Working group is charged with being the guardian
of the SIP ...
... SIP Working group is charged with being the guardian
of the SIP protocol for the Internet, and therefore should only
extend or change the SIP ...
... SIP protocol for the Internet, and therefore should only
extend or change the SIP protocol when there are compelling reasons
to do so.
...
... option tags, new response codes, and new
standards track SIP headers. With the exception of "P-" headers
...
... headers. With the exception of "P-" headers
described in Section 4.1, all SIP extensions must be standards track
and must be developed in the IETF based upon requirements ...
... mailing lists
continue after the working group is concluded. If the SIP Working
Group has closed and no suitable replacement or follow-on working
group is active ...
... SIPPING mailing lists and designated experts from the SIP community
for advice. The IETF will remain the home of extensions of SIP ...
... SIP community
for advice. The IETF will remain the home of extensions of SIP and
the requirement of standards track action will remain as defined in
...
... Working Group is chartered to be a filter in front of the SIP Working
Group. This working group will investigate requirements ...
... working group will investigate requirements for
applications of SIP, some of which may lead to requests for
extensions to SIP. These requirements ...
... applications of SIP, some of which may lead to requests for
extensions to SIP. These requirements may come from the community at
large, or from individuals who are reporting the requirements ...
... SIPPING Working Group may determine: that these requirements can
be satisfied by SIP without modifications, that the requirements are
not sufficiently general to warrant a change to SIP ...
... SIP without modifications, that the requirements are
not sufficiently general to warrant a change to SIP, that the
requirements justify a change to SIP ...
... SIP, that the
requirements justify a change to SIP, or that the requirements should
be combined with other requirements ...
... or solve the same problem in a more flexible way.
Because the SIP protocol gets so much attention, some application
designers may want to use it just because it is there, such as for
controlling household appliances. SIPPING ...
... filter,
accepting only requirements which play to the best strengths of SIP,
such as realtime presence.
...
... SIPPING working group decides on a set of requirements, it
forwards them to the SIP working group. The SIPPING Working Group
...
... working group. The SIPPING Working Group
may also document usage or applications of SIP which do not require
any protocol extensions.
...
... SIP Change Process ...
...
Anyone who thinks that the existing SIP protocol is applicable to
their application, yet not sufficient for their task must write an
individual Internet-Draft ...
... individual Internet-Draft explaining the problem they are trying to
solve, why SIP is the applicable protocol, and why the existing SIP
protocol will not work. The Internet-Draft ...
... Internet-Draft explaining the problem they are trying to
solve, why SIP is the applicable protocol, and why the existing SIP
protocol will not work. The Internet-Draft must include a detailed
...
... Internet-Draft must include a detailed
set of requirements (distinct from solutions) that SIP would need to
meet to solve the particular problem. The Internet-Draft must also
...
... In a separate Internet-Draft, the authors may describe a set of
changes to SIP that would meet the requirements. The Internet-Draft
...
... requirements. The Internet-Draft
would then be passed to the SIP working group for consideration (if
warranted). The SIP ...
... SIP working group for consideration (if
warranted). The SIP working group is not required to adopt the
proposed solution from this additional Internet-Draft ...
... SIPPING working group may also evaluate such proposals for
extensions if the requirements are judged to be appropriate to SIP,
but are not sufficiently general for standards track activity. The
SIPPING working group ...
... Transport ADs may, on a case by case basis, support a process in
which the requirements analysis is implicit and the SIP working group
requests the addition of a charter item for an extension without a
...
... SIPPING process as described. This will be the exception.
With respect to standardization, this process means that SIP
extensions come only from the IETF, the body that created ...
... extensions come only from the IETF, the body that created SIP. The
IETF will not publish a SIP ...
... Working Group is required to protect the architectural
integrity of SIP and must not add features that do not have general
use beyond the specific case. Also, they must not add features just
to make a particular function more efficient at the expense of
...
... working groups besides SIPPING generate requirements for SIP
solutions and/or extensions as well. At the time this document was
written, these include SIP ...
... SIP
solutions and/or extensions as well. At the time this document was
written, these include SIP for Instant Messaging and Presence
Leveraging Extensions (simple), Service ...
... Transport Area calls for architectural guardianship and application
of Occam's Razor by the SIP Working Group.
...
... running code and rough
consensus", it is valid to allow for the development of SIP
extensions that are either not ready for standards track, but might
be understood for that role ...
... or proprietary in nature, because a characteristic motivating them is
usage that is known not to fit the Internet architecture for SIP. We
call these "P-" headers, for "preliminary", "private", or
...
... including documentation that get Expert and IESG review, and other
SIP protocol criteria described below.
Informational SIP ...
... SIP protocol criteria described below.
Informational SIP Headers can be registered as "P-" headers if all of
...
... 2434 [4]) MUST review the
proposal for applicability to SIP and conformance to these
guidelines. The Expert Reviewer will send email to the Transport ...
... his/her opinion.
2. The proposed extension MUST NOT define SIP option tags, response
codes, or methods ...
... 4. The proposed header MUST be of a purely informational nature, and
MUST NOT significantly change the behavior of SIP entities which
support it. Headers which merely provide additional information
...
... headers redefine or contradict normative behavior defined in
standards track SIP specifications, that is what is meant by
significantly different behavior.
...
... applicability statement in the Informational RFC MUST clearly
document the useful scope of the proposal, and explain its
limitations and why it is not suitable for the general use of SIP
in the Internet.
...
... header (meaning "not specified by a
standards-track RFC issued through the SIP Working Group") MUST
include a "P-" prefix ...
... deployment considered compliant to IETF
specifications. Specifically, implementations are only SIP compliant
if a) they fall back to baseline behavior when they ignore all P-
...
... SIP Event Packages ...
... working group item.
Individuals may also wish to publish SIP Event packages. Individual
proposals for registration ...
... Event packages. Individual
proposals for registration of a SIP event package MUST first be
published as Internet-drafts for review by the SIPPING Working Group ...
... discussion. The SIPPING Working Group will determine if the
proposed package is a) an inappropriate usage of SIP, b) applicable
to SIP but not sufficiently interesting, general, or in-scope to
...
... proposed package is a) an inappropriate usage of SIP, b) applicable
to SIP but not sufficiently interesting, general, or in-scope to
adopt as a working group effort, c) contrary to similar work planned
...
... 2434 [4]) MUST review the
proposal for applicability to SIP and conformance with these
guidelines. The Expert Reviewer will send email to the IESG ...
... 4. The event package MUST NOT redefine or contradict the normative
behavior of SIP events [4], SIP [3 ...
... extensions.
5. The proposed package MUST NOT undermine SIP security in any
sense. The Internet Draft ...
... IANA. The
package MUST document all the package considerations required in
Section 5 of SIP events [4].
...
... MUST clearly document the useful scope of the proposal, and
explain its limitations and why it is not suitable for the
general use of SIP in the Internet.
...
... All Internet-Drafts that present new requirements for SIP must
include a discussion of the security requirements ...
... discussion of the security requirements and implications
inherent in the proposal. All RFCs that modify or extend SIP must
show that they have adequate security and do not worsen SIP ...
... SIP must
show that they have adequate security and do not worsen SIP's
existing security considerations.
...
... option tags, and a registry for SIP response codes, and to amend the
practices used for the existing registry ...
... IANA-Greeting.
P-header's "reserved standard names" MUST NOT be used in a SIP
implementation prior to standardization of the header.
...
... IANA to establish a registry for
SIP event packages and SIP event template packages. For event
...
... SIP event packages and SIP event template packages. For event
template packages, entries go into this registry only by approval of
...
... issues in a wide range of protocols, including those that our area
brings forward and others. Thanks to the many members of the SIP
community engaged in interesting dialogue about this document as
well; Jonathan Rosenberg and Jon Peterson gave us useful reviews.
...
... Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261prop, June 2002. ...
... Roach, A., "Session Initiation Protocol (SIP) - Specific Event Notification", RFC 3265prop, June 2002. ...