|
| | | Top
| | 3261-32xx
| 33xx
| 34xx
| 35xx
| 36xx
| 37xx
| 38xx
| 39xx
| | Prev
| Next
| 40xx
| 41xx
| 42xx
| 43xx
| 44xx
| 45xx
| 46xx
| 47xx
| | | | 48xx
| 49xx
| 50xx
| 51xx
| 52xx
| 53xx
| 54xx
| 55xx
| | | | 56xx | 57xx | 58xx | 59xx | 60xx | 61xx | 62xx | Before 3261
| |
| | |
|
37xx
|
| | # RFC 3702
| AAA Requirements for SIP
| # RFC 3725
| SIP 3pcc
| # RFC 3761
| E.164 to URI DDDS Application (ENUM)
| # RFC 3764
| SIP enumservice
| |
|
|
|
|
|
| | | | RFC3702
02/2004
(15 p.)
pdf(p)
| J. Loughney
G. Camarillo | SIPPING
| Authentication, Authorization, and Accounting Requirements for SIP
| As SIP services are deployed on the Internet, there
is a need for authentication, authorization, and accounting of SIP
sessions. This document sets out the basic requirements for this work. |
|
|
|
|
|
|
| | | | RFC3725
04/2004
(31 p.)
pdf(p)
| J. Rosenberg
J. Peterson
H. Schulzrinne
G. Camarillo | SIPPING
| Best Current Practices for Third Party Call Control (3pcc) in SIP
| Third party call control refers to the ability of one
entity to create a call in which communication is actually between
other parties. Third party call control is possible using the
mechanisms specified within SIP. However, there are several possible
approaches, each with different benefits and drawbacks. This document
discusses best current practices for the usage of SIP for third party
call control. |
|
|
| | Up
| Status: | Best Current Practice (BCP: 85) | |
|
|
|
|
| | | | RFC3761
04/2004
(18 p.)
pdf(v)
pdf(p)
| P. Faltstrom
M. Mealling | ENUM
| The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
| This document discusses the use of the Domain Name
System (DNS) for storage of E.164 numbers. More specifically, how DNS
can be used for identifying available services connected to one E.164
number. |
|
|
| | Up
| Status: | Proposed Standard -- obsoletes: RFC 2916
| |
|
|
|
|
| | | | RFC3764
04/2004
(8 p.)
pdf(p)
| J. Peterson | ENUM
| enumservice registration for SIP Addresses-of-Record
| This document registers an Electronic Number (ENUM) service for SIP, pursuant to the guidelines in RFC 3761
. Specifically, this document focuses on provisioning SIP addresses-of-record in ENUM. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | Top
| | 3261-32xx
| 33xx
| 34xx
| 35xx
| 36xx
| 37xx
| 38xx
| 39xx
| | Prev
| Next
| 40xx
| 41xx
| 42xx
| 43xx
| 44xx
| 45xx
| 46xx
| 47xx
| | | | 48xx
| 49xx
| 50xx
| 51xx
| 52xx
| 53xx
| 54xx
| 55xx
| | | | 56xx | 57xx | 58xx | 59xx | 60xx | 61xx | 62xx | Before 3261
| |
| | |
|
38xx
|
| | # RFC 3824
| Using E.164 numbers with SIP
| # RFC 3825
| DHCP Option for Coordinate-based Location Configuration Information
| # RFC 3840
| Indicating User Agent Capabilities in SIP
| # RFC 3841
| Caller Preferences for SIP
| # RFC 3842
| SIP Message Waiting
| # RFC 3853
| S/MIME AES Requirement for SIP
| # RFC 3856
| Presence Event Package for SIP
| # RFC 3857
| Watcher Information Event Template-Package for SIP
| # RFC 3858
| XML-based Format for Watcher Information
| # RFC 3859
| Common Profile for Presence (CPP)
| # RFC 3860
| Common Profile for Instant Messaging (CPIM)
| # RFC 3861
| Address Resolution for Instant Messaging and Presence
| # RFC 3862
| CPIM: Message Format
| # RFC 3863
| Presence Information Data Format (PIDF)
| # RFC 3880
| Call Processing Language (CPL)
| # RFC 3890
| Bandwidth Modifier for SDP
| # RFC 3891
| SIP "Replaces" Header
| # RFC 3892
| SIP "Referred-By" Mechanism
| # RFC 3893
| SIP Authenticated Identity Body (AIB) Format
| |
|
|
|
|
|
| | | | RFC3824
06/2004
(16 p.)
pdf(p)
| J. Peterson
H. Liu
J. Yu
B. Campbell | SIPPING
| Using E.164 numbers with SIP
| There are a number of contexts in which telephone
numbers are employed by SIP applications, many of which can be
addressed by ENUM. Although SIP was one of the primary applications for
which ENUM was created, there is nevertheless a need to define
procedures for integrating ENUM with SIP implementations. This document
illustrates how the two protocols might work in concert, and clarifies
the authoring and processing of ENUM records for SIP applications. It
also provides guidelines for instances in which ENUM, for whatever
reason, cannot be used to resolve a telephone number. |
|
|
|
|
|
|
| | | | RFC3825
07/2004
(15 p.)
pdf(p)
| J. Polk
J. Schnizlein
M. Linsner | GEOPRIV
| Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information
| This document specifies a Dynamic Host Configuration
Protocol Option for the coordinate-based geographic location of the
client. The Location Configuration Information (LCI) includes latitude,
longitude, and altitude, with resolution indicators for each. The
reference datum for these values is also included. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3840
08/2004
(36 p.)
pdf(v)
pdf(p)
| J. Rosenberg
H. Schulzrinne
P. Kyzivat | SIP
| Indicating User Agent Capabilities in SIP
| This specification defines mechanisms by which a SIP
user agent can convey its capabilities and characteristics to other
user agents and to the registrar for its domain. This information is
conveyed as parameters of the "Contact
" header field.
This document defines the 'pref
' SIP option tag.
This specification serves to create the "SIP Media Feature Tag Registration Tree (1.3.6.1.8.4)
" with the "sip.
" prefix (see: http://www.iana.org/ assignments/media-feature-tags
) and it registers a number of new Media feature tags:
| sip.audio (1) | sip.application (2) | sip.data (3) | | sip.control (4) | sip.video (5) | sip.text (6) | | sip.automata (7) | sip.class (8) | sip.duplex (9) | | sip.mobility (10) | sip.description (11) | sip.events (12) | | sip.priority (13) | sip.methods (14) | sip.extensions (15) | | sip.schemes (16) | sip.actor (17) | sip.isfocus (18) |
|
|
|
| | Up
| Status: | Proposed Standard | | See also: | RFC 4235
, RFC 4569
, draft-ietf-sip-ice-option-tag
| |
|
|
|
|
| | | | RFC3841
08/2004
(26 p.)
pdf(v)
pdf(p)
| J. Rosenberg
H. Schulzrinne
P. Kyzivat | SIP
| Caller Preferences for SIP
| This document describes a set of extensions to SIP
which allow a caller to express preferences about request handling in
servers. These preferences include the ability to select which Uniform
Resource Identifiers (URI) a request gets routed to, and to specify
certain request handling directives in proxies and redirect servers. It
does so by defining three new request header fields, "Accept-Contact
", "Reject-Contact
", and "Request-Disposition
", which specify the caller's preferences. |
|
|
| | Up
| Status: | Proposed Standard | | See also: | RFC 4596
| |
|
|
|
|
| | | | RFC3842
08/2004
(19 p.)
pdf(p)
| R. Mahy | SIPPING
| A Message Summary and Message Waiting Indication Event Package for SIP
| This document describes the 'message-summary
' SIP event package to carry message waiting status and message summaries from a messaging system to an interested User Agent. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3853
07/2004
(6 p.)
pdf(p)
| J. Peterson | SIP
| S/MIME Advanced Encryption Standard (AES) Requirement for SIP
| RFC3261 currently specifies 3DES as the
mandatory-to-implement ciphersuite for implementations of S/MIME in SIP
This document updates the normative guidance of RFC3261 to require the
Advanced Encryption Standard (AES) for S/MIME. |
|
|
| | Up
| Status: | Proposed Standard -- updates: RFC3261
| |
|
|
|
|
| | | | RFC3856
08/2004
(27 p.)
pdf(p)
| J. Rosenberg | SIMPLE
| A Presence Event Package for SIP
| This document describes the usage of SIP for
subscriptions and notifications of presence. Presence is defined as the
willingness and ability of a user to communicate with other users on
the network. Historically, presence has been limited to "on-line" and
"off-line" indicators; the notion of presence here is broader.
Subscriptions and notifications of presence are supported by defining
the 'presence
'
event package within the general SIP event notification framework. This
protocol is also compliant with the Common Presence Profile (CPP)
framework. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3857
08/2004
(20 p.)
pdf(p)
| J. Rosenberg | SIMPLE
| A Watcher Information Event Template-Package for SIP
| This document defines the 'winfo
'
template-package for SIP event framework. Watcher information refers to
the set of users subscribed to a particular resource within a
particular event package. Watcher information changes dynamically as
users subscribe, unsubscribe, are approved, or are rejected. A user can
subscribe to this information, and therefore learn about changes to it.
This event package is a template-package because it can be applied to
any event package, including itself. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3858
08/2004
(13 p.)
pdf(p)
| J. Rosenberg | SIMPLE
| An XML Based Format for Watcher Information
| Watchers are defined as entities that request (i.e.,
subscribe to) information about a resource. There is fairly complex
state associated with these subscriptions. The union of the state for
all subscriptions to a particular resource is called the watcher
information for that resource. This state is dynamic, changing as
subscribers come and go. As a result, it is possible, and indeed
useful, to subscribe to the watcher information for a particular
resource. In order to enable this, a format is needed to describe the
state of watchers on a resource. This specification describes an
Extensible Markup Language (XML) document format for such state.
This document registers a new MIME type, application/watcherinfo+xml
. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3859
08/2004
(15 p.)
pdf(p)
| J. Peterson | IMPP | Common Profile for Presence (CPP)
| At the time this document was written, numerous
presence protocols were in use (largely as components of commercial
instant messaging services), and little interoperability between
services based on these protocols has been achieved. This specification
defines common semantics and data formats for presence to facilitate
the creation of gateways between presence services. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3860
08/2004
(13 p.)
pdf(p)
| J. Peterson | IMPP | Common Profile for Instant Messaging (CPIM)
| At the time this document was written, numerous
instant messaging protocols were in use, and little interoperability
between services based on these protocols has been achieved. This
specification defines common semantics and data formats for instant
messaging to facilitate the creation of gateways between instant
messaging services. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3861
08/2004
(8 p.)
pdf(p)
| J. Peterson | IMPP | Address Resolution for Instant Messaging and Presence
| Presence and instant messaging are defined in RFC 2778
.
The Common Profiles for Presence and Instant Messaging define two
Universal Resource Identifier (URI) schemes: 'im' for INSTANT INBOXes
and 'pres' for PRESENTITIES. This document provides guidance for
locating the resources associated with URIs that employ these schemes. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3862
08/2004
(30 p.)
pdf(p)
| G. Klyne
D. Atkins | IMPP | CPIM: Message Format
| This memo defines the MIME content type
'Message/CPIM', a message format for protocols that conform to the
Common Profile for Instant Messaging (CPIM) specification. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3863
08/2004
(28 p.)
pdf(p)
| H. Sugano
S. Fujimoto
G. Klyne
A. Bateman
W. Carr
J. Peterson | IMPP | Presence Information Data Format (PIDF)
| This memo specifies the Common Profile for Presence
(CPP) Presence Information Data Format (PIDF) as a common presence data
format for CPP-compliant Presence protocols, and also defines a new media type "application/ pidf+xml"
to represent the XML MIME entity for PIDF. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3880
10/2004
(74 p.)
pdf(p)
| J. Lennox
X. Wu
H. Schulzrinne | IPTEL
| Call Processing Language (CPL): A Language for User Control of Internet Telephony Services
| This document defines the Call Processing Language
(CPL), a language to describe and control Internet telephony services.
It is designed to be implementable on either network servers or user
agents. It is meant to be simple, extensible, easily edited by
graphical clients, and independent of operating system or signalling
protocol. It is suitable for running on a server where users may not be
allowed to execute arbitrary programs, as it has no variables, loops,
or ability to run external programs.
This document registers a new MIME type, application/cpl+xml
. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3890
09/2004
(22 p.)
pdf(p)
| M. Westerlund | MMUSIC
| A Transport Independent Bandwidth Modifier for SDP
| This document defines an SDP Transport Independent
Application Specific Maximum (TIAS) bandwidth modifier that does not
include transport overhead; instead an additional packet rate attribute
is defined. The transport independent bit-rate value together with the
maximum packet rate can then be used to calculate the real bit-rate
over the transport actually used.
The existing SDP bandwidth
modifiers and their values include the bandwidth needed for the
transport and IP layers. When using SDP with protocols like the Session
Announcement Protocol (SAP), SIP, and the Real-Time Streaming Protocol
(RTSP), and when the involved hosts has different transport overhead,
for example due to different IP versions, the interpretation of what
lower layer bandwidths are included is not clear. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3891
09/2004
(16 p.)
pdf(p)
| R. Mahy
B. Biggs
R. Dean | SIP
| The SIP Replaces Header
| This document defines a new header for use with SIP multi-party applications and call control. The "Replaces
"
header is used to logically replace an existing SIP dialog with a new
SIP dialog. This primitive can be used to enable a variety of features,
for example: "Attended Transfer" and "Call Pickup". Note that the
definition of these example features is non-normative.
This document defines the 'replaces
' SIP option tag. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3892
09/2004
(25 p.)
pdf(p)
| R. Sparks | SIP
| The SIP Referred-By Mechanism
| The SIP REFER
method provides a mechanism where one party (the referrer) gives a
second party (the referee) an arbitrary URI to reference. If that URI
is a SIP URI, the referee will send a SIP request, often an INVITE, to
that URI (the refer target). This document extends the REFER
method, allowing the referrer to provide information about the REFER
request to the refer target using the referee as an intermediary. This
information includes the identity of the referrer and the URI to which
the referrer referred. The mechanism utilizes S/MIME to help protect
this information from a malicious intermediary. This protection is
optional, but a recipient may refuse to accept a request unless it is
present.
This document defines the "Referred-By
" header field. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3893
09/2004
(13 p.)
pdf(p)
| J. Peterson | SIP
| SIP Authenticated Identity Body (AIB) Format
| RFC 3261
introduces the concept of adding an S/MIME body to a SIP request or
response in order to provide reference integrity over its headers. This
document provides a more specific mechanism to derive integrity and
authentication properties from an 'authenticated identity body', a
digitally-signed SIP message, or message fragment. A standard format
for such bodies (known as Authenticated Identity Bodies, or AIBs) is
given in this document. Some considerations for the processing of AIBs
by recipients of SIP messages with such bodies are also given. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | Top
| | 3261-32xx
| 33xx
| 34xx
| 35xx
| 36xx
| 37xx
| 38xx
| 39xx
| | Prev
| Next
| 40xx
| 41xx
| 42xx
| 43xx
| 44xx
| 45xx
| 46xx
| 47xx
| | | | 48xx
| 49xx
| 50xx
| 51xx
| 52xx
| 53xx
| 54xx
| 55xx
| | | | 56xx | 57xx | 58xx | 59xx | 60xx | 61xx | 62xx | Before 3261
| |
| | |
|
39xx
|
| | # RFC 3903
| SIP Event State Publication (PUBLISH)
| # RFC 3910
| SPIRITS Protocol
| # RFC 3911
| SIP "Join" Header
| # RFC 3953
| ENUM Registration for Presence Services
| # RFC 3959
| Early Session Disposition Type for SIP
| # RFC 3960
| Early Media and Ringing Tone Generation in SIP
| # RFC 3966
| The "tel" URI for Telephone Numbers
| # RFC 3968
| IANA Header Field Parameter Registry for SIP
| # RFC 3969
| IANA URI Parameter Registry for SIP
| # RFC 3976
| Interworking SIP and Intelligent Network (IN) Applications
| # RFC 3986
| Uniform Resource Identifier (URI): Generic Syntax
| # RFC 3987
| Internationalized Resource Identifiers (IRIs)
| # RFC 3994
| Indication of Message Composition for Instant Messaging
| |
|
|
|
|
|
| | | | RFC3903
10/2004
(32 p.)
pdf(v)
pdf(p)
| A. Niemi | SIP
| SIP Extension for Event State Publication
| This document describes an extension to SIP for publishing event state used within the SIP Events framework. It defines the "PUBLISH
"
method. The first application of this extension is for the publication
of presence information. The mechanism described in this document can
be extended to support publication of any event state for which there
exists an appropriate event package. It is not intended to be a
general-purpose mechanism for transport of arbitrary data, as there are
better-suited mechanisms for this purpose.
This document defines the "SIP-ETag
" and "SIP-If-Match
" header fields. |
|
|
| | Up
| Status: | Proposed Standard | | See also: | RFC 3265
| |
|
|
|
|
| | | | RFC3910
10/2004
(50 p.)
pdf(p)
| V. Gurbani
A. Brusilovsky
I. Faynberg
J. Gato
H. Lu
M. Unmehopa | SPIRITS | The SPIRITS (Services in PSTN requesting Internet Services) Protocol
| This document describes the Services in PSTN (Public
Switched Telephone Network) requesting Internet Services (SPIRITS)
protocol. The purpose of the SPIRITS protocol is to support services
that originate in the cellular or wireline PSTN and necessitate
interactions between the PSTN and the Internet. On the PSTN side, the
SPIRITS services are most often initiated from the Intelligent Network
(IN) entities. Internet Call Waiting and Internet Caller-ID Delivery
are examples of SPIRITS services, as are location-based services on the
cellular network. The protocol defines the building blocks from which
many other services can be built.
This document defines the 'spirits-INDPs
' and 'spirits-user-prof
' SIP event packages. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3911
10/2004
(17 p.)
pdf(p)
| R. Mahy
D. Petrie | SIP
| The SIP "Join" Header
| This document defines a new header for use with SIP multi-party applications and call control. The "Join
"
header is used to logically join an existing SIP dialog with a new SIP
dialog. This primitive can be used to enable a variety of features, for
example: "Barge-In", answering-machine-style "Message Screening" and
"Call Center Monitoring". Note that definition of these example
features is non-normative.
This document defines the 'join
' SIP option tag. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3953
01/2005
(7 p.)
pdf(p)
| J. Peterson | ENUM
| Telephone Number Mapping (ENUM) Service Registration for Presence Services
| This document registers a Telephone Number Mapping
(ENUM) service for presence. Specifically, this document focuses on
provisioning pres URIs in ENUM. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3959
12/2004
(11 p.)
pdf(p)
| G. Camarillo | SIPPING
| The Early Session Disposition Type for SIP
| This document defines a new disposition type (early-session) for the Content-Disposition
header field in SIP. The treatment of "early-session" bodies is similar
to the treatment of "session" bodies. That is, they follow the
offer/answer model. Their only difference is that session descriptions
whose disposition type is "early-session" are used to establish early
media sessions within early dialogs, as opposed to regular sessions
within regular dialogs.
This document defines the 'early-session
' SIP option tag. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3960
12/2004
(13 p.)
pdf(p)
| G. Camarillo
H. Schulzrinne | SIPPING
| Early Media and Ringing Tone Generation in SIP
| This document describes how to manage early media in
SIP using two models: the gateway model and the application server
model. It also describes the inputs one needs to consider in defining
local policies for ringing tone generation. |
|
|
|
|
|
|
| | | | RFC3966
12/2004
(17 p.)
pdf(p)
| H. Schulzrinne | IPTEL
| The tel URI for Telephone Numbers
| This document specifies the URI (Uniform Resource
Identifier) scheme "tel". The "tel" URI describes resources identified
by telephone numbers. |
|
|
| | Up
| Status: | Proposed Standard -- updated by: RFC 5341
-- obsoletes RFC 2806
| | See also: | RFC 4694
, RFC 4715
, RFC 4759
, RFC 4904
,
ABNF for "tel" URI
| |
|
|
|
|
| | | | RFC3968
12/2004
(8 p.)
pdf(p)
| G. Camarillo | SIP
| The IANA Header Field Parameter Registry for SIP
| This document creates an Internet Assigned Number
Authority (IANA) registry for SIP header field parameters and parameter
values. It also lists the already existing parameters and parameter
values to be used as the initial entries for this registry. |
|
|
| | Up
| Status: | Best Current Practice (BCP: 98) -- updates: RFC 3427
| |
|
|
|
|
| | | | RFC3969
12/2004
(6 p.)
pdf(p)
| G. Camarillo | SIP
| The IANA URI Parameter Registry for SIP
| This document creates an Internet Assigned Number
Authority (IANA) registry for SIP and SIPS Uniform Resource Identifier
(URI) parameters, and their values. It also lists the already existing
parameters to be used as initial values for that registry.
This sub-registry
is defined under http://www.iana.org/assignments/ sip-parameters
, and is labeled "SIP/SIPS URI Parameters
".
The initial parameters defined in this sub-registry are: "lr
", "maddr
", "method
", "transport
", "ttl
", "user
", defined in RFC 3261
, as well as "comp
", defined in RFC 3486
. |
|
|
| | Up
| Status: | Best Current Practice (BCP: 99) -- updates: RFC 3427
| |
|
|
|
|
| | | | RFC3976
01/2005
(25 p.)
pdf(p)
| V. K. Gurbani
F. Haerens
V. Rastogi | - | Interworking SIP and Intelligent Network (IN) Applications
| Public Switched Telephone Network (PSTN) services
such as 800-number routing (freephone), time-and-day routing,
credit-card calling, and virtual private network (mapping a private
network number into a public number) are realized by the Intelligent
Network (IN). This document addresses means to support existing IN
services from Session Initiation Protocol (SIP) endpoints for an
IP-host-to-phone call. The call request is originated on a SIP
endpoint, but the services to the call are provided by the data and
procedures resident in the PSTN/IN. To provide IN services in a
transparent manner to SIP endpoints, this document describes the
mechanism for interworking SIP and Intelligent Network Application Part
(INAP). |
|
|
|
|
|
|
| | | | RFC3986
12/2004
(61 p.)
pdf(v)
pdf(p)
| T. Berners-Lee
R. Fielding
L. Masinter | - | URI Generic Syntax
| A Uniform Resource Identifier (URI) is a compact
sequence of characters that identifies an abstract or physical
resource. This specification defines the generic URI syntax and a
process for resolving URI references that might be in relative form,
along with guidelines and security considerations for the use of URIs
on the Internet. The URI syntax defines a grammar that is a superset of
all valid URIs, allowing an implementation to parse the common
components of a URI reference without knowing the scheme-specific
requirements of every possible identifier. This specification does not
define a generative grammar for URIs; that task is performed by the
individual specifications of each URI scheme. |
|
|
| | Up
| Status: | Standard (STD0066)
| | | | -- updates: RFC 1738
-- obsoletes RFC 2732
, RFC 2396
, RFC 1808
| | See also: | ABNF for URI Generic Syntax
| |
|
|
|
|
| | | | RFC3987
12/2004
(46 p.)
pdf(p)
| M. Duerst
M. Suignard | - | Internationalized Resource Identifiers (IRIs)
| This document defines a new protocol element, the
Internationalized Resource Identifier (IRI), as a complement to the
Uniform Resource Identifier (URI). An IRI is a sequence of characters
from the Universal Character Set (Unicode/ISO 10646). A mapping from
IRIs to URIs is defined, which means that IRIs can be used instead of
URIs, where appropriate, to identify resources.
The approach
of defining a new protocol element was chosen instead of extending or
changing the definition of URIs. This was done in order to allow a
clear distinction and to avoid incompatibilities with existing
software. Guidelines are provided for the use and deployment of IRIs in
various protocols, formats, and software components that currently deal
with URIs. |
|
|
| | Up
| Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3994
01/2005
(13 p.)
pdf(p)
| H. Schulzrinne | SIMPLE
| Indication of Message Composition for Instant Messaging
| In instant messaging (IM) systems, it is useful to
know during an IM conversation whether the other party is composing a
message; e.g., typing or recording an audio message. This document
defines a new status message content type and XML namespace that
conveys information about a message being composed. The status message
can indicate the composition of a message of any type, including text,
voice, or video. The status messages are delivered to the instant
messaging recipient in the same manner as the instant messages
themselves.
This document registers a new MIME type, application/im-iscomposing+xml
. |
|
|
| | Up
| Status: | Proposed Standard |
|
