diff --git a/etc/AddressBook.pdf b/etc/AddressBook.pdf deleted file mode 100644 index bb6354a..0000000 Binary files a/etc/AddressBook.pdf and /dev/null differ diff --git a/etc/Comment.txt b/etc/Comment.txt deleted file mode 100644 index e0434f7..0000000 --- a/etc/Comment.txt +++ /dev/null @@ -1,99 +0,0 @@ - -Authors: howes@netscape.com, mcs@netscape.com, frank_dawson@lotus.com - -* The meaning of "Z" and of the time-zone offset is never defined - -I assume that the +/- form has the same definition as RFC822, what is the "Z"? - -* why is there no value=image? This would seem to be particularly useful for PHOTO... - -* Errors in the definition of time: - - time-secfrac = "," 1*DIGIT - -This, if true, means that the time-list would be ambiguous: - - time-list = time *("," time) - -But luckily (...?!) it conflicts with the examples given: - - Examples for "time": - 10:22:00.33 - 10:22:00.33Z - - -* Errors in the samples - -From Example 3 (8.3) in RFC 2425: - - email;internet:mb@goerlitz.de - -The second would appear to be *both* syntactically invalid (no "=", see below), -and not a valid RFC 2426 EMAIL parameter. - - -From Example 2 (8.2) in RFC 2425: - - ... - Content-Transfer-Encoding: Quoted-Printable - - begin:VCARD - source:ldap://cn=bjorn%20Jensen, o=university%20of%20Michigan, c=US - -This is obviously not quoted-printable (since =bj is not valid) it's just 7bit. -If it was quoted-printable, "cn=bjorn" would be "cn=3dbjorn". - - -The vcards also don't have a VERSION field, making them non-rfc2426 compliant. - - - -* Differences between 2.1 and 3.0 that aren't mentioned, or are an RFC 2426 EBNF error - -Rfc2425 neglects to mention as a difference that multiple group names -are allowed in vCard 2.1, but not vCard 3.0 (RFC 2425). - -Or is this an error in the RFC2426 EBNF? - -vCard 2.1: - - groups = groups "." word / word - item = [groups "."] name [params] ":" value CRLF - -vCard 3.0/RFC 2426: - - contentline = [group "."] name *(";" param ) ":" value CRLF - group = 1*(ALPHA / DIGIT / "-") - - - - - -* params without values are allowed, but not without an "=" - -param = param-name "=" param-value *("," param-value) -param-value = ptext / quoted-string -ptext = *SAFE-CHAR - -So - -field;toggle:value - -is invalid, but - -field;toggle=:value -field;toggle=,,:value - -are valid? Is this really the intention? - -* no DQUOTE in parameter values - -parameter values appear not to be able to contain a DQUOTE, even -escaped. So: - -name;param="..\"..":value - -is invalid. This surprised me, I'd assumed that that quoting would be -possible. I'm not complaining, it makes the syntax simpler, was it -intended? I'm not missing something, am I? - diff --git a/etc/dir-30.bnf b/etc/dir-30.bnf deleted file mode 100644 index f454ac6..0000000 --- a/etc/dir-30.bnf +++ /dev/null @@ -1,159 +0,0 @@ -From RFC 2425 - -5.8.2. ABNF content-type definition - - The following ABNF uses the notation of RFC 2234, which also defines - CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT. After the unfolding of - any folded lines as described above, the syntax for a line of this - content type is as follows: - - contentline = [group "."] name *(";" param) ":" value CRLF - ; When parsing a content line, folded lines MUST first - ; be unfolded according to the unfolding procedure - ; described above. - ; When generating a content line, lines longer than 75 - ; characters SHOULD be folded according to the folding - ; procedure described above. - - group = 1*(ALPHA / DIGIT / "-") - - name = x-name / iana-token - - iana-token = 1*(ALPHA / DIGIT / "-") - ; identifier registered with IANA - - x-name = "x-" 1*(ALPHA / DIGIT / "-") - ; Names that begin with "x-" or "X-" are - ; reserved for experimental use, not intended for released - ; products, or for use in bilateral agreements. - - param = param-name "=" param-value *("," param-value) - - param-name = x-name / iana-token - - param-value = ptext / quoted-string - - ptext = *SAFE-CHAR - - value = *VALUE-CHAR - / valuespec ; valuespec defined in section 5.8.4 - - quoted-string = DQUOTE *QSAFE-CHAR DQUOTE - - NON-ASCII = %x80-FF - ; use restricted by charset parameter - ; on outer MIME object (UTF-8 preferred) - - QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-ASCII - ; Any character except CTLs, DQUOTE - - SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII - ; Any character except CTLs, DQUOTE, ";", ":", "," - - VALUE-CHAR = WSP / VCHAR / NON-ASCII - ; any textual character - -5.8.3. Pre-defined Parameters - - The following parameters and value types are defined for general use. - - predefined-param = encodingparm - / valuetypeparm - / languageparm - / contextparm - - encodingparm = "encoding" "=" encodingtype - - encodingtype = "b" ; from RFC 2047 - / iana-token ; registered as described in - ; section 15 of this document - - valuetypeparm = "value" "=" valuetype - - valuetype = "uri" ; genericurl from secion 5 of RFC 1738 - / "text" - / "date" - / "time" - / "date-time" ; date time - / "integer" - / "boolean" - / "float" - / x-name - / iana-token ; registered as described in - ; section 15 of this document - - languageparm = "language" "=" Language-Tag - ; Language-Tag is defined in section 2 of RFC 1766 - - contextparm = "context" "=" context - - context = x-name - / iana-token - -5.8.4. Pre-defined Value Types - - The format for values corresponding to the predefined valuetype - specifications given above are defined. - - valuespec = text-list - / genericurl ; from section 5 of RFC 1738 - / date-list - / time-list - / date-time-list - / boolean - / integer-list - / float-list - / iana-valuespec - - text-list = *TEXT-LIST-CHAR *("," *TEXT-LIST-CHAR) - - TEXT-LIST-CHAR = "\\" / "\," / "\n" - / - ; Backslashes, newlines, and commas must be encoded. - ; \n or \N can be used to encode a newline. - - date-list = date *("," date) - - time-list = time *("," time) - - date-time-list = date "T" time *("," date "T" time) - - boolean = "TRUE" / "FALSE" - - integer-list = integer *("," integer) - - integer = [sign] 1*DIGIT - - float-list = float *("," float) - - float = [sign] 1*DIGIT ["." 1*DIGIT] - - sign = "+" / "-" - - date = date-fullyear ["-"] date-month ["-"] date-mday - - date-fullyear = 4 DIGIT - - date-month = 2 DIGIT ;01-12 - - date-mday = 2 DIGIT ;01-28, 01-29, 01-30, 01-31 - ;based on month/year - - time = time-hour [":"] time-minute [":"] time-second [time-secfrac] - [time-zone] - - time-hour = 2 DIGIT ;00-23 - - time-minute = 2 DIGIT ;00-59 - - time-second = 2 DIGIT ;00-60 (leap second) - - time-secfrac = "," 1*DIGIT - - time-zone = "Z" / time-numzone - - time-numzome = sign time-hour [":"] time-minute - - iana-valuespec = diff --git a/etc/draft-butcher-irc-url-04.txt b/etc/draft-butcher-irc-url-04.txt deleted file mode 100644 index 3a3f99d..0000000 --- a/etc/draft-butcher-irc-url-04.txt +++ /dev/null @@ -1,840 +0,0 @@ - - -INTERNET-DRAFT Simon Butcher -Expires July 2004 Alien Internet Services - January 2003 - - - Uniform Resource Locator Schemes for - Internet Relay Chat Entities - - - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 10 of RFC2026. Distribution of this document is - unlimited. Comments should be sent to the "irc-url" mailing list, - specified at the end of this document. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - -Abstract - - This document specifies two URL (Uniform Resource Locator) schemes, - using the URI (Uniform Resource Indicator) names "irc" and "ircs", - for the location of IRC (Internet Relay Chat) servers. These URLs - allow for easy location of an IRC server, optionally also specifying - an IRC channel to join, or a person's nickname to contact upon - connection. - - - - -S. Butcher Expires July 2004 [Page 1] - -INTERNET-DRAFT URL Schemes for IRC January 2003 - - -1. Introduction - - Since its introduction, Internet Relay Chat (IRC) has become widely - known and used within the Internet Community as a real-time chat - medium. IRC networks are steadily growing larger, not only with - regards to the number of regular users, but also the number of - channels and servers required to support the diverse demand. - - Due to the nature of IRC as a real-time chat service, it has been - known to be used for a wide variety of uses such as software support, - job interviews, and of course just for a casual conversation. - - For years now, the need for an appropriate Uniform Resource Locator - (URL) scheme has been apparent. Applications for such a scheme range - quite widely, including IRC network's server lists on their website, - technical support contact details, or even a meeting location within - an e-mail, giving a specific IRC channel or nickname to contact. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - In this document, the term "client" is defined as the IRC client - software, and the term "user" is the end-user of that software. The - term "entity" refers to an addressable IRC entity, such as a user, - service, or channel. - - -2. URL Definition - - An IRC URL begins with either the Uniform Resource Identifiers (URIs) - "irc", or "ircs", denoting normal and secured connections - respectively. Normal sessions are via existing transport (such as - that in [RFC2812]) and is to be considered insecure. Secured - sessions are much the same, only secured via a "blanket security" - method such as [SSL], or negotiating a [TLS] session. - - The URL scheme for IRC follows the Generic URL Syntax ([RFC2396]). - - The action the URL instigates is to open a connection to the - specified IRC server using whatever protocol necessary, and make - contact with the given user, service or channel, if also requested. - - There is no requirement for IRC client software implementing the - "irc" scheme to also implement the "ircs" scheme, or vice-versa. It - is, however, RECOMMENDED that clients implementing the "ircs" scheme - are also capable of handling a normal connection via the "irc" - scheme. - - - -S. Butcher Expires July 2004 [Page 2] - -INTERNET-DRAFT URL Schemes for IRC January 2003 - - -2.1. ABNF Syntax - - Below is the definition for the IRC URL scheme in [ABNF] grammar: - - ircURL = ircURI "://" location "/" [ entity ] [ flags ] [ options ] - - ircURI = "irc" / "ircs" - ; See Section 2, above, for details. - - location = [ authinfo "@" ] hostport - ; See Section 3.2.2 of [RFC2396] for the definition - ; of 'hostport'. - - authinfo = [ username ] [ ":" password ] - ; See Section 2.2 of this document for details. - - username = *( escaped / unreserved ) - - password = *( escaped / unreserved ) [ ";" passtype ] - - passtype = *( escaped / unreserved ) - - entity = [ "#" ] *( escaped / unreserved ) - ; Note the prefix, "#", may be used for channel names - ; without escapes. Please see Section 2.5.1. - - flags = ( [ "," enttype ] [ "," hosttype ] ) - /= ( [ "," hosttype ] [ "," enttype ] ) - - enttype = "," ( "isuser" / "ischannel" ) - - hosttype = "," ( "isserver" / "isnetwork" ) - - options = "?" option *( "&" option ) - - option = optname [ "=" optvalue ] - - optname = *( ALPHA / "-" ) - ; Option names are case-insensitive. - - optvalue = optparam *( "," optparam ) - - optparam = *( escaped / unreserved ) - - The definition of "escaped" and "unreserved" is in sections - 2.4.1 and 2.3 of [RFC2396] respectively. Clients MUST be - aware of protocol limitations. For example, using "IRC-2" - (RFC2812), it's impossible to use codepoint U+0020 in names. - - - -S. Butcher Expires July 2004 [Page 3] - -INTERNET-DRAFT URL Schemes for IRC January 2003 - - -2.2. Authentication - - To allow for complete authentication of a session, a username MAY be - provided with the password. The username MUST NOT be passed to the - server as a nickname. For example, while registering a connection - using the "IRC-2" protocol, the username would be passed as the first - parameter of the "USER" command (See Section 3.1.3 of [RFC2812]). - - The characters available for use in a username may be restricted by - the protocol used, and the IRC server software used. - - The use of the password field is not recommended, as it presents a - significant security problem. Authors of IRC URLs using the - authentication field, including a password, should make themselves - aware of the security issues discussed in Section 6 of this document. - - See Section 3 for examples of username/password pair authentication, - and traditional server password only authentication. - - -2.3. Server Names - - Servers can be named with either their hostname, or address, like - other URL schemes, but also with an IRC Network's name. The - difference can be explicitly specified using the "isserver" and - "isnetwork" keywords in the "hosttype" section (see Section 3 for - examples). - - As many modern IRC clients maintain lists of major IRC networks and - their respective servers, determination of a server to connect to - from a given network name should be a trivial task. - - If the host name used is not a raw address (such as an IPv4, IPv6, or - other network address), the name cannot be resolved (through DNS or - other means), and does not contain a period character (U+002E), the - client MAY consider the given host name as a network name to find an - appropriate IRC server. - - If the IRC client does not contain IRC Network name lists, and - "isnetwork" has been specified, the client MUST NOT attempt to - resolve the network name as a hostname. - - -2.4. Server Ports - - Special consideration must be given to URLs without ports specified. - Almost all IRC servers are contactable on a variety of standard ports - as allocated by the IANA. Should an IRC URL be specified without a - - - -S. Butcher Expires July 2004 [Page 4] - -INTERNET-DRAFT URL Schemes for IRC January 2003 - - - port, a client MAY try a number of standard ports: - - - For the "irc" URI, the client SHOULD attempt connection to the - port 6667, and MAY attempt connection to the ports 194, 6665, - 6666, 6668 and 6669, in that order. Port 194 is likely to be a - more "authentic" server, however at this time the majority of - IRC servers are available on port 6667, at least. - - - For the "ircs" URI, the default port used is 994. User-space - ports (those above port 1023) may have questionable - authenticity, and SHOULD NOT be used unless explicitly - specified. - - Port numbers shown are in decimal, and have been assigned by the - IANA. Section 3.2.2 of [RFC2396] suggests only one port may be used - as a default port, and does not state a preference for or against - port hunting. The act of port hunting for the "irc" scheme when no - port is specified is therefore left up to the discretion of client - authors. - - For URL equivalency, clients SHOULD consider default ports without - considering port-hunting. For example, and - should be considered equivalent, as should - and . - - Note that the port 194 is officially the "standard" port for IRC - servers, the current practise is to use port 6667. This document may - be updated in the future if and when port 194 obtains an increased - prevailance. - - -2.5. Entity Names - - Only one entity can be named per URL. The named entity SHOULD be - presumed to be a channel name, unless the "enttype" section (see - Section 2.1) of the URL is provided to determine the entity type. - - An automated message MUST NOT be sent to the addressed entity. - - -2.5.1. Channel Names - - When "enttype" contains "ischannel", or "enttype" is omitted - completely, the entity name provided is a channel name. - - While it is discouraged, channel names prefixed with the "#" (U+0023) - character may be specified without encoding the character (as "%23") - in the URL. Implementers MAY accept this, despite it being an - - - -S. Butcher Expires July 2004 [Page 5] - -INTERNET-DRAFT URL Schemes for IRC January 2003 - - - exception to Section 2.4.3 of [RFC2396], because channels of this - type are currently very common, and will remain so in the foreseeable - future. - - Clients SHOULD attempt to determine valid channel name prefix - characters from the server it has connected to, such as via an - "RPL_ISUPPORT" reply. If the client is unable to determine valid - prefix characters for the server it is connected to, the client - SHOULD attempt to join the channel without modifying its name. If - joining the channel failed, the prefix character "#" may be used. - - If the client discovers the channel name given is considered to be - invalid because it is missing a valid prefix character, the client - SHOULD prepend a default prefix character to the name. - - Since default prefix characters for channels may differ between IRC - servers, the client SHOULD try to determine the default channel - prefix for the server it is connected to, such as the first prefix - character given by "CHANTYPES" in "RPL_ISUPPORT". If the client is - still unable to determine a prefix character, a prefix character of - '#' (U+0023) MAY be presumed. - - -2.5.2. Nicknames - - When "enttype" contains "isuser", the entity given refers to a user. - The given entity name may simply be a nickname, or it may contain - more specific information such as the user's hostname, username, or a - server they use. - - A user entity is referred to using the following syntax (in [ABNF] - grammar): - - userent = nickname [ "%21" username ] [ "%40" hostname ] - - - The definitions of "nickname", "username", and "hostname" are all - identical to the definition of "entname", as defined in Section 2.1 - of this document. - - It's RECOMMENDED that the client parse this name, as most servers - will not accept this syntax directly. For example, the client may - wish to make use of the IRC-2 "WHO" command to discover if the entity - is valid and available. - - - - - - - -S. Butcher Expires July 2004 [Page 6] - -INTERNET-DRAFT URL Schemes for IRC January 2003 - - -2.6. Additional Options - - Additional options may be used to provide additional information - about the entity you're addressing. - - These options listed here may be expanded on at a later date by - future documents. Unsupported options MUST be ignored by the client. - The client author is not obligated to utilise the "options" section - (see Section 2.1) of the URL, but it is RECOMMENDED to do so. - - -2.6.1. The "key" Option - - This option is only valid if the entity name given is a channel name. - If the entity name is not a channel name, then this option MUST - simply be ignored. - - The option's value provides a "key" to be given to the server when - joining the given channel name, and is used for channels which - require a "key" to join them. If a channel key is found to be - required and one is not provided with this option, the IRC client may - wish to prompt the user for the key. - - Please see Section 6 of this document. - - -3. Examples - - While examples of every situation cannot be shown here because of - space considerations, the following examples provide a rough overview - of how the IRC URL can be used. - - - - In its simplest form, the above complete URL can be used to direct a - client to a specific IRC server, which in this case is - "irc.undernet.org". The client should presume to use default port - settings. - - - - - - - All four of these URLs connects to the IRCnet network, and will join - the client to the channel "#worldchat" upon connection. All of these - URLs are considered identical. - - - - -S. Butcher Expires July 2004 [Page 7] - -INTERNET-DRAFT URL Schemes for IRC January 2003 - - - - - This will connect to the server "irc.alien.net.au" and will provoke - the client to open up a window (or similar) associated with sending - messages to the nickname 'pickle'. - - - - This will connect to AUSTnet and join the channel "#foobar", using - the channel key "bazqux". - - - - This will open a dialogue box prepared to send a message to "pickle" - with the server name "butcher.id.au". This URL will connect to the - network named as "undernet". For this to work correctly, the client - must be configured appropriately to know of at least one server's - address associated with this name. - - - - The above URL specifies that the IRC client should try to connect to - "irc.efnet.org" on the port 194, rather than use the default port(s). - It also tells the IRC client it should try to connect to the server - using the server password "pass". - - - - This shows a properly [UTF-8] encoded URL, specifying the username - "Idil" (with the first character being a Turkish Latin capital letter - "I" with a dot above it, [Unicode] codepoint U+0130) and the password - "guzel" (with a diaeresis on the u, codepoint U+00FC). - - - - - - - - - - - - - - - - - - - -S. Butcher Expires July 2004 [Page 8] - -INTERNET-DRAFT URL Schemes for IRC January 2003 - - -4. Internationalisation Considerations - - With the inevitable adoption of [Unicode] on IRC, and indeed the - Internet as a whole, URLs MUST be encoded using the [UTF-8] character - set, with (potentially) unsafe octets encoded using %HH notation - (where HH is a hexadecimal value), as per Section 2.2.5 of - [RFC-2718]. An example of this in action can be found in Section 3. - - Some IRC servers use such character sets as US-ASCII and KOI-8. It - is left up to the client and the server to negotiate an appropriate - character set for communication between the two, as more servers are - now implementing specific character-set preferences. It is also left - up to the client to convert entity names from UTF-8 into the - appropriate character set. - - At the time of writing, [UTF-8] is set to become the popular choice - (announced via RPL_ISUPPORT) as it's easy to implement with very - minimal changes to existing server software. Other IRC servers are - opting to announce a preferred character set, but allow the client to - switch character sets on the fly, using CAP/CAPAB negotiation, oft - implemented using the UNIX98 iconv() function (or something similar). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -S. Butcher Expires July 2004 [Page 9] - -INTERNET-DRAFT URL Schemes for IRC January 2003 - - -5. Interoperability Considerations - - Many existing implementations fail to acknowledge the correct use of - the generic URL syntax defined in [RFC2396], but act like they use - the format. - - Some current implementations will need slight modification to accept - the extended format defined in this specification, however most - implementations which parse the URL in a standard form will continue - to work for most IRC URLs. - - The presumption of a channel name without explicitly specifying the - entity type is designed to maintain compatibility with the existing - implementations. The practise of omitting the channel prefix - character, or not encoding it, is also for compatibility, but is - STRONGLY DISCOURAGED. - - There are interoperability issues with existing IRC servers as a - result of the restricted characters available for channel names and - nicknames. The restriction of acceptable characters has been left up - to the IRC server authors and not the URL scheme, as not to hinder - advances in IRC protocols and servers. - - Some existing IRC servers will accept nickname/password pairs, - however at the time of writing these servers do not use this for - actually authenticating the session, but instead identifying - nicknames to nickname registration services. The use of - username/password pairs is used for actual authentication, and has - been included. - - - - - - - - - - - - - - - - - - - - - - -S. Butcher Expires July 2004 [Page 10] - -INTERNET-DRAFT URL Schemes for IRC January 2003 - - -6. Security Considerations - - Security problems naturally arise when a server password and/or a - channel key is specified (using the "key" option). While the use of - the password and channel key sections is considered to be rare, and - they have been included for uses such as for shortcut/bookmark lists, - or to be used as a user command. - - As the passwords and channel keys are unfortunately passed as clear - text, any user using the IRC URL should be aware of obvious - insecurities. It is strongly discouraged to use these fields in a - public sense, such as on a website. - - Furthermore, it is recommended that client software does not - automatically initiate the connection specified by the URL without - the knowledge and consent of the user. To do so would open the - implementation up to a variety of malicious activities including, but - not limited to, the purposes of direct advertising or channel - advertising (known as "spam") via "pop-ups" or other means. - - When connecting using a secure connection ("ircs://"), user-space - ports (those above port 1023) should be treated with suspicion, as - their authority could be questionable. If a secure connection cannot - be established, the client MUST NOT automatically default to an - insecure ("irc://") connection. To do so would denigrate the "ircs" - scheme and restrict its usefulness. - - Automated messages MUST NOT be sent to any entity upon connection to - an IRC server as a direct result of execution of an IRC URL. Sending - messages to channels and other users should be left up to the user, - not the URL author or the client software. The facility to send - automated messages to other users has been explicitly avoided in this - document to avoid abuse, common with IRC. - - Clients MUST be aware of protocol limitations, especially when - dealing with entity names, as the probability for exploitation is - high. For example, a URL with a nickname including "%0D%0A" could be - used to exploit a client using using the "IRC-2" protocol, - potentially allowing a malicious URL author to execute any command - they wish. - - Beyond this, there are security concerns with regards with associated - protocols, including the IRC server-to-user protocols themselves, - [TLS] and [UTF-8], which must be taken into consideration, but are - beyond the scope of this document. - - - - - - -S. Butcher Expires July 2004 [Page 11] - -INTERNET-DRAFT URL Schemes for IRC January 2003 - - -7. IANA Considerations - - The following is registration for the URL schemes as per [RFC2717]: - - URL scheme name: Two URI's are described herein: "irc" and "ircs". - - URL scheme syntax: See Section 2.1, and indeed Section 2 as a - whole. - - Character encoding considerations: Characters must be encoded in - UTF-8 and escaped. See Section 4. - - Intended usage: The scheme initiates connection to an IRC server, - normally through the execution of IRC Client software. Further- - more, the scheme may then initiate further commands, such as - joining channels, as outlined above. - - Interoperability considerations: See Section 5. - - Security considerations: See Section 6. - - Relevant publications: The IRC protocol is defined by [RFC2812]. - Either [SSL] or [TLS] may be used for the "ircs" scheme, depending - on client and server configuration. - - Person & email address to contact for further information: The - Author; See Section 10 for details. - - Author/Change controller: The Author's details are contained - within Section 10. The IETF is to maintain change control. - - -8. Acknowledgments - - I acknowledge the previous work of Mandar Mirashi who originally - wrote an Internet-Draft to similar effect. - - The input of Petr Baudis, Robert Ginda, Piotr Kucharski, Perry - Lorier, Khaled Mardam-Bey, Dominick Meglio, James Ross, and Samuel - Sieb, was greatly appreciated, and this draft would not exist without - their valued participation. I also thank them for their patience - while I was travelling overseas. - - I would also like to acknowledge those members of the IRC development - community who encouraged me to publish this document, after more than - 18 months of pretermission. - - - - - -S. Butcher Expires July 2004 [Page 12] - -INTERNET-DRAFT URL Schemes for IRC January 2003 - - -9. References - - - [ABNF] Crocker, D., and Overell, P., "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [PICS] Miller, J., Resnick, P., Singer, D., "Rating Services and - Rating Systems (and Their Machine Readable Descriptions)", - Version 1.1, , - October 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2368] Hoffman, P., Masinter, L., Zawinski, J., "The mailto URL - scheme", RFC 2368, July 1998. - - [RFC2396] Berners-Lee, T, Fielding, T., Masinter, L., "Uniform - Resource Identifiers (URI): Generic Syntax", RFC 2396, - August 1998. - - [RFC2717] Petke, R., King, I., "Registration Procedures for URL - Scheme Names", RFC 2717, November 1999. - - [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., - "Guidelines for new URL Schemes", RFC 2718, November 1999. - - [RFC2811] Kalt, C., "Internet Relay Chat: Channel Management", RFC - 2811, April 2000. - - [RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, - April 2000. - - [SSL] Hickman, K., "The SSL Protocol", Netscape Communications - Corp., February 9, 1995. - - [TLS] Dierks, T. and Allen, C., "The TLS Protocol Version 1.0", - RFC 2246, January 1999. - - [Unicode] The Unicode Consortium. The Unicode Standard, Version - 4.0.0, (Reading, MA, Addison-Wesley, 2003. ISBN - 0-321-18578-1). - - [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", - RFC 2279, January 1998. - - - - - - -S. Butcher Expires July 2004 [Page 13] - -INTERNET-DRAFT URL Schemes for IRC January 2003 - - -10. Author's Address - - Simon Butcher - Alien Internet Services - - PO Box 7041 - Croydon South - VIC 3136 - Australia - - Phone: +61-3-9879-8052 - Fax: +61-3-9893-2793 - Email: simonb@alien.net.au - simon@butcher.name - simon@butcher.id.au - - -11. Intellectual Property Rights Notice - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementers or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - - - - - - - - - - - -S. Butcher Expires July 2004 [Page 14] - -INTERNET-DRAFT URL Schemes for IRC January 2003 - - -12. Full Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Document Discussion Forum - - Discussion for this document is currently taking place using the - "irc-url@alien.net.au" mailing list in order to keep discussion open - and archived appropriately. Those interested in this document are - strongly encouraged to join in on the discussion. - - To subscribe to the mailing list, see: - - - Archives of the mailing list are available at: - - - -Document Expiration and Filename - - Please note that this is a draft document and it shall expire July - 2004. Its filename is . - - - - -S. Butcher Expires July 2004 [Page 15] - - diff --git a/etc/draft-dawson-vcard-xml-dtd-04.pdf b/etc/draft-dawson-vcard-xml-dtd-04.pdf deleted file mode 100644 index 36d5ce7..0000000 Binary files a/etc/draft-dawson-vcard-xml-dtd-04.pdf and /dev/null differ diff --git a/etc/draft-ietf-calsch-cap-12.txt b/etc/draft-ietf-calsch-cap-12.txt deleted file mode 100644 index 625f0fe..0000000 --- a/etc/draft-ietf-calsch-cap-12.txt +++ /dev/null @@ -1,8008 +0,0 @@ - - -Calendaring and Scheduling D. Royer -Internet-Draft INET-Consulting -Expires: July 12, 2004 G. Babics - Oracle - P. Hill - Massachusetts Institute of - Technology - S. Mansour - AOL/Netscape - January 12, 2004 - - - Calendar Access Protocol (CAP) - draft-ietf-calsch-cap-12 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 12, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - The Calendar Access Protocol (CAP) is an Internet protocol described - in this memo that permits a Calendar User (CU) to utilize a Calendar - User Agent (CUA) to access an [iCAL] based Calendar Store (CS). - - The CAP definition is based on requirements identified by the - Internet Engineering Task Force (IETF) Calendaring and Scheduling - - - -Royer, et al. Expires July 12, 2004 [Page 1] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - (CALSCH) Working Group. More information about the IETF CALSCH - Working Group activities can be found on the IMC web site at http:// - www.imc.org/ietf-calendar and at the IETF web site at http:// - www.ietf.org/html.charters/calsch-charter.html [1]. Refer to the - references within this memo for further information on how to access - these various documents. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5 - 1.1 Formatting Conventions . . . . . . . . . . . . . . . . . 5 - 1.2 Related Documents . . . . . . . . . . . . . . . . . . . 6 - 1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . 7 - 2. Additions to iCalendar . . . . . . . . . . . . . . . . . 12 - 2.1 New Value Types (summary) . . . . . . . . . . . . . . . 14 - 2.1.1 New Parameters (summary) . . . . . . . . . . . . . . . . 14 - 2.1.2 New Properties (summary) . . . . . . . . . . . . . . . . 15 - 2.1.3 New Components (summary) . . . . . . . . . . . . . . . . 17 - 2.2 Relationship of RFC-2446 (ITIP) and CAP . . . . . . . . 18 - 3. CAP Design . . . . . . . . . . . . . . . . . . . . . . . 20 - 3.1 System Model . . . . . . . . . . . . . . . . . . . . . . 20 - 3.2 Calendar Store Object Model . . . . . . . . . . . . . . 20 - 3.3 Protocol Model . . . . . . . . . . . . . . . . . . . . . 21 - 3.3.1 Use of BEEP, MIME and iCalendar . . . . . . . . . . . . 22 - 4. Security Model . . . . . . . . . . . . . . . . . . . . . 24 - 4.1 Calendar User and UPNs . . . . . . . . . . . . . . . . . 24 - 4.1.1 UPNs and Certificates . . . . . . . . . . . . . . . . . 24 - 4.1.2 Anonymous Users and Authentication . . . . . . . . . . . 25 - 4.1.3 User Groups . . . . . . . . . . . . . . . . . . . . . . 25 - 4.2 Access Rights . . . . . . . . . . . . . . . . . . . . . 26 - 4.2.1 Access Control and NOCONFLICT . . . . . . . . . . . . . 26 - 4.2.2 Predefined VCARs . . . . . . . . . . . . . . . . . . . . 26 - 4.2.3 Decreed VCARs . . . . . . . . . . . . . . . . . . . . . 28 - 4.3 CAP Session Identity . . . . . . . . . . . . . . . . . . 29 - 5. CAP URL and Calendar Address . . . . . . . . . . . . . . 31 - 6. New Value Types . . . . . . . . . . . . . . . . . . . . 33 - 6.1 Property Value Data Types . . . . . . . . . . . . . . . 33 - 6.1.1 CAL-QUERY Value Type . . . . . . . . . . . . . . . . . . 33 - 6.1.2 UPN Value Type . . . . . . . . . . . . . . . . . . . . . 48 - 6.1.3 UPN-FILTER Value . . . . . . . . . . . . . . . . . . . . 49 - 7. New Parameters . . . . . . . . . . . . . . . . . . . . . 52 - 7.1 ACTION Parameter . . . . . . . . . . . . . . . . . . . . 52 - 7.2 ENABLE Parameter . . . . . . . . . . . . . . . . . . . . 52 - 7.3 ID Parameter . . . . . . . . . . . . . . . . . . . . . . 53 - 7.4 LATENCY Parameter . . . . . . . . . . . . . . . . . . . 54 - 7.5 LOCAL Parameter . . . . . . . . . . . . . . . . . . . . 55 - 7.6 LOCALIZE Parameter . . . . . . . . . . . . . . . . . . . 55 - 7.7 OPTIONS Parameter . . . . . . . . . . . . . . . . . . . 56 - - - -Royer, et al. Expires July 12, 2004 [Page 2] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - 8. New Properties . . . . . . . . . . . . . . . . . . . . . 58 - 8.1 ALLOW-CONFLICT Property . . . . . . . . . . . . . . . . 58 - 8.2 ATT-COUNTER Property . . . . . . . . . . . . . . . . . . 58 - 8.3 CALID Property . . . . . . . . . . . . . . . . . . . . . 59 - 8.4 CALMASTER Property . . . . . . . . . . . . . . . . . . . 60 - 8.5 CAP-VERSION Property . . . . . . . . . . . . . . . . . . 60 - 8.6 CARID Property . . . . . . . . . . . . . . . . . . . . . 61 - 8.7 CAR-LEVEL Property . . . . . . . . . . . . . . . . . . . 61 - 8.8 COMPONENTS Property . . . . . . . . . . . . . . . . . . 62 - 8.9 CSID Property . . . . . . . . . . . . . . . . . . . . . 64 - 8.10 DECREED Property . . . . . . . . . . . . . . . . . . . . 64 - 8.11 DEFAULT-CHARSET Property . . . . . . . . . . . . . . . . 65 - 8.12 DEFAULT-LOCALE Property . . . . . . . . . . . . . . . . 66 - 8.13 DEFAULT-TZID Property . . . . . . . . . . . . . . . . . 67 - 8.14 DEFAULT-VCARS Property . . . . . . . . . . . . . . . . . 68 - 8.15 DENY Property . . . . . . . . . . . . . . . . . . . . . 69 - 8.16 EXPAND property . . . . . . . . . . . . . . . . . . . . 69 - 8.17 GRANT Property . . . . . . . . . . . . . . . . . . . . . 70 - 8.18 ITIP-VERSION Property . . . . . . . . . . . . . . . . . 71 - 8.19 MAX-COMP-SIZE Property . . . . . . . . . . . . . . . . . 71 - 8.20 MAXDATE Property . . . . . . . . . . . . . . . . . . . . 72 - 8.21 MINDATE Property . . . . . . . . . . . . . . . . . . . . 73 - 8.22 MULTIPART Property . . . . . . . . . . . . . . . . . . . 73 - 8.23 NAME Property . . . . . . . . . . . . . . . . . . . . . 74 - 8.24 OWNER Property . . . . . . . . . . . . . . . . . . . . . 75 - 8.25 PERMISSION Property . . . . . . . . . . . . . . . . . . 75 - 8.26 QUERY property . . . . . . . . . . . . . . . . . . . . . 76 - 8.27 QUERYID property . . . . . . . . . . . . . . . . . . . . 77 - 8.28 REQUEST-STATUS property . . . . . . . . . . . . . . . . 78 - 8.29 QUERY-LEVEL Property . . . . . . . . . . . . . . . . . . 79 - 8.30 RECUR-ACCEPTED Property . . . . . . . . . . . . . . . . 79 - 8.31 RECUR-LIMIT Property . . . . . . . . . . . . . . . . . . 80 - 8.32 RECUR-EXPAND Property . . . . . . . . . . . . . . . . . 81 - 8.33 RESTRICTION Property . . . . . . . . . . . . . . . . . . 81 - 8.34 SCOPE Property . . . . . . . . . . . . . . . . . . . . . 82 - 8.35 STORES-EXPANDED Property . . . . . . . . . . . . . . . . 83 - 8.36 TARGET Property . . . . . . . . . . . . . . . . . . . . 84 - 8.37 TRANSP Property . . . . . . . . . . . . . . . . . . . . 84 - 9. New Components . . . . . . . . . . . . . . . . . . . . . 86 - 9.1 VAGENDA Component . . . . . . . . . . . . . . . . . . . 86 - 9.2 VCALSTORE Component . . . . . . . . . . . . . . . . . . 88 - 9.3 VCAR Component . . . . . . . . . . . . . . . . . . . . . 89 - 9.4 VRIGHT Component . . . . . . . . . . . . . . . . . . . . 92 - 9.5 VREPLY Component . . . . . . . . . . . . . . . . . . . . 93 - 9.6 VQUERY Component . . . . . . . . . . . . . . . . . . . . 93 - 10. Commands and Responses . . . . . . . . . . . . . . . . . 95 - 10.1 CAP Commands (CMD) . . . . . . . . . . . . . . . . . . . 95 - 10.1.1 Bounded Latency . . . . . . . . . . . . . . . . . . . . 96 - - - -Royer, et al. Expires July 12, 2004 [Page 3] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - 10.2 ABORT Command . . . . . . . . . . . . . . . . . . . . . 98 - 10.3 CONTINUE Command . . . . . . . . . . . . . . . . . . . . 99 - 10.4 CREATE Command . . . . . . . . . . . . . . . . . . . . . 100 - 10.5 DELETE Command . . . . . . . . . . . . . . . . . . . . . 105 - 10.6 GENERATE-UID Command . . . . . . . . . . . . . . . . . . 108 - 10.7 GET-CAPABILITY Command . . . . . . . . . . . . . . . . . 110 - 10.8 IDENTIFY Command . . . . . . . . . . . . . . . . . . . . 112 - 10.9 MODIFY Command . . . . . . . . . . . . . . . . . . . . . 115 - 10.10 MOVE Command . . . . . . . . . . . . . . . . . . . . . . 119 - 10.11 REPLY Response to a Command . . . . . . . . . . . . . . 121 - 10.12 SEARCH Command . . . . . . . . . . . . . . . . . . . . . 122 - 10.12.1 Searching for VFREEBUSY . . . . . . . . . . . . . . . . 125 - 10.13 SET-LOCALE Command . . . . . . . . . . . . . . . . . . . 126 - 10.14 TIMEOUT Command . . . . . . . . . . . . . . . . . . . . 127 - 10.15 Response Codes . . . . . . . . . . . . . . . . . . . . . 128 - 11. Object Registration . . . . . . . . . . . . . . . . . . 131 - 11.1 Registration of New and Modified Entities . . . . . . . 131 - 11.2 Post the item definition . . . . . . . . . . . . . . . . 131 - 11.3 Allow a comment period . . . . . . . . . . . . . . . . . 131 - 11.4 Release a new RFC . . . . . . . . . . . . . . . . . . . 131 - 12. BEEP and CAP . . . . . . . . . . . . . . . . . . . . . . 132 - 12.1 BEEP Profile Registration . . . . . . . . . . . . . . . 132 - 12.2 BEEP Exchange Styles . . . . . . . . . . . . . . . . . . 134 - 13. IANA Considerations . . . . . . . . . . . . . . . . . . 135 - 14. Security Considerations . . . . . . . . . . . . . . . . 136 - Authors' Addresses . . . . . . . . . . . . . . . . . . . 137 - A. Acknowledgments . . . . . . . . . . . . . . . . . . . . 139 - B. Bibliography . . . . . . . . . . . . . . . . . . . . . . 140 - Intellectual Property and Copyright Statements . . . . . 142 - - - - - - - - - - - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 4] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -1. Introduction - - This document specifies how a Calendar CUA interacts with a CS to - manage calendar information. In particular, it specifies how to - query, create, modify, and delete iCalendar components (e.g., events, - to-dos, or daily journal entries). It further specifies how to search - for available busy time information. Synchronization with CUAs is not - covered and believed to be possible using CAP. - - CAP is specified as a [BEEP] "profile". As such, many aspects of the - protocol (e.g., authentication and privacy) are provided within - [BEEP]. The protocol data units leverage the standard iCalendar - format [iCAL] to convey calendar related information. - - CAP can also be used to store and fetch [iTIP] objects and when those - objects are used in this memo, they mean exactly the same as defined - in [iTIP]. When iCalendar objects are transferred between the CUA and - a CS, some additional properties and parameters may be added and the - CUA is responsible for correctly generating iCalendar objects to non - CAP processes. - - The definition of new components, properties, parameter's, and value - types are broken into two parts. The first part summarizes and - defines the new objects. The second part provides the detail and any - ABNF for those objects. The ABNF in CAP as in other iCalendar - specifications is order independent. That is properties in a - component may occur in any order and parameters in any property may - occur in any order. - -1.1 Formatting Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this - document are to be interpreted as described in [RFCWORDS]. - - Calendaring and scheduling roles are referred to in quoted-strings of - text with the first character of each word in upper case. For - example, "Organizer" refers to a role of a "Calendar User" (CU) - within the protocol defined by [iTIP]. Calendar components defined by - [iCAL] are referred to with capitalized, quoted-strings of text. All - iCalendar components should start with the letter "V". For example, - "VEVENT" refers to the event calendar component, "VTODO" refers to - the to-do component and "VJOURNAL" refers to the daily journal - component. - - Scheduling methods defined by [iTIP], are referred to with - capitalized, quoted-strings of text. For example, "REPLY" refers to - the method for replying to a "REQUEST". - - - -Royer, et al. Expires July 12, 2004 [Page 5] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - CAP commands are referred to by upper-case, quoted-strings of text, - followed by the word "command". For example, "CREATE" command refers - to the command for creating a calendar entry, "SEARCH" command refers - to the command for reading calendar components. CAP Commands are - named using the "CMD" property. - - Properties defined by this memo are referred to with capitalized, - quoted-strings of text, followed by the word "property". For example, - "ATTENDEE" property refers to the iCalendar property used to convey - the calendar address that has been invited to a "VEVENT" or "VTODO" - component. - - Property parameters defined by this memo are referred to with - capitalized, quoted-strings of text, followed by the word - "parameter". For example, "PARTSTAT" parameter refers to the - iCalendar property parameter used to specify the participation status - of an attendee. Enumerated values defined by this memo are referred - to with capitalized text, either alone or followed by the word - "value". - - Object states defined by this memo are referred to with capitalized, - quoted-strings of text, followed by the word "state". For example, - "BOOKED" state refers to an object in the booked state. - - Within a query, the different parts are referred to as a "clause" and - its value as "clause value" and the clause name will be in uppercase - enclosed in quotes. Example, The "SELECT" clause or if the "SELECT" - clause value contains ... - - In tables, the quoted-string text is specified without quotes in - order to minimize the table length. - -1.2 Related Documents - - Implementers will need to be familiar with several other memos that, - along with this one, describe the Internet calendaring and scheduling - standards. These documents are: - - [iCAL] - (RFC2445) Which specifies the objects, data types, - properties and property parameters used in the protocols, along - with the methods for representing and encoding them. - - [iTIP] - (RFC2446) Which specifies an interoperability protocol for - scheduling between different installations. - - [iMIP] - (RFC2447) Which specifies the Internet email binding for - [iTIP]. - - - - -Royer, et al. Expires July 12, 2004 [Page 6] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - [GUIDE] - (RFC3283), a guide to implementers and describes the - elements of a calendaring system, how they interact with each - other, how they interact with end users, and how the standards and - protocols are used. - - This memo does not attempt to repeat the specification of concepts - and definitions from these other memos. Where possible, references - are made to the memo that provides for the specification of these - concepts and definitions. - -1.3 Definitions - - BOOKED - An object in the calendar store has one of three conceptual - states. It is in the "UNPROCESSED" state, "BOOKED" state, or - marked for deletion which is the "DELETED" state. How the - implementation stores the state of any object is not a protocol - issues and is not discussed. An object can be said to be booked, - unprocessed, or marked for delete. - - - - 1. An "UNPROCESSED" state scheduling object has been stored in - the calendar store but has not been acted on by a CU or CUA. - All scheduled entries are [iTIP] objects. All [iTIP] objects - in the store are not in the "BOOKED" state. To retrieve any - [iTIP] object, simply do a query asking for any objects that - are stored in the "UNPROCESSED" state. - - 2. A "BOOKED" state entry is stored with the "CREATE" command. It - is an object that has been acted on by a CU or CUA and there - has been a decision to store an object. To retrieve any booked - object, simply do a query asking for any objects that were - stored in the "BOOKED" state. - - 3. A "DELETED" state entry is created by sending a "DELETE" - command with the "OPTION" parameter value set to "MARK". To - retrieve any deleted object, simply do a query asking for any - objects that were stored in the "DELETED" state. By default - objects marked for delete are not returned. The CUA must - specifically ask for marked for delete objects. You can not - ask for components in the "DELETED" state and in other states - in the same "VQUERY" component, as there would be no way to - distinguish between them in the reply. - - Calendar - A collection of logically related objects or entities - each of which may be associated with a calendar date and possibly - time of day. These entities can include calendar properties or - components. In addition, a calendar might be related to other - - - -Royer, et al. Expires July 12, 2004 [Page 7] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - calendars with the "RELATED-TO" property. A calendar is identified - by its unique calendar identifier. The [iCAL] defines the initial - calendar properties, calendar components and properties that make - up the contents of a calendar. - - Calendar Access Protocol (CAP) - The standard Internet protocol that - permits a CUA to access and manipulate calendars residing on a - Calendar Store. (this memo) - - Calendar Access Rights (VCAR) - The mechanism for specifying the CAP - operations ("PERMISSION") that a particular calendar user ("UPN") - is granted or denied permission to perform on a given calendar - object ("SCOPE"). The calendar access rights are specified with a - "VCAR" component. (Section 9.3.) - - Calendar Address - Also See Calendar URL - they are one in the same - for CAP addresses. The calendar address can also be the value to - the "ATTENDEE" and "ORGANIZER" properties as defined in [iCAL]. - - Calendar URL - A calendar URL is a URL defined in this memo that - specifies the address of a CS or Calendar. - - Component- Any object that conforms to the iCalendar object format - and that is either defined in an internet draft, registered with - IANA, or is an experimental object that is prefixed with "x-". - Some types of components include calendars, events, to-dos, - journals, alarms, and time zones. A component consists of - properties and possibly other contained components. For example, - an event may contain an alarm component. - - Container - This is a generic name for VCALSTORE or VAGENDA. - - Properties - An attribute of a particular component. Some properties - are applicable to different types of components. For example, the - "DTSTART" property is applicable to the "VEVENT", "VTODO", and - "VJOURNAL" components. Other components are applicable only to an - individual type of calendar component. For example, the "TZURL" - property may only be applicable to the "VTIMEZONE" components. - - Calendar Identifier (CALID) - A globally unique identifier - associated with a calendar. Calendars reside within a CS. See - Qualified Calendar Identifier and Relative Calendar Identifier. - All CALIDs start with "cap:". - - Calendar Policy - A CAP operational restriction on the access or - manipulation of a calendar. These may be outside of the scope of - the CAP protocol. An example of an implementation or site policy - is, "events MUST BE scheduled in unit intervals of one hour". - - - -Royer, et al. Expires July 12, 2004 [Page 8] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Calendar Property - An attribute of a calendar ("VAGENDA"). The - attribute applies to the calendar, as a whole. For example, the - "CALSCALE" property specifies the calendar scale (e.g., the - "GREGORIAN" value) for the all entries within the calendar. - - Calendar Store (CS) - The data and service model definition for a - Calendar Store as defined in this memo. This memo does not specify - how the CS is implemented. - - Calendar Server - An implementation of a Calendar Store (CS) that - manages one or more calendars. - - Calendar Store Identifier (CSID) - The globally unique identifier - for an individual CS. A CSID consists of the host and port - portions of a "Common Internet Scheme Syntax" part of a URL, as - defined by [URL]. The CSID excludes any reference to a specific - calendar. (Section 8.9) - - Calendar Store Components - Components maintained in a CS specify a - grouping of calendar store-wide information. - - Calendar Store Properties - Properties maintained in a Calendar - Store calendar store-wide information. - - Calendar User (CU) - An entity (often biological) that uses a - calendaring system. - - Calendar User Agent (CUA) - The client application that a CU - utilizes to access and manipulate a calendar. - - CAP Session - An open communication channel between a CUA and a CS. - If the CAP session is authenticated, the CU is "authenticated" and - it is an "authenticated CAP session". - - Contained Component / Contained Properties - A component or property - that is contained inside of another component. A "VALARM" - component for example may be contained inside of a "VEVENT" - component. And a "TRIGGER" property could be a contained property - of a "VALARM" component. - - Delegate - A CU (sometimes called the delegatee) who has been - assigned participation in a scheduled component (e.g., VEVENT) by - one of the attendees in the scheduled component (sometimes called - the delegator). An example of a delegate is a team member told to - go to a particular meeting in place of another Attendee who is - unable to attend. - - - - - -Royer, et al. Expires July 12, 2004 [Page 9] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Designate - A CU who is authorized to act on behalf of another CU. - An example of a designate is an assistant. - - Experimental - The CUA and CS may implement experimental extensions - to the protocol. They also might have experimental components, - properties, and parameters. These extensions MUST start with "x-" - (or "X-") and should include a vendor prefix (such as - "x-myvendor-"). There is no guarantee that these experimental - extensions will interoperate with other implementations. There is - no guarantee that they will not interact in unpredictable ways - with other vendor experimental extensions. There is no guarantee - that the same specific experimental extension is not used my - multiple vendors in incompatible ways. Implementations should - limit sending those extensions to other implementations. - - Object - A generic name for any component, property, parameter, or - value type to be used in iCalendar. - - Overlapped Booking - A policy which indicates whether or not - components with a "TRANSP" property not set to - "TRANSPARENT-NOCONFLICT" or "OPAQUE-NOCONFLICT" value can overlap - one another. When the policy is applied to a calendar it indicates - whether or not the time span of any component (VEVENT, VTODO, ...) - in the calendar can overlap the time span of any other component - in the same calendar. When applied to an individual object, it - indicates whether or not any other component's time span can - overlap that individual component. If the CS does not allow - overlapped booking, then the CS is unwilling to allow any - overlapped bookings within any calendar or entry in the CS. - - Owner - One or more CUs or UGs that are listed in the "OWNER" - property in a calendar. There can be more than one owner. - - Qualified Calendar Identifier (Qualified CALID) - A CALID in which - both the scheme and CSID of the CAP URI are present. - - Realm - A collection of calendar user accounts, identified by a - string. The name of the Realm is only used in UPNs. In order to - avoid namespace conflict, the Realm SHOULD be postfixed with an - appropriate DNS domain name. (e.g., the foobar Realm could be - called foobar.example.com). - - Relative Calendar Identifier (Relative CALID) - An identifier for an - individual calendar in a calendar store. It MUST BE unique within - a calendar store. A Relative CALID consists of the "URL path" of - the "Common Internet Scheme Syntax" portion of a URL, as defined - by [URI] and [URLGUIDE]. - - - - -Royer, et al. Expires July 12, 2004 [Page 10] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Session Identity - A UPN associated with a CAP session. A session - gains an identity after successful authentication. The identity is - used in combination with VCAR to determine access to data in the - CS. - - User Group (UG) - A collection of Calendar Users and/or User Groups. - These groups are expanded by the CS and may reside either locally - or in an external database or directory. The group membership may - be fixed or dynamic over time. - - Username - A name which denotes a Calendar User within a Realm. This - is part of a UPN. - - User Principal Name (UPN) - A unique identifier that denotes a CU or - a group of CU. (Section 6.1.2) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 11] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -2. Additions to iCalendar - - Several new components, properties, parameters, and value types are - added in CAP. This section summarizes those new objects. - - This memo extends the properties that can go into 'calprops' as - defined in [iCAL] section 4.6 page 51 to allow [iTIP] objects - transmitted between a CAP aware CUA and the CS to contain the - "TARGET" and "CMD" properties. This memo also adds to the [iCAL] ABNF - to allow IANA and experimental extensions. This memo does not address - how a CUA transmits [iTIP] or [iMIP] objects to non CAP programs. - - - calprops = 2*( - - ; 'prodid' and 'version' are both REQUIRED, - ; but MUST NOT occur more than once. - ; - prodid /version / - - ; These are optional, but MUST NOT occur - ; more than once. - ; - calscale / - method / - cmd / - - ; Target is optional, and may occur more - ; than once. - ; - target / other-props ) - - other-props = *(x-prop) *(iana-prop) *(other-props) - - iana-prop = ; Any property registered by IANA directly or - ; included in an RFC that may be applied to - ; the component and within the rules published. - - x-prop = ; As defined in [iCAL] - - - Another change is that the 'component' part of the 'icalbody' ABNF as - described in [iCAL] section 4.6 is optional when sending a command as - shown in the following updated ABNF: - - icalbody = calprops component - - ; If the "VCALENDAR" component contains the "CMD" - - - -Royer, et al. Expires July 12, 2004 [Page 12] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - ; property then the 'component' is optional: - ; - / calprops ; Which MUST include a "CMD" property - - - In addition a problem exists with the control of "VALARM" components - and their "TRIGGER" properties. A CU may wish to set their own alarm - (local alarms) on components. These local alarms are not to be - forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property - and the "ENABLE" parameter. So for the protocol between a CUA and a - CS, the following changes apply to the CAP protocol from [iCAL] - section 4.6.6 page 67: - - - alarmc = "BEGIN" ":" "VALARM" CRLF - alarm-seq - other-props - (audioprop / dispprop / emailprop / procprop) - "END" ":" "VALARM" CRLF - - alarm-seq = "SEQUENCE" alarmseqparams ":" posint0 CRLF - - alarmseqparams = other-params [";" local-param] other-params - - ; Where DIGIT is defined in [iCAL] - ; - posint0 = 1*DIGIT - posint1 = posintfirst 1*DIGIT - - ; A number starting with 1 through 9. - ; - posintfirst = %x31-39 - - other-params = *(";" xparam) *(";" iana-params) *(";" other-param) - - iana-params = ; Any parameter registered by IANA directly or - ; included in an RFC that may be applied to - ; the property and within the rules published. - - xparam ; As defined in [iCAL] - - - The CUA adds a "SEQUENCE" property to each "VALARM" component as it - books the component. This property along with the "LOCAL" and - "ENABLE" parameters allow the CUA to uniquely identify any VALARM in - any component. The CUA should remove those before forwarding to non - CAP aware CUAs. - - - - -Royer, et al. Expires July 12, 2004 [Page 13] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - In addition, if a CUA wished to ignore a "TRIGGER" property in a - "VALARM" component that was supplied to it by the "Organizer", the - CUA needs a common way to tag that trigger as disabled. So the - following is a modification to [iCAL] section 4.8.6.3 page 127: - - - trigger = "TRIGGER" 1*(";" enable-param) (trigrel / trigabs) - - - Section 7.2 and Section 7.5. - -2.1 New Value Types (summary) - - UPN The UPN value type is text value type restricted to only UPN - values. (Section 6.1.2) - - UPN-FILTER Like the UPN value type, but also includes filter rules - that allow wildcards. (Section 6.1.3) - - CALQUERY The "CAL-QUERY" value type is a query syntax that is used by - the CUA to specify the rules that apply to a CAP command. (Section - 6.1.1) - - -2.1.1 New Parameters (summary) - - ACTION - The "ACTION" parameter informs the endpoint if it should - abort or ask to continue on timeout. (Section 7.1). - - ENABLE - The "ENABLE" parameter in CAP is used to tag a property in - a component as disabled or enabled. (Section 7.2). - - ID - The "ID" parameter specifies a unique identifier to be used for - any outstanding commands. - - LATENCY - The "LATENCY" parameter supplies the timeout value for - command completion to the other endpoint. (Section 7.4). - - LOCAL - The "LOCAL" parameter in CAP is used to tag a property in a - component to signify that the component is local or to be - distributed. (Section 7.5). - - LOCALIZE - The "LOCALIZE" parameter specifies the locale to be used - in error and warning messages. - - OPTIONS - The "OPTIONS" parameter passes optional information for - the command being sent. - - - - -Royer, et al. Expires July 12, 2004 [Page 14] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -2.1.2 New Properties (summary) - - ALLOW-CONFLICT - Some entries in a calendar might not be valid if - other entries were allowed to overlap the same time span. (Section - 8.1) - - ATT-COUNTER - When storing a "METHOD" property with the "COUNTER" - method, there needs to be a way to remember the "ATTENDEE" value - that sent the COUNTER. (Section 8.2) - - CAP-VERSION - The version of CAP the implementation supports. - (Section 8.5) - - CAR-LEVEL - The level of calendar access level supported. (Section - 8.7) - - COMPONENTS - The list of components supported. (Section 8.8) - - CSID - The Calendar Store IDentifier (CSID) uniquely identifies a - CAP server. (Section 8.9) - - CALID - Each calendar within a CS needs to be uniquely identifiable. - The "CALID" property identifies a unique calendar within a CS. It - can be a full CALID or a relative CALID. (Section 8.3) - - CALMASTER - The "CALMASTER" property specifies the contact - information for the CS. (Section 8.4) - - CARID - Access rights can be saved and fetched by unique ID - the - "CARID" property. (Section 8.6) - - CMD - The CAP commands, as well as replies are transmitted using the - "CMD" property. (Section 10.1) - - DECREED - Some access rights are not changeable by the CUA. When - that is the case, the "DECREED" property value in the "VCAR" - component will be TRUE. (Section 8.10) - - DEFAULT-CHARSET - The list of charsets supported by the CS. The - first entry is the default for the CS. (Section 8.11) - - DEFAULT-LOCALE - The list of locales supported by the CS. The first - entry in the list is the default locale. (Section 8.12) - - DEFAULT-TZID - This is the list of known timezones supported. The - first entry is the default. (Section 8.13) - - - - - -Royer, et al. Expires July 12, 2004 [Page 15] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - DEFAULT-VCARS - A list of the "CARID" properties that will be used - to create new calendars. (Section 8.14) - - DENY - The UPNs listed in the "DENY" property of a "VCAR" component - will denied access as described in the "VRIGHT" component. - (Section 8.15) - - EXPAND - This property tells the CS if the query reply should expand - components into multiple instances. The default is FALSE and is - ignored for CSs that can not expand recurrence rules. (Section - 8.16) - - GRANT - The UPNs listed in the "GRANT" property of a "VCAR" - component will allowed access as described in the "VRIGHT" - component. (Section 8.17) - - ITIP-VERSION - The version of [iTIP] supported. (Section 8.18) - - MAXDATE - The maximum date supported by the CS. (Section 8.20) - - MAX-COMP-SIZE - The largest component size allowed in the - implementation including attachments in octets. (Section 8.19) - - MINDATE - The minimum date supported by the CS. (Section 8.21) - - MULTIPART - Passed in the capability messages to indicate which MIME - multipart types the sender supports. (Section 8.22) - - NAME - The "NAME" property is used to add locale specific - descriptions into components. (Section 8.23) - - OWNER - Each calendar has at least one "OWNER" property. (xref - target="OWNER"/>) Related to the "CAL-OWNERS()" (Section 6.1.1.1) - query clause. - - PERMISSION - This property specifies the permission being granted or - denied. Examples are the "SEARCH" and "MODIFY" values. (Section - 8.25) - - QUERY - Used to hold the CAL-QUERY (Section 8.26) for the component. - - QUERYID - A unique id for a stored query. (Section 8.27) - - QUERY-LEVEL - The level of the query language supported. (Section - 8.29) - - - - - - -Royer, et al. Expires July 12, 2004 [Page 16] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - RECUR-ACCEPTED - If the implementation support recurrence rules. - (Section 8.30) - - RECUR-EXPAND - If the implementation support expanding recurrence - rules. (Section 8.32) - - RECUR-LIMIT - Any maximum limit on the number of instances the - implementation will expand recurring objects. (Section 8.31) - - REQUEST-STATUS - The [iCAL] "REQUEST-STATUS" property is extended to - include new error numbers. (Section 8.28) - - RESTRICTION - In the final check when granting calendar access - requests, the CS test the results to the value of the - "RESTRICTION" property in the corresponding "VRIGHT" component to - determine if the access meets that restriction. (Section 8.33) - - SCOPE - The "SCOPE" property is used in "VRIGHT"s component to - select the subset of data that may be acted upon when checking - access rights. (Section 8.34) - - SEQUENCE - When the "SEQUENCE" property is used in a "VALARM" - component it uniquely identifies the instances of the "VALARM" - within that component. - - STORES-EXPANDED - Specifies if the implementation stores recurring - object expanded or not. (Section 8.35) - - TARGET - The new "VCALENDAR" component property "TARGET" (Section - 8.36) is used to specify which calendar(s) will be the subject of - the CAP command. - - TRANSP - This is a modification the [iCAL] "TRANSP" property and it - allows more values. The new values are related to conflict - control. (Section 8.37) - - -2.1.3 New Components (summary) - - VAGENDA - CAP allows the fetching and storing of the entire contents - of a calendar. The "VCALENDAR" component is not sufficient to - encapsulate all of the needed data that describes a calendar. The - "VAGENDA" component is the encapsulating object for an entire - calendar. (Section 9.1) - - VCALSTORE - Each CS contains one or more calendars (VAGENDAs), the - "VCALSTORE" component is the encapsulating object that can hold - all of the "VAGENDA" components along with any components and - - - -Royer, et al. Expires July 12, 2004 [Page 17] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - properties that are unique to the store level. (Section 9.2) - - VCAR - Calendar Access Rights are specified and encapsulated in the - new iCalendar "VCAR" component. The "VCAR" component holds some - new properties and at least one "VRIGHT" component. (Section 9.3) - - VRIGHT - This component encapsulates a set of instructions to the CS - that define the rights or restrictions needed. (Section 9.4) - - VREPLY - This component encapsulates a set of data that can consist - of an arbitrary amounts of properties and components. Its contents - is dependent on the command that was issued. (Section 9.5) - - VQUERY - The search operation makes use of a new component, called - "VQUERY" and a new value type "CAL-QUERY" (Section 6.1.1). The - "VQUERY" component is used to fetch objects from the CS. (Section - 9.6) - - -2.2 Relationship of RFC-2446 (ITIP) and CAP - - [iTIP] describes scheduling methods which result in indirect - manipulation of components. In CAP, the "CREATE" command is used to - deposit entities into the store. Other CAP commands such as "DELETE", - "MODIFY" and "MOVE" command values provide direct manipulation of - components. In the CAP calendar store model, scheduling messages are - conceptually kept separate from other components by their state. - - All scheduling operations are as defined in [iTIP]. This memo makes - no changes to any of the methods or procedures described in [iTIP]. - In this memo referring to the presence of the "METHOD" property in an - object is the same as saying an [iTIP] object. - - A CUA may create a "BOOKED" state object by depositing an iCalendar - object into the store. This is done by depositing an object that does - not have a "METHOD" property. The CS then knows to set the state of - the object to the "BOOKED" state. If the object has a "METHOD" - property then the object is stored in the "UNPROCESSED" state. - - If existing "UNPROCESSED" state objects exist in the CS for the same - UID then a CUA may wish to consolidate the objects in to one "BOOKED" - state object. The CUA would fetch the "UNPROCESSED" state objects for - that UID and process them in the CUA as described in [iTIP]. Then if - the CUA wished to book the UID, the CUA would issue a "CREATE" - command to create the new "BOOKED" state object in the CS, followed - by a "DELETE" command to remove any related old [iTIP] objects from - the CS. And it might also involve having the CUA send some [iMIP] - objects or contacting other CSs and performing CAP operations on - - - -Royer, et al. Expires July 12, 2004 [Page 18] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - those CSs. - - The CUA could also decide not to book the object. In which case the - "UNPROCESSED" state objects could be removed from the CS or the CUA - could set those object to the marked for delete state. The CUA could - also ignore objects for later processing. - - The marked for delete state is used to keep the object around so that - the CUA can process duplicate requests automatically. If a duplicate - [iTIP] object is deposited into the CS and there exists identical - marked for delete objects, then a CUA acting on behalf of the "OWNER" - can silently drop those duplicate entries. - - Another purpose for the marked for delete state is so that when a CU - decides they do not wish to have the object show in their calendar, - the CUA can book the object; changing the "PARTSTAT" parameter to - "DECLINED" in the "ATTENDEE" property that corresponds to their UPN. - Then perform an [iTIP] processing such as sending back a decline. - Then mark that object as marked for delete. Their CUA might be - configurable to automatically drop any updates for that object - knowing the CU has already declined. - - When synchronizing with multiple CUAs, the marked for delete state - could be used to inform the synchronization process that an object is - to be deleted. How synchronization is done is not specified in this - memo. - - Several "UNPROCESSED" state entries can be in the CS for the same - UID. However once consolidated, then only one object exists in the CS - and that is the booked object. The others MUST BE removed, or have - their state changed to "DELETED". - - There MUST NOT BE more than one "BOOKED" state object in a calendar - for the same "UID". The "ADD" method value may create multiple - objects all in the "BOOKED" state for the same UID, however for the - purpose of this memo, they are the same object that simply have - multiple "VCALENDAR" components. - - For example, if you were on vacation, you could have received a - "REQUEST" method to attend a meeting and several updates to that - meeting. Your CUA would have to issue "SEARCH" commands to find them - in the CS using CAP, process them, determine what the final state of - the object from a possible combination of user input and programmed - logic. Then the CUA would instruct the CS to create a new booked - object from the consolidated results. Finally, the CUA could do a - "DELETE" command to remove the related "UNPROCESSED" state objects. - See [iTIP] for details on resolving multiple [iTIP] scheduling - entries. - - - -Royer, et al. Expires July 12, 2004 [Page 19] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -3. CAP Design - -3.1 System Model - - The system model describes the high level components of a calendar - system and how they interact with each other. - - CAP is used by a CUA to send commands to and receive responses from a - CS. - - The CUA prepares a [MIME] encapsulated command, sends it to the CS, - and receives a [MIME] encapsulated response. The calendaring related - information within these messages are represented by iCalendar - objects. In addition the "GET-CAPABILITY" command can be sent from - the CS to the CUA. - - There are two distinct protocols in operation to accomplish this - exchange. [BEEP] is the transport protocol used to move these - encapsulations between a CUA and a CS. CAP's [BEEP] profile defines - the application protocol where the content and semantics of the - messages sent between the CUA and the CS are specified. - -3.2 Calendar Store Object Model - - [iCAL] describes components such as events, todos, alarms, and - timezones. [CAP] requires additional object infrastructure. In - particular, detailed definitions of the containers for events and - todos (calendars), access control objects, and a query language. - - The conceptual model for a calendar store is shown below. The - calendar store (VCALSTORE - Section 9.2) contains "VCAR"s, "VQUERY"s, - "VTIMEZONE"s, "VAGENDA"s and calendar store properties. - - Calendars (VAGENDAs) contain "VEVENT"s, "VTODO"s, "VJOURNAL"s, - "VCAR"s, "VTIMEZONE"s, "VFREEBUSY", "VQUERY"s and calendar - properties. - - The component "VCALSTORE" is used to denote the a root of the - calendar store and contains all of the calendars. - - - Calendar Store - - VCALSTORE - | - +-- properties - +-- VCARs - +-- VQUERYs - - - -Royer, et al. Expires July 12, 2004 [Page 20] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - +-- VTIMEZONEs - +-- VAGENDA - | | - | +--properties - | +--VEVENTs - | | | - | | +--VALARMs - | +--VTODOs - | | | - | | +--VALARMs - | +--VJOURNALs - | +--VCARs - | +--VTIMEZONEs - | +--VQUERYs - | +--VFREEBUSYs - | | - | | ... - . - . - +-- VAGENDA - . . - . . - . . - - - Calendars within a Calendar Store are identified by their unique - Relative CALID. - -3.3 Protocol Model - - CAP uses [BEEP] as the transport and authentication protocol. - - The initial charset MUST BE UTF-8 for the session in an unknown - locale. If the CS supplied the [BEEP] 'localize' attribute in the - [BEEP] 'greeting' then the CUA may tell the CS to switch locales for - the session by issuing the "SET-LOCALE" CAP command and supplying one - of the locales supplied by the [BEEP] 'localize' attribute. If - supplied the first locale in the [BEEP] 'localize' attribute is the - default locale of the CS. The locale is switched only after a - successful reply. - - The "DEFAULT-CHARSET" property of the CS contains the list of - charsets supported by the CS with the first value being the default - for new calendars. If the CUA wishes to switch to one of those - charsets for the session, the CUA issues the "SET-LOCALE" command. - The CUA would have to first perform a "GET-CAPABILITY" command on the - CS to get the list of charsets supported by the CS. The charset is - switched only after a successful reply. - - - -Royer, et al. Expires July 12, 2004 [Page 21] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - The CUA may switch locales and charsets as needed. There is no - requirement that a CS support multiple locales or charsets. - -3.3.1 Use of BEEP, MIME and iCalendar - - CAP uses the [BEEP] application protocol over TCP. (refer to [BEEP] - and [BEEPTCP] for more information). The default port that the CS - listens for connections is on user port 1026. - - The [BEEP] data exchanged in CAP is a iCalendar MIME content that - fully conforms to [iCAL] iCalendar format. - - This example tells the CS to generate and return 10 UIDs to be used - by the CUA. Note throughout this memo, 'C:' refers to what the CUA - sends, 'S:' refers to what the CS sends, 'I:' refers to what the - initiator sends, and 'L:' refers to what the listener sends. Where - initiator and listener are used as defined in [BEEP]. - - - C: MSG 1 2 . 432 62 - C: Content-Type: text/calendar - C: - C: BEGIN:VCALENDAR - C: VERSION:2.0 - C: PRODID:-//someone's prodid - C: CMD;ID=unique-per-cua-123;OPTIONS=10:GENERATE-UID - C: END:VCALENDAR - - - NOTE: The following examples will not include the [BEEP] header and - footer information. Only the iCalendar objects that are sent between - the CUA and CS will be shown as the [BEEP] payload boundaries are - independent of CAP. - - The commands listed below are used to manipulate or access the data - on the calendar store: - - ABORT - Sent to halt the processing of some of the commands. - (Section 10.2) - - CONTINUE - Sent to continue processing a command that has had its - specified timeout time reached. (Section 10.3) - - CREATE - Create a new object on the CS. Initiated by the CUA only. - (Section 10.4) - - - - - - -Royer, et al. Expires July 12, 2004 [Page 22] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - SET-LOCALE - Tell the CS to use any named locale and charset - supplied. Initiated by the CUA only. (Section 10.13) - - DELETE - Delete objects from the CS. Initiated by the CUA only. Can - also be used to mark an object for deletion. (Section 10.5) - - GENERATE-UID - Generate one or more unique ids. Initiated by the CUA - only. (Section 10.6) - - GET-CAPABILITY - Query the capabilities the other end point of the - session. (Section 10.7) - - IDENTIFY - Set a new identity for the session. Initiated by the CUA - only. (Section 10.8) - - MODIFY - Modify components. Initiated by the CUA only. (Section - 10.9) - - MOVE - Move components to another container. Initiated by the CUA - only. (Section 10.10) - - REPLY - When replying to a command, the "CMD" value will be set to - "REPLY" so that it will not be confused with a new command. - (Section 10.11) - - SEARCH - Search for components. Initiated by the CUA only. (Section - 10.12) - - TIMEOUT - Sent when a specified amount of time has lapsed and a - command has not finished. (Section 10.14) - - - - - - - - - - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 23] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -4. Security Model - - The [BEEP] transport performs all session authentication. - -4.1 Calendar User and UPNs - - A CU is an entity that can be authenticated. It is represented in CAP - as a UPN, which is a key part of access rights. The UPN - representation is independent of the authentication mechanism used - during a particular CUA/CS interaction. This is because UPNs are used - within VCARs. If the UPN were dependent on the authentication - mechanism, a VCAR could not be consistently evaluated. A CU may use - one mechanism while using one CUA but the same CU may use a different - authentication mechanism when using a different CUA, or while - connecting from a different location. - - The user may also have multiple UPNs for various purposes. - - Note that the immutability of the user's UPN may be achieved by using - SASL's authorization identity feature. (The transmitted authorization - identity may be different than the identity in the client's - authentication credentials.) [SASL, section 3]. This also permits a - CU to authenticate using their own credentials, yet request the - access privileges of the identity for which they are proxying SASL. - Also, the form of authentication identity supplied by a service like - TLS may not correspond to the UPNs used to express a server's access - rights, requiring a server specific mapping to be done. The method by - which a server determines a UPN, based on the authentication - credentials supplied by a client, is implementation specific. See - [BEEP] for authentication details; [BEEP] relies on SASL. - -4.1.1 UPNs and Certificates - - When using X.509 certificates for purposes of CAP authentication, the - UPN should appear in the certificate. Unfortunately there is no - single correct guideline for which field should contain the UPN. - - From RFC-2459, section 4.1.2.6 (Subject): - - If subject naming information is present only in the - subjectAlt-Name extension (e.g., a key bound only to an email - address or URI), then the subject name MUST be an empty sequence - and the subjectAltName extension MUST BE critical. - - Implementations of this specification MAY use these comparison - rules to process unfamiliar attribute types (i.e., for name - chaining). This allows implementations to process certificates - with unfamiliar attributes in the subject name. - - - -Royer, et al. Expires July 12, 2004 [Page 24] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - In addition, legacy implementations exist where an RFC 2822 name - is embedded in the subject distinguished name as an EmailAddress - attribute. The attribute value for EmailAddress is of type - IA5String to permit inclusion of the character '@', which is not - part of the PrintableString character set. EmailAddress attribute - values are not case sensitive (e.g., "fanfeedback@redsox.com" is - the same as "FANFEEDBACK@REDSOX.COM"). - - Conforming implementations generating new certificates with - electronic mail addresses MUST use the rfc822Name in the subject - alternative name field (see sec. 4.2.1.7 of [X509CRL]) to describe - such identities. Simultaneous inclusion of the EmailAddress - attribute in the subject distinguished name to support legacy - implementations is deprecated but permitted. - - Since no single method of including the UPN in the certificate will - work in all cases, CAP implementations MUST support the ability to - configure what the mapping will be by the CS administrator. - Implementations MAY support multiple mapping definitions, for - example, the UPN may be found in either the subject alternative name - field, or the UPN may be embedded in the subject distinguished name - as an EmailAddress attribute. - - Note: If a CS or CUA is validating data received via [iMIP], if the - "ORGANIZER" or "ATTENDEE" properties said (e.g.) "ATTENDEE;CN=Joe - Random User:MAILTO:juser@example.com" then the email address should - be checked against the UPN. This is so the "ATTENDEE" property cannot - be changed to something misleading like "ATTENDEE;CN=Joe Rictus - User:MAILTO:jrictus@example.com" and have it pass validation. Note - that it is the email addresses that miscompare, the CN miscompare is - irrelevant. - -4.1.2 Anonymous Users and Authentication - - Anonymous access is often desirable. For example an organization may - publish calendar information that does not require any access control - for viewing or login. Conversely, a user may wish to view - unrestricted calendar information without revealing their identity. - -4.1.3 User Groups - - A User Group is used to represent a collection of CUs or other UGs - that can be referenced in VCARs. A UG is represented in CAP as a UPN. - The CUA cannot distinguish between a UPN that represents a CU or a - UG. - - UGs are expanded as necessary by the CS. The CS MAY expand a UG - (including nested UGs) to obtain a list of unique CUs. Duplicate UPNs - - - -Royer, et al. Expires July 12, 2004 [Page 25] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - are filtered during expansion. - - How the UG expansion is maintained across commands is implementation - specific. A UG may reference a static list of members, or it may - represent a dynamic list. Operations SHOULD recognize changes to UG - membership. - - CAP does not define commands or methods for managing UGs. - -4.2 Access Rights - - Access rights are used to grant or deny access to calendars, - components, properties, and parameters in a CS to a CU. CAP defines a - new component type called a Calendar Access Right (VCAR). - Specifically, a "VCAR" component grants, or denies, UPNs the right to - search and write components, properties, and parameters on calendars - within a CS. - - The "VCAR" component model does not put any restriction on the - sequence in which the object and access rights are created. That is, - an object associated with a particular "VCAR" component might be - created before or after the actual "VCAR" component is defined. In - addition, the "VCAR" and "VEVENT" components might be created in the - same iCalendar object and passed together in a single object. - - All rights MUST BE denied unless specifically granted. - - If two rights specified in "VCAR" components are in conflict, the - right that denies access always takes precedence over the right that - grants access. Any attempt to create a "VCAR" component that - conflicts with a "VCAR" components with a "DECREED" property set to - the "TRUE" value must fail. - -4.2.1 Access Control and NOCONFLICT - - The "TRANSP" property can take on values "TRANSPARENT-NOCONFLICT" and - "OPAQUE-NOCONFLICT" that prohibit other components from overlapping - it. This setting overrides access. The "ALLOW-CONFLICT" CS, Calendar - or component setting may also prevent overlap, returning an error - code "6.3". - -4.2.2 Predefined VCARs - - Predefined calendar access CARIDs that MUST BE implemented are: - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 26] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - CARID:READBUSYTIMEINFO - Specifies the "GRANT" and "DENY" rules that - allow UPNs to search "VFREEBUSY" components. An example definition - for this VCAR is: - - - - - BEGIN:VCAR - CARID:READBUSYTIMEINFO - BEGIN:VRIGHT - GRANT:* - PERMISSION:SEARCH - SCOPE:SELECT * FROM VFREEBUSY WHERE STATE() = 'BOOKED' - END:VRIGHT - END:VCAR - - - CARID:REQUESTONLY - Specifies the "GRANT" and "DENY" rules to UPNs - other than the owner of the calendar the ability to write new - objects with the property "METHOD" property set to the "REQUEST" - value. This CARID allows the owner to specify which UPNs are - allowed to make scheduling requests. An example definition for - this VCAR is: - - - - - BEGIN:VCAR - CARID:REQUESTONLY - BEGIN:VRIGHT - GRANT:NON CAL-OWNERS() - PERMISSION:CREATE - RESTRICTION:SELECT VEVENT FROM VAGENDA WHERE METHOD = 'REQUEST' - RESTRICTION:SELECT VTODO FROM VAGENDA WHERE METHOD = 'REQUEST' - RESTRICTION:SELECT VJOURNAL FROM VAGENDA WHERE METHOD = 'REQUEST' - END:VRIGHT - END:VCAR - - - CARID:UPDATEPARTSTATUS - Grants to authenticated users the right to - modify the instances of the "ATTENDEE" property set to one of - their calendar addresses in any components for any booked - component containing an "ATTENDEE" property. This allows (or - denies) a CU the ability to update their own participation status - in a calendar where they might not otherwise have "MODIFY" command - access. They are not allowed to change the "ATTENDEE" property - value. An example definition for this VCAR is (This example only - affects the "VEVENT" components): - - - -Royer, et al. Expires July 12, 2004 [Page 27] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - - - - BEGIN:VCAR - CARID:UPDATEPARTSTATUS - BEGIN:VRIGHT - GRANT:* - PERMISSION:MODIFY - SCOPE:SELECT ATTENDEE FROM VEVENT - WHERE ATTENDEE = SELF() - AND ORGANIZER = CURRENT-TARGET() - AND STATE() = 'BOOKED' - RESTRICTION:SELECT * FROM VEVENT - WHERE ATTENDEE = SELF() - END:VRIGHT - END:VCAR - - - CARID:DEFAULTOWNER - Grants to any owner the permission they have - for the target. An example definition for this VCAR is: - - - - - BEGIN:VCAR - CARID:DEFAULTOWNER - BEGIN:VRIGHT - GRANT:CAL-OWNERS() - PERMISSION:* - SCOPE:SELECT * FROM VAGENDA - END:VRIGHT - END:VCAR - - - -4.2.3 Decreed VCARs - - A CS MAY choose to implement and allow persistent immutable VCARs - that may be configured by the CS administrator. A reply from the CS - may dynamically create "VCAR" components that are decreed depending - on the implementation. To the CUA any "VCAR" component with the - "DECREED" property set to "TRUE" can not be changed by the currently - authenticated UPN, and depending on the implementation and other - "VCAR" components; might not be able to be changed by any UPN using - CAP, and never when the CUA gets a "DECREED:TRUE" VCAR. - - When a user attempts to modify or override a decreed "VCAR" component - rules an error will be returned indicating that the user has - - - -Royer, et al. Expires July 12, 2004 [Page 28] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - insufficient authorization to perform the operation. The reply to the - CUA MUST BE the same as if a non-decreed VCAR caused the failure. - - The CAP protocol does not define the semantics used to initially - create a decreed VCAR. This administrative task is outside the scope - of the CAP protocol. - - For example; an implementation or a CS administrator may wish to - define a VCAR that will always allow the calendar owners to have full - access to their own calendars. - - Decreed "VCAR" components MUST BE readable by the calendar owner in - standard "VCAR" component format. - -4.3 CAP Session Identity - - A [BEEP] session has an associated set of authentication credentials, - from which is derived a UPN. This UPN is the identity of the CAP - session, and is used to determine access rights for the session. - - The CUA may change the identity of a CAP session by calling the - "IDENTIFY" command. The CS only permits the operation if the - session's authentication credentials are good for the requested - identity. The method of checking this permission is implementation - dependent, but may be thought of as a mapping from authentication - credentials to UPNs. The "IDENTIFY" command allows a single set of - authentication credentials to choose from multiple identities, and - allows multiple sets of authentication credentials to assume the same - identity. - - For anonymous access the identity of the session is "@". A UPN with a - null Username and null Realm is anonymous. A UPN with a null - Username, but non-null Realm, such as "@foo.com" may be used to mean - any identity from that Realm, which is useful to grant access rights - to all users in a given Realm. A UPN with a non-null Username and - null Realm, such as "bob@" could be a security risk and MUST NOT be - used. - - As the UPN includes Realm information it may be used to govern - calendar store access rights across Realms. However, governing access - rights across Realms is only useful if login access is available. - This could be done through a trusted server relationship or a - temporary account. Note that trusted server relationships are outside - the scope of [CAP]. - - The "IDENTIFY" command also provides for a weak group implementation. - By allowing multiple sets of authentication credentials belonging to - different users to identify as the same UPN, that UPN essentially - - - -Royer, et al. Expires July 12, 2004 [Page 29] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - identifies a group of people, and may be used for group calendar - ownership, or the granting of access rights to a group. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 30] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -5. CAP URL and Calendar Address - - The CAP URL scheme is used to designate calendar stores and calendars - accessible using the CAP protocol. - - The CAP URL scheme conform to the generic URL syntax, defined in RFC - 2396, and follows the Guidelines for URL Schemes, set forth in RFC - 2718. - - A CAP URL begins with the protocol prefix "cap" and is defined by the - following grammar. - - - capurl = "cap://" csid [ "/" relcalid ] - csid = hostport ; As defined in Section 3.2.2 of RFC 2396 - relcalid = *uric ; As defined in Section 2 of RFC 2396 - - - A 'relcalid' is an identifier that uniquely identifies a calendar on - a particular calendar store. There is no implied structure in a - Relative CALID (relcalid). It may refer to the calendar of a user or - of a resource such as a conference room. It MUST BE unique within the - calendar store. - - Examples: - - - cap://cal.example.com - cap://cal.example.com/Company/Holidays - cap://cal.example.com/abcd1234Usr - - - A 'relcalid' is permitted and is resolved according to the rules - defined in Section 5 of RFC 2396. - - Examples of valid relative CAP URLs: - - - opqaueXzz123String - UserName/Personal - - - A Calendar addresses can be described as qualified or relative CAP - URLs. - - For a user currently authenticated to the CS on cal.example.com, - these two example calendar addresses refer to the same calendar: - - - - -Royer, et al. Expires July 12, 2004 [Page 31] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - cap://cal.example.com/abcd1234USR - abcd1234USR - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 32] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -6. New Value Types - - The following sections contains new components, properties, - parameters, and value definitions. - - The purpose of these is to extend the iCalendar objects in a - compatible way so that existing iCalendar "VERSION" property "2.0" - value parsers can still parse the objects without modification. - -6.1 Property Value Data Types - -6.1.1 CAL-QUERY Value Type - - Subject: Registration of text/calendar MIME value type CAL-QUERY - - Value Name: CAL-QUERY - - Value Type Purpose: This value type is used to identify values and - contains query statements targeted at locating those values. - - This is based on [SQL92] and [SQLCOM]. - - 1. For the purpose of a query, all components should be handled as - tables, and the properties of those components, should be handled - as columns. - - 2. All VAGENDAs and CSs look like tables for the purpose of a QUERY. - And all of their properties look like columns in those tables. - - 3. You CAN NOT do any cross component-type joins. And that means you - can ONLY have one component, OR one "VAGENDA" component OR one - "VCALSTORE" component in the "FROM" clause. - - 4. Everything in the "SELECT" clause and "WHERE" clauses in MUST BE - from the same component type, or "VAGENDA" component OR - "VCALSTORE" component in the "FROM" clause. - - 5. When multiple "QUERY" properties are supplied in a single - "VQUERY" component, the results returned are the same as the - results returned for multiple "VQUERY" components having each a - single "QUERY" property. - - 6. The '.' is used to separate the table name (component) and column - name (property or component) when selecting a property that is - contained inside of a component that is targeted in the TARGET - property. - - 7. A contained component without a '.' is not the same as - - - -Royer, et al. Expires July 12, 2004 [Page 33] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - "component-name.*". If given as "component-name" (no dot) the - encapsulating BEGIN/END statement will be supplied for - "component-name".: - - In this example the '.' is used to separate the "TRIGGER" property - from its contained component (VALARM). Which is contained in any - "VEVENT" component in the selected "TARGET" property value (a - relcalid). All "TRIGGER" properties in any "VEVENT" component in - relcalid would be returned. - - - - TARGET:relcalid - QUERY:SELECT VALARM.TRIGGER FROM VEVENT - - - - - SELECT VALARM FROM VEVENT WHERE UID = "123" - - This returns one BEGIN/END "VALARM" component for each - "VALARM" component in the matching "VEVENT" component. - As there is no '.' (dot) in the VALARM after the SELECT above: - - BEGIN:VALARM - TRIGGER;RELATED=END:PT5M - REPEAT:4 - ... - END:VALARM - BEGIN:VALARM - TRIGGER;RELATED=START:PT5M - DURATION:PT10M - ... - END:VALARM - ... - ... - - - If provided as "component-name.*", then only the properties and any - contained components will be returned: - - - - SELECT VALARM.* FROM VEVENT WHERE UID = "123" - - Will return all of the properties in each "VALARM" component - in the matching "VEVENT" component: - - - - -Royer, et al. Expires July 12, 2004 [Page 34] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - TRIGGER;RELATED=END:PT5M - REPEAT:4 - ... - TRIGGER;RELATED=START:PT5M - DURATION:PT10M - ... - ... - - - - - (a) SELECT FROM VEVENT - - (b) SELECT VALARM FROM VEVENT - - (c) SELECT VALARM.* FROM VEVENT - - (d) SELECT * FROM VEVENT - - (e) SELECT * FROM VEVENT WHERE - VALARM.TRIGGER < '20020201T000000Z' - AND VALARM.TRIGGER > '20020101T000000Z' - - Note: - (a) Selects all instances of - from all "VEVENT" components. - - (b) and (c) Select all "VALARM" components from all - "VEVENT" components. (b) would return then in - BEGIN/END VALARM tags. (c) would return all - of the properties without BEGIN/END VALARM tags. - - (d) Selects every property and every component - that is in any "VEVENT" component, with each "VEVENT" - component wrapped in a BEGIN/END VALARM tags. - - (e) Selects all properties and all contained - components in all "VEVENT" components that have a "VALARM" - component with a "TRIGGER" property value between - the provided dates and times, with each "VEVENT" - component wrapped in a BEGIN/END VALARM tags. - - NOT VALID: - - (f) SELECT VEVENT.VALARM.TRIGGER FROM VEVENT - - (g) SELECT DTSTART,UID FROM VEVENT WHERE - VTODO.SUMMERY = "Fix typo in CAP" - - - -Royer, et al. Expires July 12, 2004 [Page 35] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Note: (f) Is NOT valid because it contains - two '.' characters in the "SELECT" clause. - - (g) Is NOT valid because it mixes VEVENT - and VTODO properties in the same VQUERY. - - - - Formal Definition: The value type is defined by the following - notation: - - - cal-query = "SELECT" SP cap-val SP - "FROM" SP comp-name SP - "WHERE" SP cap-expr - - / "SELECT" SP cap-cols SP - "FROM" SP comp-name - - cap-val = cap-cols / param - / ( cap-val "," cap-val ) - - ; NOTE: there is NO space around the "," on - ; the next line - cap-cols = cap-col / ( cap-cols "," cap-col) - / "*" - - ; A 'cap-col' is: - ; - ; Any property name ('cap-prop') found in the component - ; named in the 'comp-name' used in the "FROM" clause. - ; - ; SELECT ORGANIZER FROM VEVENT ... - ; - ; OR - ; - ; A component name ('comp-name') of an existing component - ; contained inside of the 'comp-name' used in the "FROM" - ; clause. - ; - ; SELECT VALARM FROM VEVENT ... - ; - ; OR - ; - ; A component name ('comp-name') of an existing - ; component contained inside of the 'comp-name' used - ; in the "FROM" clause followed by a property - ; name ('cap-prop') to be selected from that component. - - - -Royer, et al. Expires July 12, 2004 [Page 36] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - ; (comp-name "." cap-prop) - ; - ; SELECT VALARM.TRIGGER FROM VEVENT ... - - cap-col = comp-name - / comp-name "." cap-prop - / cap-prop - - comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY" - / "VALARM" / "DAYLIGHT" / "STANDARD" / "VAGENDA" - / "VCAR" / "VCALSTORE" / "VQUERY" / "VTIMEZONE" - / "VRIGHT" / x-comp / iana-comp - - cap-prop = ; A property that may be in the 'cap-comp' named - ; in the "SELECT" clause. - - cap-expr = "(" cap-expr ")" - / cap-term - - cap-term = cap-expr SP cap-logical SP cap-expr - / cap-factor - - cap-logical= "AND" / "OR" - - cap-factor = cap-colval SP cap-oper SP col-value - / cap-colval SP "LIKE" SP col-value - / cap-colval SP "NOT LIKE" SP col-value - / cap-colval SP "IS NULL" - / cap-colval SP "IS NOT NULL" - / col-value SP "IN" cap-colval" - / col-value SP "NOT IN" cap-colval" - / "STATE()" "=" ( "BOOKED" - / "UNPROCESSED" - / "DELETED" - / iana-state - / x-state ) - - iana-state = ; Any state registered by IANA directly or - ; included in an RFC that may be applied to - ; the component and within the rules published. - - x-state = ; Any experimental state that starts with - ; "x-" or "X-". - - cap-colval = cap-col / param - - param = "PARAM(" cap-col "," cap-param ")" - - - - -Royer, et al. Expires July 12, 2004 [Page 37] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - cap-param = ; Any parameter that may be contained in the cap-col - ; in the supplied PARAM() function - - col-value = col-literal - / "SELF()" - / "CAL-OWNERS()" - / "CAL-OWNERS(" cal-address ")" - / "CURRENT-TARGET()" - - cal-address = ; A CALID as define by CAP - - col-literal = "'" literal-data "'" - - literal-data = ; Any data that matches the value type of the - ; column that is being compared. That is you can - ; not compare PRIORITY to "some string" because - ; PRIORITY has a value type of integer. If it is - ; not preceded by the LIKE element, any '%' and '_' - ; characters in the literal data are not treated as - ; wildcard characters and do not have to be backslash - ; escaped. - ; - ; OR - ; - ; If the literal-data is preceded by the LIKE - ; element it may also contain the '%' and '_' - ; wildcard characters. And if the literal data - ; that is comparing contains any '%' or '_' - ; characters, they MUST BE backslash escaped as - ; described in the notes below in order for them not - ; to be treated as wildcard characters. - ; - ; And if the literal data contains any characters - ; that would have to be backslash escaped if - ; a property or parameter value then they must - ; be backslash escaped in the literal-data. - ; PLUS the quote character (') must be backslash - ; escaped. Example: - ; - ; ... WHERE SUBJECT = 'It\'s time to ski' - ; - - cap-oper = "=" - / "!=" - / "<" - / ">" - / "<=" - / ">=" - - - -Royer, et al. Expires July 12, 2004 [Page 38] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - SP = ; A single white space ASCII character - ; (value in HEX %x20). - - x-comp = ; As defined in [iCAL] section 4.6 - - iana-comp = ; As defined in [iCAL] section 4.6 - - - -6.1.1.1 [NOT] CAL-OWNERS() - - This function returns the list of "OWNER" properties for the named - calendar when used in the "SELECT" clause. - - If called as 'CAL-OWNERS()', it is equivalent to the comma separated - list of all of the owners of the calendar that match the provided - "TARGET" property value. If the target is a "VCALSTORE", it returns - the "CALMASTER" property. - - If called as 'CAL-OWNERS(cal-address)', then it is the equivalent to - the comma separated list of owners for the named calendar id. If - 'cal-address' is a CS, it returns the "CALMASTER" property. - - If used in the "WHERE" clause it then returns true if the currently - authenticated UPN is an owner of the currently selected object - matched in the provided "TARGET" property. Used in a CAL-QUERY - "WHERE" clause and in the UPN-FILTER. - -6.1.1.2 CURRENT-TARGET() - - Is equivalent to the value of the "TARGET" property in the current - command. Used in a CAL-QUERY "WHERE" clause. - -6.1.1.3 PARAM() - - Used in a CAL-QUERY. Returns or tests for the value of the named - parameter from the named property. - -6.1.1.3.1 PARAM() in SELECT - - When used in a "SELECT" clause, it returns the entire property and - all of that properties parameters (the result is not limited to the - supplied parameter). If the property does not contain the named - parameter, then the property is not returned (It could however be - returned as a result of another "SELECT" clause value.) If multiple - properties of the supplied name have the named parameter, all - properties with that named parameter are returned. If multiple - PARAM() clauses in a single "SELECT" CLAUSE match the same property, - - - -Royer, et al. Expires July 12, 2004 [Page 39] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - then the single matching property is returned only once. - - Also note that many parameters have default values defined in [iCAL] - that must be treated as existing with their default value in the - properties as defined in [iCAL} even when not explicitly present. So - for example if a query were performed with PARAM(ATTENDEE,ROLE) then - ALL "ATTENDEE" properties would match because even when they do not - explicitly contain the "ROLE" parameter, it has a default value and - therefore must match. - - So when PARAM() is used in a "SELECT" clause, then it is more - accurate to say that it means return the property if it contains the - named parameter explicitly in the property or simply because the - parameter has a default for that property. - -6.1.1.3.2 PARAM() in WHERE - - When used in the "WHERE" clause, a match is true when the parameter - value matches the compare clause according to the supplied WHERE - values. If multiple named properties contain the named parameter, - then each parameter value is compared in turn to the condition and if - any match, then the results would be true for that condition the same - as if only one had existed. Each matching properties or components - are returned only once. - - As a parameter may be multivalued then the comparison might need to - be done with an "IN" or "NOT IN" comparator. - - Given the following query: - - ATTENDEE;PARTSTAT=ACCEPTED:cap://host.com/joe - - SELECT VEVENT FROM VAGENDA - WHERE PARAM(ATTENDEE,PARTSTAT) = 'ACCEPTED' - - Then all "VEVENT" components that contain one or more "ATTENDEE" - properties that have a "PARTSTAT" parameter with a "ACCEPTED" value - would be returned. And each uniquely matching VEVENT would only be - returned once no matter how many "ATTENDEE" properties had matching - roles in each unique "VEVENT" component. - - Also note that many parameters have default values defined in [iCAL]. - So if the following query were performed on the "ATTENDEE" property - in the above example: - - SELECT VEVENT FROM VAGENDA - WHERE PARAM(ATTENDEE,ROLE) = 'REQ-PARTICIPANT' - - - - -Royer, et al. Expires July 12, 2004 [Page 40] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - It would return the "ATTENDEE" property exampled above because the - default value for the "ROLE" parameter is "REQ-PARTICIPANT". - -6.1.1.4 SELF() - - Used in a CAL-QUERY "WHERE" clause. Returns the UPN of the currently - authenticated UPN or their current UPN as a result of an IDENTIFY - command. - -6.1.1.5 STATE() - - Returns one of three values, "BOOKED", "UNPROCESSED", or "DELETED" - depending on the state of the object. Where "DELETED" is a component - in the marked for delete state. Components that have been removed - from the store are never returned. - - If not specified in a query then both "BOOKED" and "UNPROCESSED" data - is returned. Each unique "METHOD" property must be in a separate MIME - object per the [iCAL] section 3.2 restriction. - -6.1.1.6 Use of single quote - - All literal values are surrounded by single quotes ('), not double - quotes ("), and not without any quotes. If the value contains quotes - or any other ESCAPED-CHAR, they MUST BE backslash escaped as - described in section 4.3.11 "Text" of [iCAL]. Any "LIKE" clause - wildcard characters that are part of any literal data that is - preceded by a "LIKE" clause or "NOT LIKE" clause and is not intended - to mean wildcard search MUST BE escaped as described in note (7) - below. - -6.1.1.7 Comparing DATE and DATE-TIME values - - When comparing "DATE-TIME" values to "DATE" values and when comparing - "DATE" values to "DATE-TIME" values, the result will be true if the - "DATE" value is on the same day as the "DATE-TIME" value. And they - are compared in UTC no matter what time zone the data may actual have - been stored in. - - Local time event as descibed in section 4.2.19 of [iCAL] must be - considered to be in the CUA default timezone that was supplied by the - CUA in the "CAPABILITY" exchange. - - - VALUE-1 VALUE-2 Compare Results - - 20020304 20020304T123456 TRUE - (in UTC-3) (in UTC-3) - - - -Royer, et al. Expires July 12, 2004 [Page 41] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - 20020304 20020304T003456 FALSE - (in UTC) (in UTC-4) - - 20020304T003456Z 20020205T003456 FALSE - (in UTC-0) (in UTC-7) - - - When comparing "DATE" values and "DATE-TIME" values with the "LIKE" - clause the comparison will be done as if the value is a [iCAL] DATE - or DATE-TIME string value. - - - LIKE '2002%' will match anything in the year 2002. - - LIKE '200201%' will match anything in January 2002. - - LIKE '%T000000' will match anything at midnight. - - LIKE '____01__T%' will match anything for any year or - time that is in January. - (Four '_', '01', two '_' 'T%'). - - - Using a "LIKE" clause value of "%00%, would return any value that - contained two consecutive zeros. - - All comparisons will be done in UTC. - -6.1.1.8 DTEND and DURATION - - The "DTEND" property value is not included in the time occupied by - the component. That is a "DTEND" property value of 20030614T12000 - includes all of the time up to but not including noon on that day. - - The "DURATION" property value end time is also not inclusive. So an - object with a "DTSTART" property value of 20030514T110000 and a - "DURATION" property value of "1H" does not include noon on that day. - - When a "QUERY" property value contains a "DTEND" value, then the CS - MUST also evaluate any existing "DURATION" property value and - determine if it has an effective end time that matches the "QUERY" - property supplied "DTEND" value or any range of values supplied by - the "QUERY" property. - - When a "QUERY" property contains a "DURATION" value, then the CS MUST - also evaluate any existing "DTEND" property values and determine if - they have an effective duration that matches the "QUERY" property - value supplied "DURATION" value or any range of values supplied by - - - -Royer, et al. Expires July 12, 2004 [Page 42] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - the "QUERY" property. - -6.1.1.9 [NOT] LIKE - - The pattern matching characters are the '%' that matches zero or more - characters, and '_' that matches exactly one character (where - character does not always mean octet). - - "LIKE" clause pattern matches always cover the entire string. To - match a pattern anywhere within a string, the pattern must start and - end with a percent sign. - - To match a '%' or '_' in the data and not have it interpreted as a - wildcard character, they MUST BE backslash escaped. That is to search - for a '%' or '_' in the string: - - - LIKE '%\%%' Matches any string with a '%' in it. - LIKE '%\_%' Matches any string with a '_' in it. - - - Strings compared using the "LIKE" clause MUST BE performed using case - in-sensitive comparisons when the locale allows. (Example: in - US-ASCII the compare assumes 'a' = 'A'). - - If the "LIKE" clause is preceded by 'NOT' then there is a match when - the string compare fails. - - Some property values (such as the 'recur' value type), contain commas - and are not multi valued. The CS must understand the objects being - compared and understand how to determine how any multi valued or - multi instances properties or parameter values are separated, quoted, - and backslash escaped and perform the comparisons as if each value - existed by itself and not quoted or backslash escaped when comparing - using the LIKE element. - - See related examples in Section 6.1.1.11 - -6.1.1.10 Empty vs. NULL - - When used in a CAL-QUERY value, "NULL" means that the property or - parameter is not present in the object. Paramaters that are not - provided and have a default value in the property are considered to - exist with their default value and will not be "NULL". - - If the property exists but has no value then "NULL" MUST NOT match. - If the parameter exists but has no value then "NULL" MUST NOT match. - If the parameter not present and has a default value then "NULL" MUST - - - -Royer, et al. Expires July 12, 2004 [Page 43] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - NOT match. - - If the property (or parameter) exists, but has no value then it - matches the empty string '' (quote quote). - -6.1.1.11 [NOT] IN - - This is similar to the "LIKE" clause, except it does value matching - and not string comparison matches. - - Some iCalendar objects can be multi instance and multi valued. The - "IN" clause will return a match if the literal value supplied as part - of the "IN" clause is contained in the value of any instance of the - named property or parameter, or is in any of the multiple values in - the named property or parameter. Unlike the "LIKE" clause, the '%' - and '_' matching characters are not used with the "IN" clause and - have no special meaning. - - - BEGIN:A-COMPONENT - a property:value1,value2 One property, two values. - b property:"value1,value2" One property, one value. - c property:parameter=1,2:x One parameter, two values. - d property:parameter="1,2",3:y One parameter, one value. - e property:parameter=",":z One parameter, one value. - f property:x,y,z One property, three values - END:A-COMPONENT - - 'value1' IN property would match (a) only. - 'value1,value2' IN property would match (b) only. - 'value%' IN property would NOT match any. - ',' IN property would NOT match any. - '%,%' IN property would NOT match any. - 'x' IN property would match (f) and (c). - '2' IN parameter would match (c) only. - '1,2' IN parameter would match (d) only. - ',' IN parameter would match (e) only. - '%,%' IN parameter would NOT match any. - - property LIKE 'value1%' would match (a) and (b). - property LIKE 'value%' would match (a) and (b). - property LIKE 'x' would match (f) and (c). - parameter LIKE '1%' would match (c) and (d). - parameter LIKE '%2%' would match (c) and (d). - parameter LIKE ',' would match (e) only. - - - Some property values (such as the "RECUR" value type), contain commas - - - -Royer, et al. Expires July 12, 2004 [Page 44] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - and are not multi valued. The CS must understand the objects being - compared and understand how to determine how any multi valued or - multi instances properties or parameter values are separated, quoted, - and backslash escaped and perform the comparisons as if each value - existed by itself and not quoted or backslash escaped when comparing - using the IN element. - - If the "IN" clause is preceded by 'NOT' then there is a match when - the value does not exist in the property or parameter value. - -6.1.1.12 DATE-TIME and TIME values in a WHERE clause - - All "DATE-TIME" and "TIME" literal values supplied in a "WHERE" - clause MUST BE terminated with 'Z'. That means that the CUA MUST - supply the values in UTC. - - - Valid: - - WHERE alarm.TRIGGER < '20020201T000000Z' - AND alarm.TRIGGER > '20020101T000000Z' - - - Not valid and it is a syntax error and the CS MUST reject the QUERY. - - - WHERE alarm.TRIGGER < '20020201T000000' - AND alarm.TRIGGER > '20020101T000000' - - - -6.1.1.13 Multiple contained components - - If a query references a component and a component or property - contained in the component, any clauses referring to the contained - component or property must be evaluated on all of the contained - components or properties. If any of the contained components or - properties match the query, and the conditions on the containing - component are also true, the component matches the query. - - For example, in the query below, if a BOOKED VEVENT contains multiple - VALARMs, and the VALARM.TRIGGER clause is true for any of the VALARMs - in the VEVENT, then the UID, SUMMARY, and DESCRIPTION of this VEVENT - would be included in the QUERY results. - - - - BEGIN:VQUERY - - - -Royer, et al. Expires July 12, 2004 [Page 45] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - EXPAND:TRUE - QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT - WHERE VALARM.TRIGGER >= '20000101T030405Z' - AND VALARM.TRIGGER <= '20001231T235959Z' - AND STATE() = 'BOOKED' - END:VQUERY - - - -6.1.1.14 Example, Query by UID - - The following example would match the entire content of a "VEVENT" or - "VTODO" component with the "UID" property equal to "uid123" and not - expand any multiple instances of the component. If the CUA does not - know if "uid123" was a "VEVENT", "VTODO", "VJOURNAL", or any other - component, then all components that the CUA supports MUST BE supplied - in a QUERY property. This example assumes the CUA is only interested - in "VTODO" and "VEVENT" components. - - If the results were empty it could also mean that "uid123" was a - property in a component other than a VTODO or VEVENT. - - - BEGIN:VQUERY - QUERY:SELECT * FROM VTODO WHERE UID = 'uid123' - QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123' - END:VQUERY - - - -6.1.1.15 Query by Date-Time range - - This query selects the entire content of every booked "VEVENT" - component that has an instance greater than or equal to July 1st, - 2000 00:00:00 UTC and less than or equal to July 30st, 2000 23:59:59 - UTC. This includes single instance "VEVENT" components that do no - explicitly contain any recurence properties or "RECURRENCE-ID" - properties. This works only for CSs that have the "RECUR-EXPAND" - property value set to "TRUE" in the "GET-CAPABILITY" exchange. - - BEGIN:VQUERY - EXPAND:TRUE - QUERY:SELECT * FROM VEVENT - WHERE RECURRENCE-ID >= '20000701T000000Z' - AND RECURRENCE-ID <= '20000730T235959Z' - AND STATE() = 'BOOKED' - END:VQUERY - - - - -Royer, et al. Expires July 12, 2004 [Page 46] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -6.1.1.16 Query for all Unprocessed Entries - - The following example selects the entire contents of all non-booked - "VTODO" and "VEVENT" components in the "UNPROCESSED" state. The - default for the "EXPAND" property is FALSE, so the recurrence rules - will not be expanded. - - - BEGIN:VQUERY - QUERYID:Fetch VEVENT and VTODO iTIP components - QUERY:SELECT * FROM VEVENT WHERE STATE() = 'UNPROCESSED' - QUERY:SELECT * FROM VTODO WHERE STATE() = 'UNPROCESSED' - END:VQUERY - - - The following example fetches all "VEVENT" and "VTODO" components in - the "BOOKED" state. - - - BEGIN:VQUERY - QUERYID:Fetch All Booked VEVENT and VTODO components - QUERY:SELECT * FROM VEVENT WHERE STATE() = 'BOOKED' - QUERY:SELECT * FROM VTODO WHERE STATE() = 'BOOKED' - END:VQUERY - - - The following fetches the "UID" property for all "VEVENT" and "VTODO" - components that have been marked for delete. - - - BEGIN:VQUERY - QUERYID:Fetch UIDs of marked for delete VEVENTs and VTODOs - QUERY:SELECT UID FROM VEVENT WHERE STATE() = 'DELETE' - QUERY:SELECT UID FROM VTODO WHERE STATE() = 'DELETE' - END:VQUERY - - - -6.1.1.17 Query with Subset of Properties by Date/Time - - In this example only the named properties will be selected and all - booked and non-booked components will be selected that have a - "DTSTART" value from February 1st to February 10th 2000 (in UTC). - - - BEGIN:VQUERY - QUERY:SELECT UID,DTSTART,DESCRIPTION,SUMMARY FROM VEVENT - WHERE DTSTART >= '20000201T000000Z' - - - -Royer, et al. Expires July 12, 2004 [Page 47] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - AND DTSTART <= '20000210T235959Z' - END:VQUERY - - - -6.1.1.18 Query with Components and Alarms In A Range - - This example fetches all booked "VEVENT" components with an alarm - that triggers within the specified time range. In this case only the - "UID", "SUMMARY", and "DESCRIPTION" properties will be selected for - all booked "VEVENTS" components that have an alarm between the two - date-times supplied. - - - BEGIN:VQUERY - EXPAND:TRUE - QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT - WHERE VALARM.TRIGGER >= '20000101T030405Z' - AND VALARM.TRIGGER <= '20001231T235959Z' - AND STATE() = 'BOOKED' - END:VQUERY - - - -6.1.2 UPN Value Type - - Value Name: UPN - - Purpose: This value type is used to identify values that contain user - principal name of CU or group of CU. - - Formal Definition: The value type is defined by the following - notation: - - - upn = "@" - / [ dot-atom-text ] "@" dot-atom-text - - ; dot-atom-text is defined in RFC 2822 - - - - Description: This data type is an identifier that denotes a CU or a - group of CU. A UPN is a RFC 2822 compliant email address, with - exceptions listed below, and in most cases it is deliverable to the - CU. In some cases it is identical to the CU's well known email - address. A CU's UPN MUST never be an e-mail address that is - deliverable to a different person. And there is no requirement that a - - - -Royer, et al. Expires July 12, 2004 [Page 48] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - person's UPN MUST BE their e-mail address. A UPN is formatted as a - user name followed by "@" followed by a Realm in the form of a valid, - and unique, DNS domain name. The user name MUST BE unique within the - Realm. In it's simplest form it looks like "user@example.com". - - In certain cases a UPN will not be RFC 2822 compliant. When anonymous - authentication is used, or anonymous authorization is being defined, - the special UPN "@" will be used. When authentication MUST BE used, - but unique identity MUST BE obscured, a UPN of the form - @DNS-domain-name may be used. For example, "@example.com". - - Example: - - The following is a UPN for a CU: - - - jdoe@example.com - - - The following is a example of a UPN that could be for a group of CU: - - - staff@example.com - - - The following is a UPN for an anonymous CU belonging to a specific - realm or when used as a UPN-FILTER it specifies that it applies to - all UPNs in a specific realm: - - - @example.com - - - The following is a UPN for an anonymous CU: - - - @ - - - -6.1.3 UPN-FILTER Value - - Value Name: UPN-FILTER - - Purpose: This value type is used to identify values that contain a - user principal name filter. - - Formal Definition: The value type is defined by the following - - - -Royer, et al. Expires July 12, 2004 [Page 49] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - notation: - - - - ; NOTE: "CAL-OWNERS(cal-address)" - ; and "NOT CAL-OWNERS(cal-address)" - ; are both NOT allowed below. - ; - upn-filter = "CAL-OWNERS()" / - - "NOT CAL-OWNERS()" / - "*" / - [ "*" / dot-atom-text ] "@" ( "*" / dot-atom-text ) - - ; dot-atom-text is defined in RFC 2822 - - - Description: The value is used to match user principal names (UPNs). - For "CAL-OWNERS()" and "NOT CAL-OWNERS()", see Section 8.24. - - - - * Matches all UPNs. - - @ Matches the UPN of anonymous CUs - belonging to the null realm - - @* Matches the UPN of anonymous CUs - belonging to any non-null realm - - @realm Matches the UPN of anonymous CUs - belonging to the specified realm. - - *@* Matches the UPN of non-anonymous CUs - belonging to any non-null realm - - *@realm Matches the UPN of non-anonymous CUs - belonging to the specified realm - - user@realm Matches the UPN of the specified CU - belonging to the specified realm - - user@* Not allowed. - - user@ Not allowed. - - - Example: The following are examples of this value type: - - - -Royer, et al. Expires July 12, 2004 [Page 50] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - DENY:NON CAL-OWNERS() - DENY:@hackers.example.com - DENY:*@hackers.example.com - GRANT:sam@example.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 51] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -7. New Parameters - -7.1 ACTION Parameter - - Parameter Name: ACTION - - Purpose: This parameter indicates the action to be taken when a - timeout occurs. - - Value Type: TEXT - - Conformance: This property can be specified in the "CMD" property. - - When present in a "CMD" property the "ACTION" parameter specifies the - action to be taken when the command timeout expires. - - Formal Definition: The parameter is defined by the following - notation: - - - action-param = ";" "ACTION" "=" ( "ASK" / "ABORT" ) - ; If 'action-param' is supplied then - ; 'latency-param' MUST BE supplied. - - - - Example: The following is an example of this parameter: - - - CMD;LATENCY=10;ACTION=ASK:CREATE - - - -7.2 ENABLE Parameter - - Parameter Name: ENABLE - - Purpose: This parameter indicates whether or not the property should - be ignored. Example if a "TRIGGER" property in a "VALARM" component - should be ignored. - - Value Type: BOOLEAN - - Conformance: This property can be specified in the "TRIGGER" - properties. - - Description: When a non owner sends an [iTIP] "REQUEST" to a calendar - that object might contain a "VALARM" component. The owner may wish to - - - -Royer, et al. Expires July 12, 2004 [Page 52] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - have local control over their own CUA and when or how alarms are - triggered. - - A CUA may add the "ENABLE" parameter to any "TRIGGER" property before - booking the component. If the "ENABLE" parameter is set to "FALSE", - then the alarm will be ignored by the CUA. If set to "TRUE", or if - the "ENABLE" property is not in the "TRIGGER" property, the alarm is - enabled. This parameter may not be known by pre-CAP implementations - and should not be an issue as it conforms to an 'ianaparam' as - defined in [iCAL]. - - Formal Definition: The property is defined by the following notation: - - - enable-param = "ENABLE" "=" boolean - - - Example: The following is an example of this property for a "VAGENDA" - component: - - - TRIGGER;ENABLE=FALSE;RELATED=END:PT5M - - - -7.3 ID Parameter - - Parameter Name: ID - - Purpose: When used in a "CMD" component provides a unique identifier. - - Value Type: TEXT - - Conformance: This parameter can be specified in the "CMD" property. - - Description: If there is more than one command sent then the "ID" - parameter is used to uniquely identify the command. - - A CUA may add the "ID" parameter to any "CMD" property before sending - the command. There must not be more than one outstanding command - tagged with the same "ID" parameter value. - - Formal Definition: The property is defined by the following notation: - - - id-param = ";" "ID" "=" unique-id - ; The text value supplied is a unique value - ; shared between the CUA and CS to uniquely - - - -Royer, et al. Expires July 12, 2004 [Page 53] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - ; identify the instance of command in the - ; the current CUA session. The value has - ; no meaning to other CUAs or other sessions. - - unique-id = ; text - - text = ; As defined in [iCAL]. - - - - Example: The following is an example of this parameter component: - - - CMD;UD=some-unique-value:CREATE - - - -7.4 LATENCY Parameter - - Parameter Name: LATENCY - - Purpose: This parameter indicates time in seconds for when a timeout - occurs. - - Value Type: TEXT - - Conformance: This property can be specified in the "CMD" property. - - When present in a "CMD" property the "LATENCY" parameter specifies - the time in sections when the command timeout expires. - - Formal Definition: The parameter is defined by the following - notation: - - - latency-param = ";" "LATENCY" "=" latency-sec - ; The value supplied in the time in seconds. - ; If 'latency-param' is supplied then - ; 'action-param' MUST BE supplied. - - latency-sec = posint1 - - ; Default is zero (0) meaning no timeout. - - - Example: The following is an example of this parameter: - - - - - -Royer, et al. Expires July 12, 2004 [Page 54] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - CMD;LATENCY=10;ACTION=ASK:CREATE - - - -7.5 LOCAL Parameter - - Parameter Name: LOCAL - - Purpose: Indicates if the named component should be exported to any - non-organizer calendar. - - Value Type: BOOLEAN - - Conformance: This parameter can be specified in the "SEQUENCE" - properties in a "VALARM" component. - - Description: When a non owner sends an [iTIP] "REQUEST" to a calendar - that object might contain a "VALARM" component. The owner may wish to - have local control over their own CUA and when or how alarms are - triggered. - - A CUA may add the "LOCAL" parameter to the "SEQUENCE" property before - booking the component. If the "LOCAL" parameter is set to "TRUE", - then the alarm MUST NOT be forwarded to any other calender. If set to - "FALSE", or if the "LOCAL" parameter is not in the "SEQUENCE" - property, the alarm is global. - - Formal Definition: The property is defined by the following notation: - - - local-param = "LOCAL" "=" boolean - - - Example: The following is an example of this parameter: - - - SEQUENCE;LOCAL=TRUE:4 - - - -7.6 LOCALIZE Parameter - - Parameter Name: LOCALIZE - - Purpose: If provided the "LOCALIZE" parameter specifies the desired - language for error and warning messages. - - Value Type: TEXT - - - -Royer, et al. Expires July 12, 2004 [Page 55] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Conformance: This parameter can be specified in the "CMD" properties. - - When the "LOCALIZE" parameter is supplied then its value MUST BE one - of the values listed in the initial [BEEP] greeting 'localize' - attribute. - - A CUA may add the "LOCALIZE" parameter to the "CMD" property to - specify the language of any error or warning messages. - - Formal Definition: The property is defined by the following notation: - - - localize-param = ";" "LOCALIZE" "=" beep-localize - - beep-localize = text ; As defined in [BEEP] - ; The value supplied MUST BE one value from the initial - ; [BEEP] greeting 'localize' attribute specifying - ; the locale to use for error messages during - ; this instance of the command sent. - - - Example: The following is an example of this parameter: - - - CMD;LOCALIZE=fr_CA:CREATE - - - -7.7 OPTIONS Parameter - - Parameter Name: OPTIONS - - Purpose: If provided the "OPTIONS" parameter specifies some "CMD" - property specific options. - - Value Type: TEXT - - Conformance: This parameter can be specified in the "CMD" properties. - - A CUA adds the "OPTIONS" parameter to the "CMD" property when the - command needs extra values. - - Formal Definition: The property is defined by the following notation: - - option-param = ";" "OPTIONS" "=" cmd-specific - - cmd-specific = ; The value supplied is dependent on the - ; CMD value. See the specific CMDs for the - - - -Royer, et al. Expires July 12, 2004 [Page 56] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - ; correct values to use for each CMD. - - Example: The following is an example of this parameter: - - CMD;OPTIONS=10:GENERATE-UID - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 57] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -8. New Properties - -8.1 ALLOW-CONFLICT Property - - Property Name: ALLOW-CONFLICT - - Purpose: This property indicates whether or not the calendar and CS - supports component conflicts. That is, whether or not any of the - components in the calendar can overlap. - - Value Type: BOOLEAN - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in "VAGENDA" and - "VCALSTORE" component. - - Description: This property is used to indicate whether components may - conflict. That is, if their expanded instances may share the same - time or overlap the same time periods. If it has a value of TRUE, - then conflicts are allowed. If FALSE, the no two components may - conflict. - - If FALSE in the "VCALSTORE" component, then all "VAGENDA" component - "ALLOW-CONFLICT" property values MUST BE false in the CS. - - Formal Definition: The property is defined by the following notation: - - - allow-conflict = "ALLOW-CONFLICT" other-params ":" boolean CRLF - - - Example: The following is an example of this property for a "VAGENDA" - component: - - - ALLOW-CONFLICT:FALSE - - - -8.2 ATT-COUNTER Property - - Property Name: ATT-COUNTER - - Property Parameters: Non-standard property parameters can be - specified on this property. - - - - -Royer, et al. Expires July 12, 2004 [Page 58] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Conformance: This property MUST be specified in an iCalendar object - that specifies counter proposal to a group scheduled calendar entity. - When storing a "METHOD" property with the "COUNTER" method, there - needs to be a way to remember who sent the COUNTER. The ATT-COUNTER - property MUST BE added to all "COUNTER" [iTIP] components by the CUA - before storing in a CS. - - Description: This property is used to identify the CAL-ADDRESS of the - entity that sent the "COUNTER" [iTIP] object. - - Formal Definition: The property is defined by the following notation: - - - attcounter = "ATT-COUNTER" other-params ":" cal-address CRLF - - - Examples: - - ATT-COUNTER:cap:example.com/Doug - ATT-COUNTER:mailto:Doug@Example.com - - -8.3 CALID Property - - Property Name: CALID - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in the "VAGENDA" - component. - - Description: This property is used to specify a fully qualified - CALID. - - Formal Definition: The property is defined by the following notation: - - - CALID = "CALID" other-params ":" relcalid CRLF - - - Example: - - CALID:cap://cal.example.com/sdfifgty4321 - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 59] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -8.4 CALMASTER Property - - Property Name: CALMASTER - - Purpose: The property specifies an e-mail address of a person - responsible for the calendar store. - - Value Type: URI - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in a "VCALSTORE" - component. - - Description: The parameter value SHOULD BE a MAILTO URI as defined in - [URL]. It MUST BE a contact URI such as a MAILTO URI and not a home - page or file URI that describes how to contact the calmasters. - - Formal Definition: The property is defined by the following notation: - - calmaster = "CALMASTER" other-params ":" uri CRLF - - uri = ; IANA registered uri as defined in [iCAL] - - Example: The following is an example of this property: - - CALMASTER:mailto:administrator@example.com - - -8.5 CAP-VERSION Property - - Property Name: CAP-VERSION - - Purpose: This property specifies the version of CAP supported. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property is specified in the "VREPLY" component - that is sent in response to a "GET-CAPABILITY" command. - - Description: This specifies the version of CAP that the endpoint - supports. The list is a comma separated list of RFC numbers - supported. The list MUST contain at least XXXX (NOTE 'XXXX' WILL BE - REPLACED WITH THE RFC NUMBER OF THIS DOCUMENT). - - - -Royer, et al. Expires July 12, 2004 [Page 60] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Formal Definition: The property is defined by the following notation: - - - cap-version = "CAP-VERSION" other-params ":" text CRLF - - - Example: The following are examples of this property: - - - CAP-VERSION:XXXX - - - -8.6 CARID Property - - Property Name: CARID - - Purpose: This property specifies the identifier for an access right - component. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property MUST BE specified once in a "VCAR" - component. - - Description: This property is used in the "VCAR" component to specify - an identifier. A "CARID" property value is unique per container. - - Formal Definition: The property is defined by the following notation: - - - carid = "CARID" other-params ":" text CRLF - - - Example: The following are examples of this property: - - - CARID:xyzzy-007 - CARID:User Rights - - - -8.7 CAR-LEVEL Property - - Property Name: CAR-LEVEL - - - -Royer, et al. Expires July 12, 2004 [Page 61] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Purpose: The property specifies the level of VCAR supported. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in a "VREPLY" component - that is sent in response to a "GET-CAPABILITY" command. - - Description: The value is one from a list of "CAR-NONE", "CAR-MIN", - or "CAR-FULL-1". If "CAR-FULL-1" is supplied then "CAR-MIN" is also - available. A "CAR-MIN" implementation only supported the - "DEFAULT-VCARS" property values listed in the "VCALSTORE" component - and a "CAR-MIN" implementation does not support the creation or - modification of "VCAR" components from the CUA. - - Formal Definition: The property is defined by the following notation: - - - car-level = "CAR-LEVEL" ":" other-params : car-level-values - - car-level-values = ( "CAR-NONE" / "CAR-MIN" / "CAR-FULL-1" - / other-levels ) - - other-levels = ; Any name published in an RFC for a "CAR-LEVEL" - ; property value. - - - Example: The following is an example of this property: - - - CAR-LEVEL:CAR-FULL-1 - - - -8.8 COMPONENTS Property - - Property Name: COMPONENTS - - Purpose: The property specifies a the list of components supported by - the endpoint. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - - - -Royer, et al. Expires July 12, 2004 [Page 62] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Conformance: The property can be specified in a "VREPLY" component in - response to a "GET-CAPABILITY" command. - - Description: A comma separated list of components supported by the - endpoint. If not in the list sent from the endpoint then they are not - supported by that endpoint. Sending an unsupported component results - in unpredictable results. This includes any components inside of - other components (VALARM for example). The recommended list is - "VCALSTORE,VCALENDAR,VREPLY,VAGENDA, - VEVENT,VALARM,VTIMEZONE,VJOURNAL,VTODO,VALARM - DAYLIGHT,STANDARD,VCAR,VRIGHT,VQUERY" - - Formal Definition: The property is defined by the following notation: - - - components = "COMPONENTS" other-params ":" comp-list CRLF - - ; All of these MUST BE supplied only once. - ; - comp-list-req = "VCALSTORE" "," "VCALENDAR" "," "VTIMEZONE" "," - "VREPLY" "," "VAGENDA" "," "STANDARD" "," - "DAYLIGHT" - - ; At least one MUST BE supplied. The same value - ; MUST NOT occur more than once. - ; - comp-list-min = ( "," "VEVENT") / ( "," "VTODO") / ( "," "VJOURNAL" ) - - ; The same value MUST NOT occur - ; more than once. If "VCAR" is supplied then - ' "VRIGHT" must be supplied. - ; - comp-list-opt = ( "," "VFREEBUSY" ) / ( "," "VALARM" ) - / ( "," "VCAR" ) / ( "," "VRIGHT" ) - / ( "," "VQUERY") / ( "," x-comp ) - / ( "," iana-comp ) - - comp-list = comp-list-req 1*3comp-list-min *(comp-list-opt) - - - Example: The following is an example of this property: - - - COMPONENTS:VCALSTORE,VCALENDAR,VREPLY,VAGENDA, - VEVENT,VALARM,VTIMEZONE,VJOURNAL,VTODO, - DAYLIGHT,STANDARD,VFREEBUSY,VCAR,VRIGHT,VQUERY - - - - - -Royer, et al. Expires July 12, 2004 [Page 63] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -8.9 CSID Property - - Property Name: CSID - - Purpose: The property specifies a the globally unique identifier for - the calendar store. - - Value Type: URI - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in a "VCALSTORE" - component. - - Description: The identifier MUST BE globally unique. Each CS needs - its own unique identifier. The "CSID" property is the official unique - identifier for the CS. If the [BEEP] 'serverName' attribute was - supplied in the [BEEP] 'start' message, then the CSID will be mapped - to the virtual host name supplied and the host name part of the CSID - MUST BE the same as the 'serverName' value. This allows one CS - implementation to service multiple virtual hosts. CS's are not - required to support virtual hosting. If a CS does not support virtual - hosting then it must ignore the [BEEP] 'serverName' attribute. - - Formal Definition: The property is defined by the following notation: - - - csid = "CSID" other-params ":" capurl CRLF - - - Example: The following is an example of this property: - - - CSID:cap://calendar.example.com - - - -8.10 DECREED Property - - Property Name: DECREED - - Purpose: This property specifies if an access right calendar - component is decreed or not. - - Value Type: BOOLEAN - - Property Parameters: Non-standard property parameters can be - - - -Royer, et al. Expires July 12, 2004 [Page 64] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - specified on this property. - - Conformance: This property MAY be specified once in a "VCAR" - component. - - Description: This property is used in the "VCAR" component to specify - whether the component is decreed or not. If the "DECREED" property - value is "true" then the CUA will be unable to change the contents of - the "VCAR" component and any attempt will fail with an error. - - Formal Definition: The property is defined by the following notation: - - - decreed = "DECREED" other-params ":" boolean CRLF - - - Example: The following is an example of this property: - - - DECREED:TRUE - - - -8.11 DEFAULT-CHARSET Property - - Property Name: DEFAULT-CHARSET - - Purpose: This property indicates the default charset. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in "VAGENDA" and - "VCALSTORE" calendar component. - - Description: In a "VAGENDA" component this property is used to - indicate the charset of calendar. If not specified, the default is - the first value in the "VCALSTORE" components "DEFAULT-CHARSET" - property value list. The value MUST BE an IANA registered character - set as defined in [CHARREG]. - - In a "VCALSTORE" component it is a comma separated list of charsets - supported by the CS. The first entry is the default entry for all - newly created "VAGENDA" components. The "UTF-8" value MUST BE in the - "VCALSTORE" component "DEFAULT-CHARSET" property list. All compliant - CAP implementations (CS and CUA) MUST support at least the "UTF-8" - - - -Royer, et al. Expires July 12, 2004 [Page 65] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - charset. - - If a charset name contains a comma (,), then that comma must be - backslashed escaped in the value. - - Formal Definition: The property is defined by the following notation: - - - default-charset = "DEFAULT-CHARSET" other-params ":" text - *( "," text) CRLF - - - Example: The following is an example of this property for a "VAGENDA" - component: - - - DEFAULT-CHARSET:Shift_JIS,UTF-8 - - - -8.12 DEFAULT-LOCALE Property - - Property Name: DEFAULT-LOCALE - - Purpose: This property specifies the default language for text - values. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in "VAGENDA" and - "VCALSTORE" components. - - Description: In a "VAGENDA" component, the "DEFAULT-LOCALE" property - is used to indicate the locale of the calendar. The full locale - SHOULD be used. The default and minimum locale is POSIX (aka the 'C' - locale). - - In a "VCALSTORE" component it is a comma separated list of locales - supported by the CS. The first value in the list is the default for - all newly created VAGENDAs. "POSIX" MUST BE in the list. - - Formal Definition: The property is defined by the following notation: - - - default-locale = "DEFAULT-LOCALE" other-params ":" language - - - -Royer, et al. Expires July 12, 2004 [Page 66] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - *( "," language) CRLF - - language = Text identifying a locale, as defined in [CHARPOL] - - - Example: The following is an example of this property: - - - DEFAULT-LOCALE:en-US.iso-8859-1,POSIX - - - -8.13 DEFAULT-TZID Property - - Property Name: DEFAULT-TZID - - Purpose: This property specifies the text value that specifies the - time zones. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property may be specified once in a "VAGENDA" and - "VCALSTORE" components. - - Description: A multi valued property that lists the known time zones. - The first is the default. Where "TZID" property values are the same - as the "TZID" property as defined in [iCAL]. - - If in a "VCALSTORE" component it is a comma separated list of TZIDs - known to the CS. The entry is used as the default TZID list for all - newly created calendars. The list MUST contain at least "UTC". A - "VCALSTORE" components MUST have one "VTIMEZONE" component contained - in it for each value in the "DEFAULT-TZID" property value. - - If in a "VAGENDA" component it is a comma separated list of "TZID" - property values naming the time zones known to the calendar. The - first time zone in the list is the default and is used as the - localtime for objects that contain a date or date-time value without - a time zone. All "VAGENDA" components MUST have one "VTIMEZONE" - component contained for each value in the "DEFAULT-TZID" property - value. - - If a "TZID" property value contains a comma (,), the comma must be - backslash escaped. - - - - -Royer, et al. Expires July 12, 2004 [Page 67] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Formal Definition: This property is defined by the following - notation: - - - default-tzid = "DEFAULT-TZID" other-params - ":" [tzidprefix] text - *("," [tzidprefix] text) CRLF - - - Example: The following is an example of this property: - - - DEFAULT-TZID:US/Mountain,UTC - - - -8.14 DEFAULT-VCARS Property - - Property Name: DEFAULT-VCARS - - Purpose: This property is used to specify the "CARID" property ids of - the default "VCAR" components for newly created "VAGENDA" components. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property MUST BE specified in "VCALSTORE" calendar - component and MUST at least specify the following values: - "READBUSYTIMEINFO", "REQUESTONLY", "UPDATEPARTSTATUS", and - "DEFAULTOWNER". - - Description: This property is used in the "VCALSTORE" component to - specify the "CARID" value of the "VCAR" components that MUST BE - copied into now "VAGENDA" components at creation time by the CS. All - "DEFAULT-VCAR" values must have "VCARS" components stored in the - "VCALSTORE". - - Formal Definition: The property is defined by the following notation: - - - def-vcars = "DEFAULT-VCARS" other-params ":" text - *( "," text ) CRLF - - - Example: The following is an example of this property: - - - - -Royer, et al. Expires July 12, 2004 [Page 68] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY, - UPDATEPARTSTATUS,DEFAULTOWNER - - - -8.15 DENY Property - - Property Name: DENY - - Purpose: This property identifies the UPN(s) being denied access in - the "VRIGHT" component. - - Value Type: UPN-FILTER - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in "VRIGHT" components. - - Description: This property is used in the "VRIGHT" component to - define the CU or UG being denied access. - - Formal Definition: The property is defined by the following notation: - - - deny = "DENY" other-params ":" upn-filter CRLF - - - Example: The following are examples of this property: - - - DENY:* - - DENY:bob@example.com - - - -8.16 EXPAND property - - Property Name: EXPAND - - Purpose: This property is to notify the CS if it should or should not - expand any component with recurrence rules into multiple instances in - a query reply. - - Value Type: BOOLEAN - - Property Parameters: Non-standard property parameters can be - - - -Royer, et al. Expires July 12, 2004 [Page 69] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - specified on this property. - - Conformance: This property can be specified in "VQUERY" components. - - Description: If a CUA wishes to see all of the instances of a - recurring component the CUA sets EXPAND=TRUE in the "VQUERY" - component. If not specified, the default is FALSE. Note that if the - CS has its "RECUR-EXPAND" CS property value set to false then the - "EXPAND" property will be ignored and the result will be as if the - "EXPAND" value was set to false. The results will be bounded by any - date range or other limits in the query. - - Formal Definition: The property is defined by the following notation: - - - expand = "EXPAND" other-params ":" ("TRUE" / "FALSE") CRLF - - - Example: The following are examples of this property: - - - EXPAND:FALSE - EXPAND:TRUE - - - -8.17 GRANT Property - - Property Name: GRANT - - Purpose: This property identifies the UPN(s) being granted access in - the "VRIGHT" component. - - Value Type: UPN-FILTER - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in "VRIGHT" calendar - components. - - Description: This property is used in the "VRIGHT" component to - specify the CU or UG being granted access. - - Formal Definition: The property is defined by the following notation: - - - grant = "GRANT" other-params ":" upn-filter CRLF - - - -Royer, et al. Expires July 12, 2004 [Page 70] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Example: The following are examples of this property: - - - GRANT:* - - GRANT:bob@example.com - - - -8.18 ITIP-VERSION Property - - Property Name: ITIP-VERSION - - Purpose: This property specifies the version of ITIP supported. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property is specified in the "VREPLY" component - that is sent in response to a "GET-CAPABILITY" command. - - Description: This specifies the version of ITIP that the endpoint - supports. The list is a comma separated list of RFC numbers - supported. The list MUST contain at least 2446 to mean [iTIP] - - Formal Definition: The property is defined by the following notation: - - - itip-version = "ITIP-VERSION" other-params ":" text CRLF - - - Example: The following are examples of this property: - - - ITIP-VERSION:2446 - - - -8.19 MAX-COMP-SIZE Property - - Property Name: MAX-COMP-SIZE - - Purpose: This property specifies the largest size of any object - accepted. - - Value Type: TEXT - - - -Royer, et al. Expires July 12, 2004 [Page 71] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property is specified in the "VREPLY" component - that is sent in response to a "GET-CAPABILITY" command. - - Description: A positive integer value that specifies the size of the - largest iCalendar object that can be accepted in octets. Objects - larger than this will be rejected. A value of zero (0) means no - limit. This is also the maximum value of any [BEEP] payload that will - be accepted or sent. - - Formal Definition: The property is defined by the following notation: - - - max-comp-size = "MAX-COMP-SIZE" other-params ":" posint0 CRLF - - - Example: The following are examples of this property: - - - MAX-COMP-SIZE:1024 - - - -8.20 MAXDATE Property - - Property Name: MAXDATE - - Purpose: This property specifies the date/time in the future beyond - which the CS or CUA cannot represent. - - Value Type: DATE-TIME - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in the "VCALSTORE" - component. - - Description: The date and time MUST BE a UTC value and end with 'Z'. - - Formal Definition: The property is defined by the following notation: - - - maxdate = "MAXDATE" other-params ":" date-time CRLF - - - - - -Royer, et al. Expires July 12, 2004 [Page 72] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Example: The following is an example of this property: - - - MAXDATE:20990101T000000Z - - - -8.21 MINDATE Property - - Property Name: MINDATE - - Purpose: This property specifies the date/time in the past prior to - which the server cannot represent. - - Value Type: DATE-TIME - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in the "VCALSTORE" - component. - - Description: The date and time MUST BE a UTC value and end with 'Z'. - - Formal Definition: The property is defined by the following notation: - - - mindate = "MINDATE" other-params ":" date-time CRLF - - - Example: The following is an example of this property: - - - MINDATE:19710101T000000Z - - - -8.22 MULTIPART Property - - Property Name: MULTIPART - - Purpose: This property provides a comma separated list of supported - MIME multipart types supported by the sender. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - - -Royer, et al. Expires July 12, 2004 [Page 73] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Conformance: This property is specified in the "VREPLY" component - that is sent in response to a "GET-CAPABILITY" command. - - Description: This property is used in the in the "GET-CAPABILITY" - command reply to indicated the MIME multipart types supported. A CS - and CUA SHOULD support all registered MIME multipart types. - - Formal Definition: The property is defined by the following notation: - - - mname = "MULTIPART" other-params ":" text *( "," text) CRLF - - - Example: The following is an example of this property: - - - MULTIPART:related,alternate,mixed - - - -8.23 NAME Property - - Property Name: NAME - - Purpose: This property provides a localizable display name for a - component. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in a component. - - Description: This property is used in the in component to specify a - localizable display name. If more than one "NAME" properties are in a - component, then they MUST have unique "LANG" parameters. If the - "LANG" parameter is not supplied, then it defaults to the "VAGENDA" - components "DEFAULT-LOCALE" first value as the default. If the - component is a "VAGENDA" then the default value is the "VAGENDA"s - components "DEFAULT-LOCALE" first value as the default. A "VCALSTORE" - components "DEFAULT-LOCALE" first value is the default if the - component is stored at the "VCALSTORE" level. - - Formal Definition: The property is defined by the following notation: - - - name = "NAME" nameparam ":" text CRLF - - - -Royer, et al. Expires July 12, 2004 [Page 74] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - nameparam = other-params [ ";" languageparam ] other-params - - languageparam = ; As defined in [iCAL]. - - - Example: The following is an example of this property: - - - NAME:Restrict Guests From Creating VALARMs On VEVENTs - - - -8.24 OWNER Property - - Property Name: OWNER - - Purpose: The property specifies an owner of the component. - - Value Type: UPN - - Property Parameters: Non-standard, alternate text representation and - language property parameters can be specified on this property. - - Conformance: The property MUST BE specified at in a "VAGENDA" - component. - - Description: A multi-instanced property indicating the calendar - owner. - - Formal Definition: The property is defined by the following notation: - - - owner = "OWNER" other-params ":" upn CRLF - - - Example: The following is an example of this property: - - - OWNER:jsmith@example.com - OWNER:jdough@example.com - - - -8.25 PERMISSION Property - - Property Name: PERMISSION - - Purpose: This property defines a permission that is granted or denied - - - -Royer, et al. Expires July 12, 2004 [Page 75] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - in a "VRIGHT" component. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in "VRIGHT" components. - - Description: This property is used in the "VRIGHT" component to - define a permission that is granted or denied. - - Formal Definition: The property is defined by the following notation: - - - perm = "PERMISSION" other-params ":" permvalue CRLF - - permvalue = ( "SEARCH" / "CREATE" / "DELETE" - / "MODIFY" / "MOVE" / all - / iana-cmd / x-cmd ) - - all = "*" - - iana-cmd = ; Any command registered by IANA directly or - ; included in an RFC that may be applied as - ; a command. - - x-cmd = ; Any experimental command that starts with - ; "x-" or "X-". - - - Example: The following is an example of this property: - - - PERMISSION:SEARCH - - - -8.26 QUERY property - - Property Name: QUERY - - Purpose: Specifies the query for the component. - - Value Type: CAL-QUERY - - Property Parameters: Non-standard property parameters can be - specified on this property. - - - -Royer, et al. Expires July 12, 2004 [Page 76] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Conformance: This property can be specified in "VQUERY" components. - - Description: A "QUERY" is used to specify the "CAL-QUERY" (Section - 6.1.1 for the query. - - Formal Definition: The property is defined by the following notation: - - - query = "QUERY" other-params ":" cal-query CRLF - - - Example: The following is an example of this property: - - - QUERY:SELECT * FROM VEVENT - - - -8.27 QUERYID property - - Property Name: QUERYID - - Purpose: Specifies a unique ID for a query in the targeted container. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters are specified - on this property. - - Conformance: This property can be specified in "VQUERY" components. - - Description: A "QUERYID" property is used to specify the unique id - for a query. A "QUERYID" property value is unique per container. - - Formal Definition: The property is defined by the following notation: - - - queryid = "QUERYID" other-params ":" text CRLF - - - Example: The following are examples of this property: - - - QUERYID:Any Text String - QUERYID:fetchUnProcessed - - - - - - -Royer, et al. Expires July 12, 2004 [Page 77] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -8.28 REQUEST-STATUS property - - This description is a revision of the "REQUEST-STATUS" property for - [iCAL] objects with a "VCALENDAR" component "VERSION" property that - includes a value of "2.0" or newer. The 'statdesc' is optional and - the 'extdata' may be included when 'statdesc' is not provided. - - - rstatus = "REQUEST-STATUS" rstatparam ":" - statcode ";" [ statdesc ] ";" [ extdata ] - - rstatparam = other-params [";" languageparam] other-params - - statcode = 1*DIGIT *("." 1*DIGIT) - ;Hierarchical, numeric return status code - - statdesc = text - ;An optional textual status description, content is - ;decided by the implementer. May be empty. - - extdata = text - ; Textual exception data. For example, the offending - ; property name and value or complete property line. - - - Example: The following are some possible examples of this property. - The COMMA and SEMICOLON separator characters in the property value - are BACKSLASH character escaped because they appear in a text value. - - - REQUEST-STATUS:2.0;Success - - REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 - - REQUEST-STATUS:2.8; Success\, repeating VEVENT ignored. Scheduled - as a single VEVENT.;RRULE:FREQ=WEEKLY;INTERVAL=2 - - REQUEST-STATUS:4.1;Time conflict. Date/time is busy. - - REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: - MAILTO:jsmith@example.com - - REQUEST-STATUS:3.7;;ATTENDEE:MAILTO:jsmith@example.com - - REQUEST-STATUS:10.4;Help! That really shouldn't have happened. - - - - - - -Royer, et al. Expires July 12, 2004 [Page 78] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -8.29 QUERY-LEVEL Property - - Property Name: QUERY-LEVEL - - Purpose: This property specifies the level of query supported. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in the "VREPLY" component - in response to a "GET-CAPABILITY" command. - - Description: Indicates level of query support. CAL-QL-NONE is for - CS's that allow ITIP methods only to be deposited and nothing else. - - Formal Definition: The property is defined by the following notation: - - - query-level = "QUERY-LEVEL" other-params - ":" ( "CAL-QL-1" / "CAL-QL-NONE") CRLF - - - Example: The following is an example of this property: - - - QUERY-LEVEL:CAL-QL-1 - - - -8.30 RECUR-ACCEPTED Property - - Property Name: RECUR-ACCEPTED - - Purpose: This property specifies if the endpoint supports recurring - instances. - - Value Type: BOOLEAN - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in the "VREPLY" component - in response to a "GET-CAPABILITY" command. - - Description: Indicates if recurrence rules are supported. If FALSE - then the endpoint can not process any kind of recurring rules. - - - -Royer, et al. Expires July 12, 2004 [Page 79] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Formal Definition: The property is defined by the following notation: - - - recur-accepted = "RECUR-ACCEPTED" other-params ":" boolean CRLF - - - Example: The following is an example of this property: - - - RECUR-ACCEPTED:TRUE - RECUR-ACCEPTED:FALSE - - - -8.31 RECUR-LIMIT Property - - Property Name: RECUR-LIMIT - - Purpose: This property specifies the maximum number of instances the - endpoint will expand instances into at query or storage time. - - Value Type: INTEGER - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in the "VREPLY" component - in response to a "GET-CAPABILITY" command. - - Description: For implementations that have the "STORES-EXPANDED" - value set to TRUE, then this value specifies the maximum number of - instances that will be stored and fetched. For all implementations - this is the maximum number of instances that will be returned when - the "EXPAND" parameter is specified as TRUE and the results contain a - infinite or large number of recurring instances. - - Formal Definition: The property is defined by the following notation: - - - recur-limit = "RECUR-LIMIT" other-params ":" posint1 CRLF - - - Example: The following is an example of this property: - - - RECUR-LIMIT:1000 - - - - - -Royer, et al. Expires July 12, 2004 [Page 80] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -8.32 RECUR-EXPAND Property - - Property Name: RECUR-EXPAND - - Purpose: This property specifies if the endpoint can expand - recurrences into multiple objects. - - Value Type: BOOLEAN - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in the "VREPLY" component - in response to a "GET-CAPABILITY" command. - - Description: If TRUE then the endpoint can expand an object into - multiple instances as defined by its recurrence rules when the - "EXPAND" property is supplied. If FALSE then the endpoint ignores the - "EXPAND" property. - - Formal Definition: The property is defined by the following notation: - - - recur-expand = "RECUR-EXPAND" other-params ":" boolean CRLF - - - Example: The following is an example of this property: - - - RECUR-EXPAND:TRUE - RECUR-EXPAND:FALSE - - - -8.33 RESTRICTION Property - - Property Name: RESTRICTION - - Purpose: This property defines restrictions on the result value of - new or existing components. - - Value Type: CAL-QUERY - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in "VRIGHT" components, - but only when the "PERMISSION" property is set to "CREATE", "MODIFY", - - - -Royer, et al. Expires July 12, 2004 [Page 81] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - or "*" property value. - - Description: This property is used in the "VRIGHT" component to - define restrictions on the components that can be written (i.e., by - using the "CREATE" or "MOVE" commands) as well as on the values that - may take existent calendar store properties, calendar properties, - components, and properties (i.e., by using the "MODIFY" command). - Accepted values MUST match any specified "RESTRICTION" property - values. - - Formal Definition: The property is defined by the following notation: - - - restrict = "RESTRICTION" other-params ":" cal-query CRLF - - - Example: The following are examples of this property: - - - RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST' - - RESTRICTION:SELECT * FROM VEVENT WHERE - SELF() IN ORGANIZER - - RESTRICTION:SELECT * FROM VEVENT WHERE 'BUSINESS' IN - CATEGORIES - - - -8.34 SCOPE Property - - Property Name: SCOPE - - Purpose: This property identifies the objects in the CS to which the - access rights applies. - - Value Type: CAL-QUERY - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in "VRIGHT" components. - - Description: This property is used in the "VRIGHT" component to - define the set of objects subject to the access right being defined. - - Formal Definition: The property is defined by the following notation: - - - - -Royer, et al. Expires July 12, 2004 [Page 82] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - scope = "SCOPE" other-params ":" cal-query CRLF - - - Example: The following is an example of this property: - - - SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC' - - - -8.35 STORES-EXPANDED Property - - Property Name: STORES-EXPANDED - - Purpose: This property specifies if the sending endpoint expands - recurrence rules prior to storing them into the CS. - - Value Type: BOOLEAN - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in a "VREPLY" component - in response to a "GET-CAPABILITY" command. - - Description: If the value is TRUE then the endpoint expands - recurrence rules and then stores the results into the CS. If this is - TRUE then the "RECUR-LIMIT" property is significant because an - infinitely recurring appointment will be stored no more than - "RECUR-LIMIT" property values into the CS and all other instances - will be lost. - - Formal Definition: The property is specified by the following - notation: - - - - stores-expanded = "STORES-EXPANDED" other-params ":" boolean CRLF - - - The following is an example of this property: - - - - STORES-EXPANDED:TRUE - STORES-EXPANDED:FALSE - - - - - -Royer, et al. Expires July 12, 2004 [Page 83] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -8.36 TARGET Property - - Property Name: TARGET - - Purpose: This property defines the container that the command that is - issued will act upon. Its value is a capurl as defined in Section 5. - - Value Type: URI - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in a command component. - - Description: This property value is used to specify the container - that the command will effect. When used in a command, the command - will be performed on the container which has a capurl matching the - value. - - Formal Definition: The property is specified by the following - notation: - - - - target = "TARGET" other-params ":" ( capurl / relcalid ) CRLF - - - The following is an example of this property: - - - - TARGET:cap://mycal.example.com - TARGET:SomeRelCalid - - - -8.37 TRANSP Property - - Property Name: TRANSP - - Purpose: This property defines whether an component is transparent or - not to busy time searches. This is a modification to [iCAL] "TRANSP" - property in that it adds some values. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - - -Royer, et al. Expires July 12, 2004 [Page 84] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Conformance: This property can be specified in a component. - - Description: Time Transparency is the characteristic of an object - that determines whether it appears to consume time on a calendar. - Objects that consume actual time for the individual or resource - associated with the calendar SHOULD be recorded as "OPAQUE", allowing - them to be detected by free-busy time searches. Other objects, which - do not take up the individual's (or resource's) time SHOULD be - recorded as "TRANSPARENT", making them invisible to free-busy time - searches. - - Formal Definition: The property is specified by the following - notation: - - - transp = "TRANSP" other-params ":" transvalue CRLF - - transvalue - = "OPAQUE" ;Blocks or opaque on busy time searches. - / "TRANSPARENT" ;Transparent on busy time searches. - - / "TRANSPARENT-NOCONFLICT" ; Transparent on busy time - ; searches and no other OPAQUE or OPAQUE-NOCONFLICT objects - ; can overlap it. - - / "OPAQUE-NOCONFLICT" ; Opaque on busy time - ; searches and no other OPAQUE or OPAQUE-NOCONFLICT objects - ; can overlap it. - ; - ;Default value is OPAQUE - - - The following is an example of this property for an object that is - opaque or blocks on free/busy time searches plus no other object can - overlap it: - - - - TRANSP:OPAQUE-NOCONFLICT - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 85] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -9. New Components - -9.1 VAGENDA Component - - Component Name: VAGENDA - - Purpose: Provide a grouping of properties that defines an agenda. - - Formal Definition: There are two formats of the "VAGENDA" component. - (1) When it is being created, and (2) how it exists in the - "VCALSTORE" component. - - A "VAGENDA" component in a "VCALSTORE" component is defined by the - following notes and ABNF notation: - - CALSCALE - The value MUST BE from the "VCALSTORE" "CALSCALE" - property list. The default is the first entry in the VCALSTORE - CALSCALE list. - - CREATED - The timestamp of the calendar's create date. This is a - READ ONLY property in a "VAGENDA". - - LAST-MODIFIED - The timestamp of any change to the "VAGENDA" - properties or when any component was last created, modified, or - deleted. - - - - agenda = "BEGIN" ":" "VAGENDA" CRLF - agendaprop - *(icalobject) ; as defined in [iCAL] - "END" ":" "VAGENDA" CRLF - - agendaprop = *( - ; The following MUST occur exactly once. - ; - allow-conflict / relcalid / calscale / created - / default-charset / default-locale - / default-tzid / last-mod / - - ; The following MUST occur at least once. - ; and the value MUST NOT be empty. - - / owner - - ; The following are optional, - ; and MAY occur more than once. - - - - -Royer, et al. Expires July 12, 2004 [Page 86] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - / name / related-to / other-props / x-comp - ) - - - When creating a VAGENDA, use the following notation: - - - agendac = "BEGIN" ":" "VAGENDA" CRLF - agendacprop - *(icalobject) ; as defined in [iCAL] - "END" ":" "VAGENDA" CRLF - - agendacprop = *( - ; The following MUST occur exactly once. - ; - allow-conflict / relcalid / calscale - / default-charset / default-locale - / default-tzid / - - ; The following MUST occur at least once. - ; and the value MUST NOT be empty. - ; - / owner - - ; The following are optional, - ; and MAY occur more than once. - ; - / name / related-to / other-props / x-comp - ) - - - To fetch all of the properties from the targeted "VAGENDA" component. - This does not fetch any components: - - - - SELECT * FROM VAGENDA - - - To fetch all of the properties from the targeted VAGENDA and all of - the contained components, use the special '*.*' value: - - - - SELECT *.* FROM VAGENDA - - - - - - -Royer, et al. Expires July 12, 2004 [Page 87] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -9.2 VCALSTORE Component - - Component Name: VCALSTORE - - Purpose: Provide a grouping of properties that defines a calendar - store. - - Formal Definition: A "VCALSTORE" component is defined by the - following table and ABNF notation. The creation of a "VCALSTORE" - component is an administrative task and not part of the CAP protocol. - - The following are notes to some of the properties in the "VCALSTORE" - component. - - CALSCALE - A comma separated list of CALSCALEs supported by this CS. - All "VAGENDA" component calendar CALSCALE properties MUST BE from - this list. This list MUST contain at least "GREGORIAN". The - default for newly created "VAGENDA" components is the first entry. - - RELATED-TO - This is a multiple instance property. There must be a - "RELATED-TO" property MUST for each of the "VAGENDA" components - contained in the "VCALSTORE" component each with the "RELTYPE" - parameter value set to "CHILD". Other "RELATED-TO" properties may - be included. - - CREATED - The timestamp of the CS creation time. This is a READ ONLY - property. - - CSID - The CSID of this calendar store. MUST NOT be empty. How this - property is set in the VCALSTORE is an administrative or - implementation specific issue and is not covered in CAP. This is a - READ ONLY property. A suggested value is the fully qualified host - name or a fully qualified virtual host name supported by the - system. - - LAST-MODIFIED - The timestamp when the Properties of the "VCALSTORE" - component were last updated or calendars were created or deleted. - This is a READ ONLY PROPERTY. - - - - calstorec = "BEGIN" ":" "VCALSTORE" CRLF - calstoreprop - *(vagendac) - "END" ":" "VCALSTORE" CRLF - - calstoreprop = *( - ; the following MUST occur exactly once - - - -Royer, et al. Expires July 12, 2004 [Page 88] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - allow-conflict / calscale / calmaster - / created / csid / default-charset - / default-locale / default-vcars - / default-tzid / last-mod / maxdate / mindate - - ; the following are optional, - ; and MAY occur more than once - - / name / related-to / other-props / x-comp - ) - - last-mod = ; As defined in [iCAL]. - - - To fetch all of the properties from the targeted VCALSTORE and not - fetch the calendars that it contains: - - - - SELECT * FROM VCALSTORE - - - To fetch all of the properties from the targeted "VCALSTORE" - component and all of the contained calendars and all of those - calendars contained properties and components, use the special '*.*' - value: - - - - SELECT *.* FROM VCALSTORE - - - -9.3 VCAR Component - - Component Name: VCAR - - Purpose: Provide a grouping of calendar access rights. - - Formal Definition: A "VCAR" component is defined by the following - notation: - - - carc = "BEGIN" ":" "VCAR" CRLF - carprop 1*rightc - "END" ":" "VCAR" CRLF - - carprop = 1*( - - - -Royer, et al. Expires July 12, 2004 [Page 89] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - ; 'carid' is REQUIRED, - ; but MUST NOT occur more than once - - carid / - - ; the following are OPTIONAL, - ; and MAY occur more than once - - name / decreed / other-props - ) - - - Description: A "VCAR" component is a grouping of properties, and - "VRIGHT" components, that represents access rights granted or denied - to UPNs. - - The "CARID" property specifies the local identifier for the "VCAR" - component. The "NAME" property specifies a localizable display name. - - Example: In the following example, the UPN "foo@example.com" is given - search access to the "DTSTART" and "DTEND" VEVENT properties. No - other access is specified: - - - BEGIN:VCAR - CARID:View Start and End Times - NAME:View Start and End Times - BEGIN:VRIGHT - GRANT:foo@example.com - PERMISSION:SEARCH - SCOPE:SELECT DTSTART,DTEND FROM VEVENT - END:VRIGHT - END:VCAR - - - In this example, all UPNs are given search access to "DTSTART" and - "DTEND" properties of VEVENT components. "All CUs and UGs" are - specified by the UPN value "*". Note that this enumerated UPN value - is not in quotes: - - - BEGIN:VCAR - CARID:ViewStartEnd2 - NAME:View Start and End Times 2 - BEGIN:VRIGHT - GRANT:* - PERMISSION:SEARCH - SCOPE:SELECT DTSTART,DTEND FROM VEVENT - - - -Royer, et al. Expires July 12, 2004 [Page 90] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - END:VRIGHT - END:VCAR - - - In these examples, full calendar access rights are given to the - CAL-OWNERS(), and a hypothetical administrator is given access rights - to specify calendar access rights. If no other rights are specified, - only these two UPNs can specify calendar access rights: - - - BEGIN:VCAR - CARID:some-id-3 - NAME:Only OWNER or ADMIN Settable VCARs - BEGIN:VRIGHT - GRANT:CAL-OWNERS() - PERMISSION:* - SCOPE:SELECT * FROM VAGENDA - END:VRIGHT - BEGIN:VRIGHT - GRANT:cal-admin@example.com - PERMISSION:* - SCOPE:SELECT * FROM VCAR - RESTRICTION:SELECT * FROM VCAR - END:VRIGHT - END:VCAR - - - In this example, rights to write, search, modify or delete calendar - access rights are denied to all UPNs. This example would disable - providing different access rights to the calendar store or calendar. - This calendar access right should be specified with great care, as it - removes the ability to change calendar access; even for the owner or - administrator. It could be used by small devices that do not support - the changing of any VCAR: - - - BEGIN:VCAR - CARID:VeryRestrictiveVCAR-2 - NAME:No CAR At All - BEGIN:VRIGHT - DENY:* - PERMISSION:* - SCOPE:SELECT * FROM VCAR - END:VRIGHT - END:VCAR - - - - - - -Royer, et al. Expires July 12, 2004 [Page 91] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -9.4 VRIGHT Component - - Component Name: "VRIGHT" - - Purpose: Provide a grouping of properties that describe an access - right (granted or denied). - - Formal Definition: A "VRIGHT" component is defined by the following - notation: - - - rightc = "BEGIN" ":" "VRIGHT" CRLF - rightprop - "END" ":" "VRIGHT" CRLF - - rightprop = 2*( - - ; either 'grant' or 'deny' MUST - ; occur at least once - ; and MAY occur more than once - - grant / deny / - - ; 'permission' MUST occur at least once - ; and MAY occur more than once - - permission / - - ; the following are optional, - ; and MAY occur more than once - - scope / restriction / other-props - - ) - - - Description: A "VRIGHT" component is a grouping of calendar access - right properties. - - The "GRANT" property specifies the UPN that is being granted access. - The "DENY" property specifies the UPN is being denied access. The - "PERMISSION" property specifies the actual permission being set. The - "SCOPE" property identifies the calendar store properties, calendar - properties, components, or properties to which the access right - applies. The "RESTRICTION" property specifies restriction on the - value that may take calendar store properties, calendar properties, - calendar components, and properties after a "CREATE" or "MODIFY" - command. Values MUST match all the instances of the "RESTRICTION" - - - -Royer, et al. Expires July 12, 2004 [Page 92] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - property to be valid. - -9.5 VREPLY Component - - Component Name: "VREPLY" - - Purpose: Provide a grouping of arbitrary properties and components - that are the data set result from an issued command. - - Formal Definition: A "VREPLY" component is defined by the following - notation: - - - replyc = "BEGIN" ":" "VREPLY" CRLF - any-prop-or-comp - "END" ":" "VREPLY" CRLF - - any-prop-or-comp = ; Zero or more iana or experimental - ; properties and components, in any order. - - - Description: Provide a grouping of arbitrary properties and - components that are the data set result from an issued command. - - A query can return a predictable set of arbitrary properties and - components. This component is used by query and other commands to - return data that does not fit into any other component. It may - contain any valid property or component, even if they are not - registered. - -9.6 VQUERY Component - - Component Name: VQUERY - - Purpose: A component describes a set of objects to be acted upon. - - Formal Definition: A "VQUERY" component is defined by the following - notation: - - - queryc = "BEGIN" ":" "VQUERY" CRLF - queryprop - "END" ":" "VCAR" CRLF - - queryprop = 1*( - - ; 'queryid' is OPTIONAL but MUST NOT occur - ; more than once. If the "TARGET" property - - - -Royer, et al. Expires July 12, 2004 [Page 93] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - ; is supplied then the "QUERYID" property - ; MUST BE supplied. - ; - queryid / target - - ; 'expand' is OPTIONAL but MUST NOT occur - ; more than once. - - expand - - ; the following are OPTIONAL, and MAY occur - ; more than once - ; - / name / other-props - - ; the following MUST occur at least once if - ; queryid is not supplied. - ; - / query - - ) - - - Description: A "VQUERY" contains properties that describe which - properties and components the CS is requested to act upon. - - The "QUERYID" property specifies the local identifier for a "VQUERY" - component. - - For a search, if the "TARGET" property is supplied in a "VQUERY" - component, then the CS is to search for the query in the CALID - supplied by the "TARGET" property value. - - For a create the "TARGET" property MUST NOT be supplied as the - destination container is already supplied in the "TARGET" property of - the "VCALENDAR" component. - - For examples, see Section 6.1.1. - - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 94] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -10. Commands and Responses - - CAP commands and responses are described in this section. - -10.1 CAP Commands (CMD) - - All commands are send using the CMD property. - - Property Name: CMD - - Purpose: The property defines the command to be sent. - - Value Type: TEXT - - Property Parameters: Non-standard, id, localize, latency, action or - options. - - Conformance: This property is the method used to specify the commands - to a CS and can exist in any object sent to the CS. - - Description: All of the commands to the CS are supplied in this - property. The "OPTIONS" parameter is overloaded and its meaning is - dependent on the CMD value supplied. - - Formal Definition: The property is defined by the following notation: - - - cmd = "CMD" ( - / abort-cmd - / continue-cmd - / create-cmd - / delete-cmd - / generate-uid-cmd - / get-capability-cmd - / identify-cmd - / modify-cmd - / move-cmd - / reply-cmd - / search-cmd - / set-locale-cmd - / iana-cmd - / x-cmd - ) CRLF - - option-value = paramtext ; As defined in [iCAL] - - - Calendaring commands allow a CUA to directly manipulate a calendar. - - - -Royer, et al. Expires July 12, 2004 [Page 95] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Calendar access rights can be granted or denied for any commands. - -10.1.1 Bounded Latency - - A CAP command can have an associated maximum latency time by - specifying the "LATENCY" parameter. If the command is unable to be - completed in the specified amount of time (as specified by the - "LATENCY" parameter value with an "ACTION" parameter set to the "ASK" - value), then a "TIMEOUT" command MUST BE sent on the same channel" to - which there MUST BE a an "ABORT" or a "CONTINUE" command reply. If - the CUA initiated the original command, then the CS would issue the - "TIMEOUT" command and the CUA would then have to issue an "ABORT" or - "CONTINUE" command. If the CS initiated the original command then the - CUA would have to issue the "TIMEOUT" and the CS would send the - "ABORT" or "CONTINUE". - - Upon receiving an "ABORT" command, the command must then be - terminated. Only the "ABORT", "TIMEOUT", "REPLY, and "CONTINUE" - commands can not be aborted. The "ABORT", "TIMEOUT", and "REPLY" - commands MUST NOT have latency set. - - Upon receiving a "CONTINUE" command the work continues as if it had - not been delayed or stopped. Note that a new latency time MAY BE - included in a "CONTINUE" command indicating to continue the original - command until the "LATENCY" parameter value expires or the results of - the original command can be returned. - - Both the "LATENCY" parameter and the "ACTION" parameter MUST BE - supplied to any "CMD" property, or nether can be added to the "CMD" - property. The "LATENCY" parameter MUST BE set to the maximum latency - time in seconds. The "ACTION" parameter accepts the following - values: "ASK" and "ABORT" parameters. - - If the maximum latency time is exceeded and the "ACTION" parameter is - set to the "ASK" value, then "TIMEOUT" command MUST BE sent. - Otherwise if the "ACTION" parameter is set to the "ABORT" value then - the command MUST BE terminated and return a REQUEST-STATUS code of - 2.0.3 for the original command. - - If a CS can both start sending the reply to a command and guarantee - that all of the results can be sent from a command (short of - something like network or power failure) prior to the "LATENCY" - timeout value then the "LATENCY" time has not expired. - - Example: - - In this example the initiator asks for the listeners capabilities. - - - - -Royer, et al. Expires July 12, 2004 [Page 96] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - I: Content-Type: text/calendar - I: - I: BEGIN:VCALENDAR - I: VERSION:2.0 - I: PRODID:The CUA's PRODID - I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:GET-CAPABILITY - I: END:VCALENDAR - - # After 3 seconds - - L: Content-Type: text/calendar - L: - L: BEGIN:VCALENDAR - L: PRODID:-//someone's prodid - L: VERSION:2.0 - L: CMD;ID=xyz12346:TIMEOUT - L: END:VCALENDAR - - - In order to continue and give the CS more time then the CUA would - issue a "CONTINUE" command: - - - I: Content-Type: text/calendar - I: - I: BEGIN:VCALENDAR - I: VERSION:2.0 - I: PRODID:-//someone's prodid - I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:CONTINUE - I: END:VCALENDAR - - L: Content-Type: text/calendar - L: - L: BEGIN:VCALENDAR - L: VERSION:2.0 - L: PRODID:-//someone's prodid - L: CMD;ID=xyz12346:REPLY - L: BEGIN:VREPLY - L: REQUEST-STATUS:2.0.3;Continued for 3 more seconds - L: END:VREPLY - L: END:VCALENDAR - - - Above the "2.0.3" status is returend because it is not an error, it - is a progress status sent in reply to the "CONTINUE" command. - - To abort the command and not wait any further then issue an "ABORT" - command: - - - -Royer, et al. Expires July 12, 2004 [Page 97] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - I: Content-Type: text/calendar - I: - I: BEGIN:VCALENDAR - I: VERSION:2.0 - I: PRODID:-//someone's prodid - I: CMD;ID=xyz12346:ABORT - I: END:VCALENDAR - - # Which would result in a 2.0.3 reply. - - L: Content-Type: text/calendar - L: - L: BEGIN:VCALENDAR - L: VERSION:2.0 - L: PRODID:-//someone's prodid - L: CMD;ID=xyz12346:REPLY - L: BEGIN:VREPLY - L: REQUEST-STATUS:2.0.3;Aborted As Requested. - L: END:VREPLY - L: END:VCALENDAR - - - If the "ACTION" value had been set to "ABORT", then the listiner - would send a "7.0" error on timeout in the reply to the command that - initiated the command that timed out. - -10.2 ABORT Command - - CMD: ABORT - - Purpose: The "ABORT" command is sent to request that the named or - only in process command be aborted. Latency MUST not be supplied with - the "ABORT" command. - - Formal Definition: An "ABORT" command is defined by the following - notation: - - - abort-cmd = abortparam ":" "ABORT" - - abortparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - id-param - / localize-param - - - - -Royer, et al. Expires July 12, 2004 [Page 98] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - ; the following is optional, - ; and MAY occur more than once - - / other-params - - ) - - The REPLY of any "ABORT" command is: - - - abort-reply = "BEGIN" ":" "VCALENDAR" CRLF - calprops - abort-vreply - "END" ":" "VCALENDAR" CRLF - - abort-vreply = "BEGIN" ":" "VREPLY" CRLF - request-status - other-props - "END" ":" "VREPLY" CRLF - - - -10.3 CONTINUE Command - - CMD: CONTINUE - - Purpose: The "CONTINUE" command is only sent after a "TIMEOUT" - command has been received to inform the other end of the session to - resume working on a command. - - Formal Definition: A "CONTINUE" command is defined by the following - notation: - - - continue-cmd = continueparam ":" "CONTINUE" - - continueparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - id-param - / localize-param - / latency-param - - ; the following MUST occur exactly once and only - ; when the latency-param has been supplied and - ; MUST NOT be supplied if the latency-param is - - - -Royer, et al. Expires July 12, 2004 [Page 99] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - ; not supplied. - - / action-param - - ; the following are optional, - ; and MAY occur more than once - - / other-params - ) - - The REPLY of any "CONTINUE" command is: - - - continue-reply = "BEGIN" ":" "VCALENDAR" CRLF - calprops - continue-vreply - "END" ":" "VCALENDAR" CRLF - - continue-vreply = "BEGIN" ":" "VREPLY" CRLF - request-status - other-props - "END" ":" "VREPLY" CRLF - - - -10.4 CREATE Command - - CMD: CREATE - - Purpose: The "CREATE" command is used to create one or more - iCalendar objects in the store in the "BOOKED" or "UNPROCESSED" - state. - - A CUA MAY send a "CREATE" command to a CS. The "CREATE" command MUST - BE implemented by all CSs. - - The CS MUST NOT send a "CREATE" command to any CUA. - - Formal Definition: A "CREATE" command is defined by the following - notation and the hierarchy restrictions as defined in Section 3.2: - - - create-cmd = createparam ":" "CREATE" - - createparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - - -Royer, et al. Expires July 12, 2004 [Page 100] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - id-param - / localize-param - / latency-param - - ; the following MUST occur exactly once and only - ; when the latency-param has been supplied and - ; MUST NOT be supplied if the latency-param is - ; not supplied. - - / action-param - - ; the following is optional, - ; and MAY occur more than once - - / other-params - ) - - - Response: - - One iCalendar object per TARGET property MUST BE returned. - - The REPLY of any "CREATE" command is: - - Restriction Table for the iCalendar section of a reply that contains - an iCalendar object is any valid [iTIP] response plus any from this - ABNF: - - - create-reply = "BEGIN" ":" "VCALENDAR" CRLF - creply-props - 1*(create-vreply) - "END" ":" "VCALENDAR" CRLF - - create-vreply = "BEGIN" ":" "VREPLY" CRLF - created-id - request-status - other-props - "END" ":" "VREPLY" CRLF - - ; Where the id is appropriate for the - ; type of object created: - ; - ; VAGENDA = relcalid - ; VALARM = sequence - ; VCAR = carid - ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid - ; VQUERY = queryid - - - -Royer, et al. Expires July 12, 2004 [Page 101] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - ; VTIMEZONE = tzid - ; x-component = x-id - ; - created-id = ( relcalid / carid / uid / queryid / - tzid / sequence / x-id) - - x-id = ; An ID for an x-component. - - creply-props = 4*( - ; These are REQUIRED and MUST NOT occur - ; more than once. - ; - prodid /version / target / reply-cmd - - ; These are optional, and may occur more - ; than once. - ; - other-props - - - For a "CREATE" command the "TARGET" property specifies the containers - where the components will be created. - - If the iCalendar object being created does not have a "METHOD" - property, then is not an [iTIP] object, then its state will be - "BOOKED". Use the "DELETE" command to set the state of an object to - the "DELETED" state (tagged for deletion). A CUA can not use the - "CREATE" command to create an object in the "DELETED" state. - - If the intention is to book an [iTIP] object then the "METHOD" - property MUST NOT BE supplied. Otherwise any [iTIP] object MUST have - a valid [iTIP] "METHOD" property value and it is a scheduling request - being deposited into the CS and will have its state set to - "UNPROCESSED" state. - - ABNF for a "CREATE" object is: - - - create-object = "BEGIN" ":" "VCALENDAR" CRLF - ; If 'calprops' contain the "METHOD" property - ; then this 'create-object' component MUST - ; conform to [iTIP] restrictions. - ; - ; calprops MUST include 'create-cmd' - ; - calprops - other-props - 1*(create-comp) - - - -Royer, et al. Expires July 12, 2004 [Page 102] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - "END" ":" "VCALENDAR" CRLF - - ; NOTE: The 'VCALSTORE' component is not included in - ; 'create-comp' as it is out of scope for CAP to create - ; a new CS. - ; - create-comp = agendac / carc / queryc - / timezonec / freebusyc - / eventc / todoc / journalc - / iana-comp / x-component - - - In the following example two new top level "VAGENDA" components are - created. Note that the "CSID" value of the server is cal.example.com - which is where the new "VAGENDA" components are going to be created. - - - C: Content-Type: text/calendar - C: - C: BEGIN:VCALENDAR - C: PRODID:-//someone's prodid - C: VERSION:2.0 - C: CMD;ID=creation01:CREATE - C: TARGET:cal.example.com - C: BEGIN:VAGENDA <- data for 1st new calendar - C: CALID:relcalz1 - C: NAME;LANGUAGE=en_US:Bill's Soccer Team - C: OWNER:bill - C: CALMASTER:mailto:bill@example.com - C: TZID:US/Pacific - C: END:VAGENDA - C: BEGIN:VAGENDA <- data for 2nd new calendar - C: CALID:relcalz2 - C: NAME;LANGUAGE=EN-us:Mary's personal calendar - C: OWNER:mary - C: CALMASTER:mailto:mary@example.com - C: TZID:US/Pacific - C: END:VAGENDA - C: END:VCALENDAR - - S: Content-Type: text/calendar - S: - S: BEGIN:VCALENDAR - S: VERSION:2.0 - S: PRODID:-//someone's prodid - S: CMD;ID=creation01:REPLY - S: TARGET:cal.example.com - S: BEGIN:VREPLY <- Reply for 1st calendar create - - - -Royer, et al. Expires July 12, 2004 [Page 103] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - S: CALID:relcalz1 - S: REQUEST-STATUS:2.0 - S: END:REPLY - S: BEGIN:VREPLY <- Reply for 2nd calendar create - S: CALID:relcalz2 - S: REQUEST-STATUS:2.0 - S: END:VREPLY - S: END:VCALENDAR - - - To create a new component in multiple containers simply name all of - the containers in the "TARGET" in the create command. Here a new - "VEVENT" component is created in two TARGET components. In this - example, the "VEVENT" component is one new [iTIP] "REQUEST" to be - stored in two calendars. The results would be iCalendar objects that - conform to the [iTIP] replies as defined in [iTIP]. - - This example shows two [iTIP] "VEVENT" components being created in - each of the two supplied "TARGET" properties and as it contains the - "METHOD" property they will be stored in the "UNPROCESSED" state: - - - C: Content-Type: text/calendar - C: - C: BEGIN:VCALENDAR - C: VERSION:2.0 - C: PRODID:-//someone's prodid - C: CMD;ID=creation02:CREATE - C: METHOD:REQUEST - C: TARGET:relcalz1 - C: TARGET:relcalz2 - C: BEGIN:VEVENT - C: DTSTART:20030307T180000Z - C: UID:FirstInThisExample-1 - C: DTEND:20030307T190000Z - C: SUMMARY:Important Meeting - C: END:VEVENT - C: BEGIN:VEVENT - C: DTSTART:20040307T180000Z - C: UID:SecondInThisExample-2 - C: DTEND:20040307T190000Z - C: SUMMARY:Important Meeting - C: END:VEVENT - C: END:VCALENDAR - - - The CS sends the "VREPLY" commands in separate MIME objects, one per - supplied "TARGET" property value. - - - -Royer, et al. Expires July 12, 2004 [Page 104] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - S: Content-Type: text/calendar - S: - S: BEGIN:VCALENDAR - S: VERSION:2.0 - S: PRODID:-//someone's prodid - S: CMD;ID=creation02:REPLY - S: TARGET:relcalz1 <- 1st TARGET listed. - S: BEGIN:REPLY <- Reply for 1st VEVENT create in 1st TARGET. - S: UID:FirstInThisExample-1 - S: REQUEST-STATUS:2.0 - S: END:VREPLY - S: BEGIN:REPLY <- Reply for 2nd VEVENT crate in 1st TARGET. - S: UID:SecondInThisExample-2 - S: REQUEST-STATUS:2.0 - S: END:VREPLY - S: END:VCALENDAR - - - And the second reply for the 2nd TARGET: - - - S: Content-Type: text/calendar - S: - S: BEGIN:VCALENDAR - S: VERSION:2.0 - S: PRODID:-//someone's prodid - S: CMD;ID=creation02:REPLY - S: TARGET:relcalz2 <- 2nd TARGET listed - S: BEGIN:REPLY <- Reply for 1st VEVENT create in 2nd TARGET. - S: UID:FirstInThisExample-1 - S: REQUEST-STATUS:2.0 - S: END:VREPLY - S: BEGIN:REPLY <- Reply for 2nd VEVENT crate in 2nd TARGET. - S: UID:SecondInThisExample-2 - S: REQUEST-STATUS:2.0 - S: END:VREPLY - S: END:VCALENDAR - - - -10.5 DELETE Command - - CMD: DELETE - - Purpose: The "DELETE" command physically removes the QUERY result - from the store or marks it for deletion. - - A CUA MAY send a "DELETE" command to a CS. The "DELETE" command MUST - - - -Royer, et al. Expires July 12, 2004 [Page 105] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - BE implemented by all CSs. - - The CS MUST NOT send a "DELETE" command to any CUA. - - Formal Definition: A "DELETE" command is defined by the following - notation: - - - delete-cmd = deleteparam ":" "DELETE" - - deleteparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - ; - id-param - / localize-param - / latency-param - / option-param "MARK" - - ; The following MUST occur exactly once and only - ; when the latency-param has been supplied and - ; MUST NOT be supplied if the latency-param is - ; not supplied. - ; - / action-param - - ; the following is optional, - ; and MAY occur more than once - ; - / other-params - ) - - - The "DELETE" command is used to delete calendars or components. The - included "VQUERY" component(s) specifies the container(s) to delete. - - If a component is to be marked for delete and not physically removed, - then include the "OPTIONS" parameter with its value set to the "MARK" - value in order to alter its state to "DELETED". - - When components are deleted, only the top most component - "REQUEST-STATUS" properties are returned. No "REQUEST-STATUS" - properties are returned for components inside of the selected - components. There MUST BE one "VREPLY" component returned for each - object that is deleted or marked for delete. Note that if no "VREPLY" - components are returned then nothing matched and nothing was deleted. - - - - -Royer, et al. Expires July 12, 2004 [Page 106] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Restriction Table for the "REPLY" command for any "DELETE" command. - - - delete-reply = "BEGIN" ":" "VCALENDAR" CRLF - calprops ; MUST include 'reply-cmd' - *(delete-vreply) - "END" ":" "VCALENDAR" CRLF - - - delete-vreply = "BEGIN" ":" "VREPLY" CRLF - deleted-id - request-status - "END" ":" "VREPLY" CRLF - - ; Where the id is appropriate for the - ; type of object deleted: - ; - ; VAGENDA = relcalid - ; VCAR = carid - ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid - ; VQUERY = queryid - ; ALARM = sequence - ; VTIMEZONE = tzid - ; x-component = x-id - ; An instance = uid recurid - ; - deleted-id = ( relcalid / carid / uid / uid recurid - / queryid / tzid / sequence / x-id ) - - - Example to delete a "VEVENT" component with "UID" value of - 'abcd12345' from the calendar "relcald-22" from the current CS: - - - C: Content-Type: text/calendar - C: - C: BEGIN:VCALENDAR - C: TARGET:relcalid-22 - C: CMD;ID:"random but unique per CUA":DELETE - C: BEGIN:VQUERY - C: QUERY:SELECT VEVENT FROM VAGENDA WHERE UID = 'abcd12345' - C: END:VQUERY - C: END:VCALENDAR - - S: BEGIN:VCALENAR - S: TARGET:relcalid-22 - S: CMD;ID:"random but unique per CUA":REPLY - S: BEGIN:VREPLY - - - -Royer, et al. Expires July 12, 2004 [Page 107] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - S: UID:abcd12345 - S: REQUEST-STATUS:3.0 - S: END:VREPLY - S: END:VCALENDAR - - - One or more iCalendar objects will be returned that contain a - "REQUEST-STATUS" properties for the deleted components. There could - have been more than one component deleted. Any booked and any number - of unprocessed [iTIP] scheduling components that matched the QUERY - value in the above example. Each unique "METHOD" property value that - was deleted from the store MUST BE in a separate iCalendar object. - This is because only one "METHOD" property is allowed in a single - "VCALENDAR" BEGIN/END block. - -10.6 GENERATE-UID Command - - CMD: GENERATE-UID - - Purpose: The "GENERATE-UID" command returns one or more unique - identifiers which MUST BE globally unique. - - The "GENERATE-UID" command MAY BE sent to any CS. The "GENERATE-UID" - command MUST BE implemented by all CSs. - - The "GENERATE-UID" command MUST NOT be sent to a CUA. - - Formal Definition: A "GENERATE-UID" command is defined by the - following notation: - - - generate-uid-cmd = genuidparam ":" "GENERATE-UID" - - genuidparam = *( - - ; The following are optional, - ; but MUST NOT occur more than once. - - id-param - / localize-param - / latency-param - - ; The following MUST occur exactly once and only - ; when the latency-param has been supplied and - ; MUST NOT be supplied if the latency-param is - ; not supplied. - - / action-param - - - -Royer, et al. Expires July 12, 2004 [Page 108] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - ; The following is optional, - ; and MAY occur more than once. - - / other-params - - ; The following MUST BE supplied exactly once. - ; The value specifies the number of UIDs to - ; be returned. - - / option-param posint1 - - ) - - - Response: - - - gen-reply = "BEGIN" ":" "VCALENDAR" CRLF - calprops ; Which MUST include 'reply-cmd' - 1*(gen-vreply) - "END" ":" "VCALENDAR" CRLF - - - gen-vreply = "BEGIN" ":" "VREPLY" CRLF - 1*(uid) - request-status - "END" ":" "VREPLY" CRLF - - - Example: - - - C: BEGIN:VCALENDAR - C: VERSION:2.0 - C: PRODID:-//someone's prodid - C: CMD;ID=unique-per-cua-124;OPTIONS=5:GENERATE-UID - C: END:VCALENDAR - - S: Content-Type: text/calendar - S: - S: BEGIN:VCALENDAR - S: VERSION:2.0 - S: PRODID:-//someone's prodid - S: CMD;ID=unique-per-cua-124:REPLY - S: BEGIN:VREPLY - S: UID:20011121T120000Z-12340@cal.example.com - S: UID:20011121T120000Z-12341@cal.example.com - S: UID:20011121T120000Z-12342@cal.example.com - - - -Royer, et al. Expires July 12, 2004 [Page 109] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - S: UID:20011121T120000Z-12343@cal.example.com - S: UID:20011121T120000Z-12344@cal.example.com - S: REQUEST-STATUS:2.0 - S: END:VREPLY - S: END:VCALENDAR - - - -10.7 GET-CAPABILITY Command - - CMD: GET-CAPABILITY - - Purpose: The "GET-CAPABILITY" command returns the capabilities of the - other end point of the session. - - A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial - connection. A CS MUST send a "GET-CAPABILITY" command to a CUA after - the initial connection. The "GET-CAPABILITY" command and reply MUST - BE implemented by all CSs and CUAs. - - Formal Definition: A "GET-CAPABILITY" command is defined by the - following notation: - - - get-capability-cmd = capibiltyparam ":" "GET-CAPABILITY" - - capibiltyparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - ; - id-param / localize-param / latency-param - - ; the following MUST occur exactly once and only - ; when the latency-param has been supplied and - ; MUST NOT be supplied if the latency-param is - ; not supplied. - ; - / action-param - - ; the following is optional, - ; and MAY occur more than once - ; - / other-params - ) - - - Response: - - - -Royer, et al. Expires July 12, 2004 [Page 110] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - The "GET-CAPABILITY" command returns information about the Calendar - other end of the session given the current state of the connection. - The values returned may differ depending on current user identify and - the security level of the connection. - - Client implementations SHOULD NOT require any capability element - beyond those defined in this specification or future RFC publications - , and MAY ignore any nonstandard, experimental capability elements. - The "GET-CAPABILITY" reply may return different results depending on - the UPN and if the UPN is authenticated. - - When sending a reply to a "GET-CAPABILITY" command, all of these MUST - BE supplied. The following properties are returned in response to a - "GET-CAPABILITY" command: - - - cap-vreply = "BEGIN" ":" "VCALENDAR" CRLF - ; The following properties may be in any order. - ; - prodid - version - reply-cmd - other-props - "BEGIN" ":" "VREPLY" CRLF - ; The following properties may be in any order. - ; - cap-version - car-level - components - stores-expanded - maxdate - mindate - itip-version - max-comp-size - multipart - query-level - recur-accepted - recur-expand - recur-limit - other-props - "END" ":" "VREPLY" CRLF - "END" ":" "VCALENDAR" CRLF - - Example: - - I: Content-Type: text/calendar - I: - I: BEGIN:VCALENDAR - - - -Royer, et al. Expires July 12, 2004 [Page 111] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - I: VERSION:2.0 - I: PRODID:-//someone's prodid - I: CMD;ID=unique-per-cua-125:GET-CAPABILITY - I: END:VCALENDAR - - L: Content-Type: text/calendar - L: - L: BEGIN:VCALENDAR - L: VERSION:2.0 - L: PRODID:-//someone's prodid - L: CMD;ID=unique-per-cua-125:REPLY - L: BEGIN:VREPLY - L: CAP-VERSION:1.0 - L: PRODID:The CS prodid - L: QUERY-LEVEL:CAL-QL-1 - L: CAR-LEVEL:CAR-FULL-1 - L: MAXDATE:99991231T235959Z - L: MINDATE:00000101T000000Z - L: MAX-COMPONENT-SIZE:0 - L: COMPONENTS:VCALENDAR,VTODO,VJOURNAL,VEVENT,VCAR, - L: VALARM,VFREEBUSY,VTIMEZONE,STANDARD,DAYLIGHT,VREPLY - L: ITIP-VERSION:2446 - L: RECUR-ACCEPTED:TRUE - L: RECUR-EXPAND:TRUE - L: RECUR-LIMIT:0 - L: STORES-EXPANDED:FALSE - L: X-INET-PRIVATE-COMMANDS:1.0 - L: END:VREPLY - L: END:VCALENDAR - - - -10.8 IDENTIFY Command - - CMD: IDENTIFY - - Purpose: The "IDENTIFY" command allows the CUA to set a new identity - to be used for calendar access. - - A CUA MAY send an "IDENTIFY" command to a CS. The "IDENTIFY" command - MUST BE implemented by all CSs. A CS implementation MAY reject all - "IDENTIFY" commands. - - The CS MUST NOT send a "IDENTIFY" command to any CUA. - - Formal Definition: A "IDENTIFY" command is defined by the following - notation: - - - - -Royer, et al. Expires July 12, 2004 [Page 112] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - identify-cmd = identifyparam ":" "IDENTIFY" - - identifyparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - id-param - / localize-param - / latency-param - - ; the following MUST occur exactly once and only - ; when the latency-param has been supplied and - ; MUST NOT be supplied if the latency-param is - ; not supplied. - - / action-param - - ; the following is optional, - ; and MAY occur more than once - - / other-params - - ; The value is the UPN of the requested - ; identity. If option is not supplied it is - ; a request to return to the original authenticated - ; identity. - - / option-param upn - - ) - - Response: - - A "REQUEST-STATUS" property wrapped in a "VREPLY" component with only one of the following - request-status codes: - - 2.0 Successful. - - 6.4 Identity not permitted. VCAR restriction. - - - The CS determines through an internal mechanism if the credentials - supplied at authentication permit the operation as the selected - identity. If they do, the session assumes the new identity, otherwise - a security error is returned. - - Example: - - - -Royer, et al. Expires July 12, 2004 [Page 113] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - C: Content-Type: text/calendar - C: - C: BEGIN:VCALENDAR - C: VERSION:2.0 - C: PRODID:-//someone's prodid - C: CMD;ID=unique-per-cua-999;OPTIONS=newUserId:IDENTIFY - C: END:VCALENDAR - - S: Content-Type: text/calendar - S: - S: BEGIN:VCALENDAR - S: VERSION:2.0 - S: PRODID:-//someone's prodid - S: BEGIN:VREPLY - S: REQUEST-STATUS:2.0;Request Approved - S: END:VREPLY - S: END:VCALENDAR - - Or if denied: - - S: Content-Type: text/calendar - S: - S: BEGIN:VCALENDAR - S: PRODID:-//someone's prodid - S: VERSION:2.0 - S: BEGIN:VREPLY - S: REQUEST-STATUS:6.4;Request Denied - S: END:VREPLY - S: END:VCALENDAR - - And for the CUA to return to its original authenticated identity - the OPTIONS parameter is omitted: - - C: Content-Type: text/calendar - C: - C: BEGIN:VCALENDAR - C: VERSION:2.0 - C: PRODID:-//someone's prodid - C: CMD;ID=unique-per-cua-995:IDENTIFY - C: END:VCALENDAR - - - The CS may accept (2.0) or deny (6.4) the request to return to the - original identity. - - If a CS considers the "IDENTIFY" command an attempt to violate - security, the CS MAY terminate the [BEEP] session without any further - notice to the CUA after sending the "REQUEST-STATUS" 6.4 reply. - - - -Royer, et al. Expires July 12, 2004 [Page 114] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -10.9 MODIFY Command - - CMD: MODIFY - - Purpose: The "MODIFY" command is used to modify existing components. - - A CUA MAY send a "MODIFY" command to a CS. The "MODIFY" command MUST - BE implemented by all CSs. - - The CS MUST NOT send a "MODIFY" command to any CUA. - - Formal Definition: A "MODIFY" command is defined by the following - notation: - - - modify-cmd = modifyparam ":" "MODIFY" - - modifyparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - id-param - / localize-param - / latency-param - - ; the following MUST occur exactly once and only - ; when the latency-param has been supplied and - ; MUST NOT be supplied if the latency-param is - ; not supplied. - - / action-param - - ; the following is optional, - ; and MAY occur more than once - - / other-params - - ) - - - The "MODIFY" command is used to modify existing components. The - TARGET property specifies the calendars where the components exist - that are going to be modified. - - The format of the request is three components inside of "VCALENDAR" - component: - - - - -Royer, et al. Expires July 12, 2004 [Page 115] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - BEGIN:VCALENDAR - ... - BEGIN:VQUERY - ... - END:VQUERY - BEGIN:XXX - ...old-values... - END:XXX - BEGIN:XXX - ...new-values... - END:XXX - END:VCALENDAR - - - The "VQUERY" component selects the components that are to be - modified. - - Where "XXX" above is a named component type (VEVENT, VTODO, ...). - Both the old and new components MUST BE of the same type. - - The old-values is a component and the contents of that component are - going to change and may contain information that helps uniquely - identify the original component (SEQUENCE in the example below). If - the CS can not find a component that matches the QUERY and does not - have at least all of the OLD-VALUES, then a 6.1 error is returned. - - The new-values is a component of the same type as old-values and - new-values contains the new data for each selected component. Any - data that is in old-values and not in new-values is deleted from the - selected component. Any values in new-values that was not in - old-values is added to the component. - - In this example the "VEVENT" component with a "UID" property value of - 'unique-58' has; the "LOCATION" property and "LAST-MODIFIED" property - changed, the "VALARM" component with the "SEQUENCE" property with a - value of "3" has its "TRIGGER" property disabled, the "X-LOCAL" - property is removed from the "VEVENT" component, and a "COMMENT" - property is added. - - Because "SEQUENCE" property is used to locate the "VALARM" component - in this example, both the old-values and the new-values contain the - "SEQUENCE" property with a value of "3" and if the "SEQUENCE" - property were to be left out of new-values, it would have been - deleted. - - - Example: - - - - -Royer, et al. Expires July 12, 2004 [Page 116] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - C: Content-Type: text/calendar - C: - C: BEGIN:VCALENDAR - C: VERSION:2.0 - C: PRODID:-//someone's prodid - C: TARGET:my-cal - C: CMD:ID=unique-mod:MODIFY - C: BEGIN:VQUERY <- Query to select data set. - C: QUERY:SELECT * FROM VEVENT WHERE UID = 'unique-58' - C: END:VQUERY - C: BEGIN:VEVENT <- Start of old data. - C: LOCATION:building 3 - C: LAST-MODIFIED:20020101T123456Z - C: X-LOCAL:some private stuff - C: BEGIN:VALARM - C: SEQUENCE:3 - C: TRIGGER;RELATED=END:PT5M - C: END:VALARM - C: END:VEVENT <- End of old data. - C: BEGIN:VEVENT <- Start of new data. - C: LOCATION:building 4 - C: LAST-MODIFIED:20020202T010203Z - C: COMMENT:Ignore global trigger. - C: BEGIN:VALARM - C: SEQUENCE:3 - C: TRIGGER;ENABLE=FALSE:RELATED=END:PT5M - C: END:VALARM - C: END:VEVENT <- End of new data. - C: END:VCALENDAR - - - The "X-LOCAL" property was not supplied in the new-values, so it was - deleted. The "LOCATION" property value was altered, as was the - "LAST-MODIFIED" value. The "VALARM" component with a "SEQUENCE" - property value of "3" had its "TRIGGER" property disabled, and the - "SEQUENCE" property value did not change so it was not effected. The - "COMMENT" property was added. - - When it comes to inline ATTACHMENTs, the CUA only needs to uniquely - identify the contents of the ATTACHMENT value in the old-values in - order to delete them. When the CS compares the attachment data it is - compared in its binary form. The ATTACHMENT value supplied by the CUA - MUST BE valid encoded information. - - For example, to delete the same huge inline attachment from every - VEVENT in 'my-cal' that has an "ATTACH" property value with the - old-values: - - - - -Royer, et al. Expires July 12, 2004 [Page 117] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//someone's prodid - TARGET:my-cal - CMD:MODIFY - BEGIN:VQUERY - QUERY:SELECT ATTACH FROM VEVENT - END:VQUERY - BEGIN:VEVENT - ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY: - MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U - EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE - ...< remainder of attachment data NOT supplied >.... - END:VEVENT - BEGIN:VEVENT - END:VEVENT - END:VCALENDAR - - - Above the new-values is empty, so everything in the old-values is - deleted. - - Furthermore, the following additional restrictions apply: - - 1. One can not change the "UID" property of a component. - - 2. If a contained component is changed inside of a selected - component, and that contained component has multiple instances, - then old-values MUST contain information that uniquely identifies - the instance or instances that are changing. It is valid to - change more than one. As all contained components that match - old-values will be modified. In the first modify example above, - if "SEQUENCE" properties were to be deleted from both the - old-values and new-values, then all "TRIGGER" properties that - matched the old-values in all "VALARM" components in the selected - "VEVENT" components would be disabled. - - 3. The result of the modify MUST BE a valid iCalendar object. - - Response: - - A "VCALENDAR" component is returned with one ore more - "REQUEST-STATUS" property values. - - If any error occurred: - - No component will be changed at all. That is, it will appear just - as it was prior to the modify and the CAP server SHOULD return a - - - -Royer, et al. Expires July 12, 2004 [Page 118] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - "REQUEST-STATUS" property for each error that occurred. - - There MUST BE at least one error reported. - - If multiple components are selected, then what uniquely identified - the component MUST BE returned (UID, QUERYID, ...) if the component - contains a unique identifier. If not, sufficient information to - uniquely identify the modified components MUST BE returned in the - reply. - - - S: Content-Type: text/calendar - S: - S: BEGIN:VCALENDAR - S: TARGET:relcalid - S: CMD;ID=delete#1:REPLY - S: BEGIN:VREPLY - S: BEGIN:VEVENT - S: UID:123 - S: REQUEST-STATUS:2.0 - S: END:VEVENT - S: END:VREPLY - S: END:VCALENDAR - - - -10.10 MOVE Command - - CMD: MOVE - - Purpose: The "MOVE" command is used to move components within the CS. - - A CUA MAY send a "MOVE" command to a CS. The "MOVE" command MUST BE - implemented by all CSs. - - The CS MUST NOT send a "MOVE" command to any CUA. - - Formal Definition: A "MOVE" command is defined by the following - notation: - - - move-cmd = moveparam ":" "MOVE" - - moveparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - - - -Royer, et al. Expires July 12, 2004 [Page 119] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - id-param - / localize-param - / latency-param - - ; the following MUST occur exactly once and only - ; when the latency-param has been supplied and - ; MUST NOT be supplied if the latency-param is - ; not supplied. - - / action-param - - ; the following is optional, - ; and MAY occur more than once - - / other-params - - ) - - - Response: - The REQUEST-STATUS in a VCALENDAR object. - - - The content of each "result" is subject to the result restriction - table defined below. - - The access control on the "VAGENDA" component after it has been moved - to its new location in the calstore MUST BE at least as secure as it - was prior to the move. If the CS is not able to ensure the same level - of security, a permission denied "REQUEST-STATUS" property value MUST - BE returned and the "MOVE" command not performed. - - The "TARGET" property value specifies the new location, and the - "VQUERY" component specifies the old location. - - Restriction Table for the "REPLY" command of any "MOVE" command. - - - move-reply = "BEGIN" ":" "VCALENDAR" CRLF - calprops - 1*(move-vreply) - "END" ":" "VCALENDAR" CRLF - - - move-vreply = "BEGIN" ":" "VREPLY" CRLF - move-id - request-status - "END" ":" "VREPLY" CRLF - - - -Royer, et al. Expires July 12, 2004 [Page 120] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - ; Where the id is appropriate for the - ; type of object moved: - ; - ; VAGENDA = relcalid - ; VCAR = carid - ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid - ; VQUERY = queryid - ; ALARM = sequence - ; An instance = uid recurid - ; x-component = x-id - ; - move-id = ( relcalid / carid / uid / uid recurid - / queryid / tzid / sequence / x-id) - - - Example: moving the VAGENDA Nellis to Area-51 - - - C: Content-Type: text/calendar - C: - C: BEGIN:VCALENDAR - C: VERSION:2.0 - C: PRODID:-//someone's prodid - C: CMD:MOVE - C: TARGET:Area-51 - C: BEGIN:VQUERY - C: QUERY: SELECT * FROM VAGENDA WHERE CALID='Nellis' - C: END:VQUERY - C: END:VCALENDAR - - S: Content-Type: text/calendar - S: - S: BEGIN:VCALENDAR - S: VERSION:2.0 - S: PRODID:-//someone's prodid - S: TARGET:Area-51 - S: BEGIN:VREPLY - S: CALID:Nellis - S: REQUEST-STATUS: 2.0 - S: END:VREPLY - S: END:VCALENDAR - - - -10.11 REPLY Response to a Command - - CMD: REPLY - - - - -Royer, et al. Expires July 12, 2004 [Page 121] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Purpose: The "REPLY" value to the "CMD" property is used to return - the results of all other commands to the CUA. - - A CUA MUST send a "REPLY" command to a CS for any command a CS MAY - send to the CUA. The "REPLY" command MUST BE implemented by all CUAs - that support getting the "GET-CAPABILITY" command. - - A CS MUST send a "REPLY" command to a CUA for any command a CUA MAY - send to the CS. The "REPLY" command MUST BE implemented by all CSs. - - Formal Definition: A "REPLY" command is defined by the following - notation: - - - reply-cmd = replyparam ":" "REPLY" - - replyparam = *( - - ; The 'id' parameter value MUST BE exactly the - ; same as the value sent in the original - ; CMD property. If the original CMD did - ; not have an 'id' parameter, then the 'id' - ; MUST NOT be supplied in the REPLY. - - id-param - - ; the following is optional, - ; and MAY occur more than once - - / other-params - - ) - - - -10.12 SEARCH Command - - CMD: SEARCH - - Purpose: The "SEARCH" command is used to return selected components - to the CUA. - - A CUA MAY send a "SEARCH" command to a CS. The "SEARCH" command MUST - BE implemented by all CSs. - - The CS MUST NOT send a "SEARCH" command to any CUA. - - Formal Definition: A "SEARCH" command is defined by the following - - - -Royer, et al. Expires July 12, 2004 [Page 122] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - notation: - - - search-cmd = searchparam ":" "SEARCH" - - searchparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - id-param - / localize-param - / latency-param - - ; the following MUST occur exactly once and only - ; when the latency-param has been supplied and - ; MUST NOT be supplied if the latency-param is - ; not supplied. - - / action-param - - ; the following is optional, - ; and MAY occur more than once - - / other-params - - ) - - - The format of the request is the search command (search-cmd) followed - by one or more (query) "VQUERY" components - - Response: - - The data in each result set contains one or more iCalendar components - composed of all the selected results enclosed in a single "VREPLY" - component per "QUERY". - - Only "REQUEST-STATUS" property and the properties mentioned in the - "SELECT" clause of the QUERY are included in the components. Each - "VCALENDAR" component is tagged with the "TARGET" property. - - Searching for objects - - In the example below objects on March 10,1999 between 080000Z and - 190000Z are read. In this case only 4 properties for each objects are - returned. Two calendars are specified. Only booked (vs scheduled) - entries are to be returned (this example only selected VEVENT - - - -Royer, et al. Expires July 12, 2004 [Page 123] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - objects): - - - C: Content-Type: text/calendar - C: - C: BEGIN:VCALENDAR - C: VERSION:2.0 - C: PRODID:-//someone's prodid - C: CMD:SEARCH - C: TARGET:relcal2 - C: TARGET:relcal3 - C: BEGIN:VQUERY - C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID - C: FROM VEVENT - C: WHERE DTEND >= '19990310T080000Z' - C: AND DTSTART <= '19990310T190000Z' - C: AND STATE() = 'BOOKED' - C: END:VQUERY - C: END:VCALENDAR - - - The return values are subject to VCAR filtering. That is, if the - request contains properties to which the UPN does not have access, - those properties will not appear in the return values. If the UPN has - access to at least one property of the component, but has been denied - access to all properties called out in the request, the response will - contain a single "REQUEST-STATUS" property indicating the error. - - Here the request was successful, however one of the "VEVENT" - components contents were not accessible (4.1). - - - S: Content-Type: text/calendar - S: - S: BEGIN:VCALENDAR - S: TARGET:relcalid - S: CMD:REPLY - S: VERSION:2.0 - S: PRODID:-//someone's prodid - S: BEGIN:VREPLY - S: BEGIN:VEVENT - S: REQUEST-STATUS:4.1 - S: END:VEVENT - S: BEGIN:VEVENT - S: REQUEST-STATUS:2.0 - S: UID:123 - S: DTEND:19990310T080000Z - S: DSTART:19990310T190000Z - - - -Royer, et al. Expires July 12, 2004 [Page 124] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - S: SUMMARY: Big meeting - S: END:VEVENT - S: END:VREPLY - S: END:VCALENDAR - - - If the UPN has no access to any components at all, the response will - simply be an empty data set. The response looks the same if there - the particular components did not exist. - - - S: Content-Type: text/calendar - S: - S: BEGIN:VCALENDAR - S: VERSION:2.0 - S: PRODID:-//someone's prodid - S: CMD:REPLY - S: TARGET:ralcalid - S: BEGIN:VREPLY - S: REQUEST-STATUS:2.0 - S: END:VREPLY - S: END:VCALENDAR - - - If there are multiple targets, each iCalendar reply is contained - within its own iCalendar object. - -10.12.1 Searching for VFREEBUSY - - If a CS sets the "RECUR-EXPAND" property to "TRUE" and contains the - "VFREEBUSY" component in the "COMPONENTS" value in a reply to the - "GET-CAPABILITY" command, then it is the CS's responsibility and not - the CUA's responsibility to provide the correct "VFREEBUSY" - information for a calendar. - - If a CUA issues a "CREATE" "VFREEBUSY", such a CS MUST return success - and not store the "VFREEBUSY" component as the results would never be - used. - - Such a CS MUST dynamically create the results of a search for - "VFREEBUSY" components at search time when searching for STATE() = - 'BOOKED' items. - - If a CUA searches for "VFREEBUSY" components with STATE() = - 'UNPROCESSED', such a CS MUST return a "VREPLY" with no components. - - If a CUA searches for "VFREEBUSY" components without specifying the - STATE, such a CS MUST return the same result as if STATE()='BOOKED' - - - -Royer, et al. Expires July 12, 2004 [Page 125] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - had been specified. - - For CSs that set the "CAPABILITY" "RECUR-EXPAND" property to "FALSE" - and have the "VFREEBUSY" component in the "COMPONENTS" value in the - "CAPABILITY" reply, a CUA MAY store the "VFREEBUSY" information on - the CS. These CSs then MUST return a "VFREEBUSY" component calculated - from the stored components. If no "VFREEBUSY" information is - available for the "TARGET" calendar, then a "VFREEBUSY" with no - blocked out time will be returned with a success code. A CUA sets the - "VFREEBUSY" time on a those calendars by creating a "VFREEBUSY" - component without a "METHOD" creating a "BOOKED" entry. - - If a CS does not set the "VFREEBUSY" value in the "COMPONENTS" - "CAPABILITY" value, the CS does not support the "VFREEBUSY" component - and all creation and searching for a "VFREEBUSY" component MUST fail. - Examples of calendars that may be in this category are public event - calendars that will never require scheduling with other UPNs. - -10.13 SET-LOCALE Command - - CMD: SET-LOCALE - - Purpose: The "SET-LOCALE" command is used to select the locale that - will be used in error codes used in the "REQUEST-STATUS" property. - - A CUA MAY send a "SET-LOCALE" command to a CS. The SET-LOCALE command - MUST BE implemented by all CSs. - - The CS MUST NOT send a "SET-LOCALE" command to any CUA. - - Formal Definition: A "SET-LOCALE" command is defined by the following - notation: - - - setlocale-cmd = setlocaleparam ":" "SET-LOCALE" - - setlocaleparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - id-param - / localize-param - / latency-param - / setlocale-option - - ; the following MUST occur exactly once and only - ; when the latency-param has been supplied and - - - -Royer, et al. Expires July 12, 2004 [Page 126] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - ; MUST NOT be supplied if the latency-param is - ; not supplied. - - / action-param - - ; the following is optional, - ; and MAY occur more than once - - / other-params - - setlocal-option = option-param newlocale - - newlocale = ; Any locale supplied in the initial [BEEP] - ; "greeting" "localize" parameter and - ; and any charset supported by the CS - ; and listed in the DEFAULT-CHARSET property - ; of the VCALSTORE. - - ) - - - Examples: - - - CMD:OPTIONS=en_US.UTF-8:SET-LOCALE - CMD:OPTIONS=th_TH.ISO8859-11:SET-LOCALE - CMD:OPTIONS=es_MX.ISO8859-1:SET-LOCALE - - - Restriction Table for the "REPLY" command of any "SET-LOCALE" - command. - - - - setlocale-reply = "BEGIN" ":" "VCALENDAR" CRLF - calprops - 1*(setlocale-vreply) - "END" ":" "VCALENDAR" CRLF - - setlocale-vreply = "BEGIN" ":" "VREPLY" CRLF - request-status - "END" ":" "VREPLY" CRLF - - - -10.14 TIMEOUT Command - - CMD: TIMEOUT - - - -Royer, et al. Expires July 12, 2004 [Page 127] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Purpose: The "TIMEOUT" command is only sent after a command has been - sent with a latency value set. When received it means the command - could not be completed in the time allowed. - - Formal Definition: A "TIMEOUT" command is defined by the following - notation: - - - timeout-cmd = timeoutparam ":" "TIMEOUT" - - timeoutparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - id-param - / localize-param - - / other-params - - ) - - - -10.15 Response Codes - - Numeric response codes are returned using the "REQUEST-STATUS" - property. - - The format of these codes is described in [iCAL], and extend in - [iTIP] and [iMIP]. The following describes new codes added to this - set and how existing codes apply to CAP. - - At the application layer response codes are returned as the value of - a "REQUEST-STATUS" property. The value type of this property is - modified from that defined in [iCAL], in order to make the - accompanying "REQUEST-STATUS" property text optional. - - - Code Description - -------------------------------------------------------------- - 2.0 Success. The parameters vary with the - operation and are specified. - - 2.0.3 In response to the client issuing an - "abort" reply, this reply code indicates - that any command currently underway was - successfully aborted. - - - -Royer, et al. Expires July 12, 2004 [Page 128] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - 3.1.4 Capability not supported. - - 4.1 Calendar store access denied. - - 6.1 Container not found. - - 6.2 Attempt to create or modify an object - such that it would overlap another object - in either of the following two circumstances: - - (a) One of the objects has a TRANSP - property set to OPAQUE-NOCONFLICT or - TRANSPARENT-NOCONFLICT. - - (b) The calendar's ALLOW-CONFLICT - property is set to FALSE. - - 6.3 Bad args. - - 6.4 Permission denied - VCAR restriction. - A VCAR exists and the CS will not perform - the operation. - - 7.0 A timeout has occurred. The server was - unable to complete the operation in the - requested time. - - 8.0 A failure has occurred in the CS - that prevents the operation from - succeeding. - - 8.1 A query was performed and the query is - too complex for the CS. The operation - was not performed. - - 8.2 Used to signal that an iCalendar object has - exceeded the server's size limit - - 8.3 A DATETIME value was too far in the future - represented on this Calendar. - - 8.4 A DATETIME value was too far in the past - to be represented on this Calendar. - - 8.5 An attempt was made to create a new - object but the unique UID specified is - already in use. - - - - -Royer, et al. Expires July 12, 2004 [Page 129] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - 9.0 An unrecognized command was received. - Or an unsupported command was received. - - - 10.4 The operation has not been performed - because it would cause the resources - (memory, disk, CPU, etc) to exceed the - allocated quota. - - -------------------------------------------------------------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 130] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -11. Object Registration - - This section provides the process for registration of new or modified - properties, parameters, commands, or other modifications, additions, - or deletions to objects. - -11.1 Registration of New and Modified Entities - - New objects are registered by the publication of an IETF Request for - Comment (RFC). Changes to a objects are registered by the publication - of a revision to the RFC in a new RFC. - -11.2 Post the item definition - - The object description MUST BE posted to the new object discussion - list: ietf-calendar@imc.org. - -11.3 Allow a comment period - - Discussion on a new object MUST BE allowed to take place on the list - for a minimum of two weeks. Consensus MUST BE reached on the object - before proceeding to the next step. - -11.4 Release a new RFC - - The new object will be submitted for publication as any other - internet draft requesting RFC status. - - - - - - - - - - - - - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 131] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -12. BEEP and CAP - -12.1 BEEP Profile Registration - - Beep replies will be one to one (1:1 MSG/RPY) if possible and one to - many (1:many MSG/ANS) when the TARGET changes. - - Profile Identification: specify a URI [10] that authoritatively - identifies this profile. - - http://iana.org/beep/cap/1.0 - - Message Exchanged during Channel Creation: - - CUAs SHOULD supply the BEEP "localize" attributes in the BEEP - "greeting" messages. - - CSs SHOULD supply the BEEP "localize" attributes in the BEEP - "greeting" messages. - - CUAs SHOULD supply the BEEP "serverName" attribute at channel - creation time to the CS so that if the CS is performing virtual - hosting the CS can determine the intended virtual host. CSs that do - not support virtual hosting may ignore the BEEP "serverName" - attribute. - - Messages starting one-to-one exchanges: - - The initial message each direction MUST BE single "text/calendar" - object containing a CAP "CAPABILITY" CMD and must not be part of a - MIME multipart message. - - After the initial message then a BEEP "MSG" may contain one or more - MIME objects at least one of which MUST be "text/calendar" and each - "text/calendar" MIME object MUST contain a CAP "CMD" property. - - Multiple iCal objects may be sent in a single BEEP message by either - representing them as separate MIME text/calendar parts contained - within a MIME multipart/mixed part or by simple concatenation within - a single text/calendar MIME object. - - In either case, all iCal objects transmitted together must have the - same TARGET property. - - The sending of multipart MIME entities over BEEP is not permitted for - CAP unless the other endpoint has indicated its ability to accept - them via the appropriate CAPABILITY. - - - - -Royer, et al. Expires July 12, 2004 [Page 132] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Messages in positive replies: - - After the initial message then a BEEP "RPY" may contain one or more - MIME objects at least one of which MUST be "text/calendar" and each - "text/calendar" MIME object MUST contain a CAP "CMD" property. All - "text/calendar" MIME objects in a single BEEP "RPY" messages MUST - have the same "TARGET" property value. - - Multiple iCal objects may be sent in a single BEEP message by either - representing them as separate MIME text/calendar parts contained - within a MIME multipart/mixed part or by simple concatenation within - a single text/calendar MIME object. - - In either case, all iCal objects transmitted together must have the - same TARGET property. - - The sending of multipart MIME entities over BEEP is not permitted for - CAP unless the other endpoint has indicated its ability to accept - them via the appropriate CAPABILITY. - - Messages in negative replies: - - Any valid "text/calendar" MIME object that contains CAP - "REQUEST-STATUS" property and a CAP "CMD" property with a property - value of "REPLY". And where the CS has determined the requested - operation to be a fatal error. And when the CS has performed NO - operation that effected the contents of any part of the CS or any - calendar controlled by the CS. - - Messages in one-to-many exchanges: - - After the initial message then a BEEP "MSG" may contain one or more - MIME objects at least one of which MUST be "text/calendar" and each - "text/calendar" MIME object MUST contain a CAP "CMD" property. - - The BEEP "MSG" messages can only contain MIME "multipart" MIME - objects if the other endpoint has received a CAP "CAPABILITY" - indicating the other endpoint supports multipart MIME objects. This - does not prevent the endpoint from sending multiple [iCAL] - 'icalobject' objects in a single BEEP "MSG" so long as all of them - have the same "TARGET" property value. - - Multiple iCal objects may be sent in a single BEEP message by either - representing them as separate MIME text/calendar parts contained - within a MIME multipart/mixed part or by simple concatenation within - a single text/calendar MIME object. - - In either case, all iCal objects transmitted together must have the - - - -Royer, et al. Expires July 12, 2004 [Page 133] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - same TARGET property. - - The sending of multipart MIME entities over BEEP is not permitted for - CAP unless the other endpoint has indicated its ability to accept - them via the appropriate CAPABILITY. - - Message Syntax: - - They are CAP "text/calendar" MIME objects as specified in this memo. - (Remember this text will be part of CAP). - - Message Semantics: - - As defined in this memo. (Remember this will be part of CAP). - -12.2 BEEP Exchange Styles - - [BEEP] defines three styles of message exchange: - - MSG/ANS,ANS,...,NUL - For one to many exchanges. - - MSG/RPY - For one to one exchanges. - - MSG/ERR - For requests the cannot be processed due to an error. - - A CAP request targeted at more than one containers, MAY use a one- - to-many exchange, with a distinct answer associated with each target. - CAP request targeted at a single container MAY use a one-to-one - exchange or a one-to-many exchange. "MSG/ERR" MAY only be used when - an error condition prevents the execution of the request on all the - targeted calendars. - - - - - - - - - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 134] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -13. IANA Considerations - - This memo defines IANA registered extensions to the attributes - defined by iCalendar, as defined in [iCAL], and [iTIP]. - - IANA registration proposals for iCalendar and [iTIP] are to be mailed - to the registration agent for the "text/calendar" [MIME] - content-type, using the format - defined in section 7 of [iCAL]. - - If the IESG approves this memo for publication, then the IANA - registers the profile specified in Section 12.1, and selects an - IANA-specific URI, e.g., http://iana.org/beep/cap/1.0. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 135] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -14. Security Considerations - - Access rights should be granted cautiously. Without careful planning - it is possible to open up access to a greater degree than desired. - - The "IDENTIFY" command should be carefully implemented. - - In addition, since CAP is a profile of [BEEP], consult [BEEP]'s - Section 9 for a discussion of BEEP-specific security issues. - - There are risks of allowing anonymous UPNs to deposit REQUEST and - REFRESH objects. (calendar spam and deninal of service for example) - So implementations should consider methods to restrict anonymous - requests to within acceptable usages. - - CS implementations might consider automatically creating VCARs that - allow CAP ATTENDEEs in booked objects to deposit REFRESH and REPLY - objects for those UIDs if they otherwise do not have access rather - then opening up world access. And they may consider also allowing - COUNTER objects for those ATTENDEEs. - - When an object is booked by a CUA the CS reply may wish to include - warning messages to the CUA for ATTENDEEs that have CAP urls that do - not have local UPNs as those ATTENDEES may be unable to REPLY or - REFRESH. Some CSs may wish this to be an error. - - Although service provisioning is a policy matter, at a minimum, all - implementations must provide the following tuning profiles: - - for authentication: http://iana.org/beep/SASL/DIGEST-MD5 - - for confidentiality: http://iana.org/beep/TLS (using the - TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher) - - for both: http://iana.org/beep/TLS (using the - TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side - certificates) - - - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 136] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -URIs - - [1] - - -Authors' Addresses - - Doug Royer - INET-Consulting.com - 1795 W. Broadway #266 - Idaho Falls, ID 83402 - US - - Phone: +1-866-594-8574 - Fax: +1-866-594-8574 - EMail: Doug@Royer.com - URI: http://INET-Consulting.com - - - George Babics - Oracle - 2000 Peel Street - Montreal, Quebec H3A 2W5 - CA - - Phone: +1-514-733-8500 x4201 - Fax: +1-514-733-8878 - EMail: George.Babics@Oracle.com - - - Paul Hill - Massachusetts Institute of Technology - W92-172 - 77 Massachusetts Avenue - Cambridge, MA 02139 - US - - Phone: +1-617-253-0124 - Fax: +1-617-258-8736 - EMail: phb@mit.edu - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 137] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - Steve Mansour - AOL/Netscape - 466 Ellis Road - Mountain View, CA 94043 - US - - Phone: +1-650-937-3351 - EMail: sman@netscape.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 138] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -Appendix A. Acknowledgments - - The following have individuals were major contributors in the - drafting and discussion of this memo: - - Harald Alvestrand, Christopher Apple, G. Barnes, ArentJan Banck, - Martijn van Beers, Mario Bonin, Andrea Campi, Darryl Champagne, Damon - Chaplin, Karen Chu, Shannon Clark, Andre Courtemanche, Dave Crocker, - Alan Davies, Andrew Davison, Mark Davidson, Bernard Desruisseaux, - Frank Dawson, Pat Egen, Greg FitzPatrick, illes Fortin, Ned Freed, - Gary Frederick, Jagan Garimella, Graham Gilmore, Micah Gorrell, - Lawrence Greenfield, Bertrand Guiheneuf, Olivier Gutknecht, Mike - Hixson, Jeff Hodges, Paul Hoffman, Scott Hollenbeck, Alex Hoppman, - Bruce Kahn, Lata Kannan, suchet singh khalsa, Dan Kohn, Patrice - Lapierre, Jonathan Lennox, Lisa Lippert, Robert Lusardi, David Madeo, - Bob Mahoney, Murata Makoto, Gary McGath, Libby Miller, Steve Miller, - Bob Morgan, David Nicol, David Nusbaum, Pete O'Leary, Mark Paterson, - Ralph Patterson, Eric R. Plamondon, Robert Ransdell, Jim Ray, - Marshall Rose, JP Rosevear, Paul Sharpe, Richard Shusterman, Tony - Small, John Smith, Benjamin Sonntag, John Stracke, Preston - Stephenson, Alexander Taler, Peter Thompson, Steve Vinter, Mark Wahl, - Dan Winship - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 139] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -Appendix B. Bibliography - - - [BEEP] Rose, M., "The Block Extensible Exchange Protocol Core", - RFC 3080, March 2001 - ftp://ftp.isi.edu/in-notes/rfc3080.txt - - [BEEPTCP] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001 - ftp://ftp.isi.edu/in-notes/rfc3081.txt - - [CHARREG] Freed, N., Postel, J., "IANA Charset Registration Procedures", - RFC 2278, January 1998, - ftp://ftp.isi.edu/in-notes/rfc2278.txt - - [CHARPOL] Alvestrand, H., "IETF Policy on Character Sets and Languages", - RFC 2277, January 1998, - ftp://ftp.isi.edu/in-notes/rfc2277.txt - - - [GUIDE] Mahoney, B., Babics, G., Taler, A. "Guide to Internet - Calendaring", RFC 3283, June 2002, - ftp://ftp.isi.edu/in-notes/rfc3283.txt - - [iCAL] Dawson, F. and Stenerson, D., "Internet Calendaring and - Scheduling Core Object Specification (iCalendar)", RFC 2445, - November 1998 ftp://ftp.isi.edu/in-notes/rfc2445.txt - - [iTIP] Silverberg, S., Mansour, S., Dawson, F. and Hopson, R., - "iCalendar Transport-Independent Interoperability Protocol - (iTIP) Events, BusyTime, To-dos and Journal Entries", - RFC 2446, November 1998 ftp://ftp.isi.edu/in-notes/rfc2446.txt - - [iMIP] Dawson, F., Mansour, S. and Silverberg, "iCalendar - Message-Based Interoperability Protocol (iMIP)", RFC 2447, - November 1998 ftp://ftp.isi.edu/in-notes/rfc2447.txt - - [MIME] Borenstein, N. and Freed, N., "Multipurpose Internet Mail - Extensions (MIME) Part One: Format of Internet Message Bodies", - RFC 2045, November 1996 - ftp://ftp.isi.edu/in-notes/rfc2045.txt - - [RFCWORDS] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, BCP 14, March 1997 - ftp://ftp.isi.edu/in-notes/rfc2119.txt - - [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", - RFC 2222, October 1997 - ftp://ftp.isi.edu/in-notes/rfc2222.txt - - - -Royer, et al. Expires July 12, 2004 [Page 140] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - [SQL92] "Database Language SQL", ANSI/ISO/IEC 9075: 1992, - aka ANSI X3.135-1992, aka FiPS PUB 127-2 - - [SQLCOM] ANSI/ISO/IEC 9075:1992/TC-1-1995, Technical corrigendum 1 - to ISO/IEC 9075: 1992, also adopted as Amendment 1 to - ANSI X3.135.1992 - - [URLGUIDE] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., - "Guidelines for new URL Schemes", RFC 2718, November 1999, - ftp://ftp.isi.edu/in-notes/rfc2718.txt - - [URI] Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform Resource - Identifiers (URI): Generic Syntax", RFC 2396, August 1998 - ftp://ftp.isi.edu/in-notes/rfc2396.txt - - [URL] Berners-Lee, T, Masinter, L. and McCahil, M., "Uniform - Resource Locators (URL)", RFC 1738, December 1994 - ftp://ftp.isi.edu/in-notes/rfc1738.txt - - [X509CRL] Housley, R., Ford, W., Polk, W., Solo, D. "Internet X.509 - Public Key Infrastructure, Certificate and CRL Profile", - RFC 2459, January 1999, - ftp://ftp.isi.edu/in-notes/rfc2459.txt - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 141] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Royer, et al. Expires July 12, 2004 [Page 142] - -Internet-Draft Calendar Access Protocol (CAP) January 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Royer, et al. Expires July 12, 2004 [Page 143] - diff --git a/etc/draft-jennings-impp-vcard-04.txt b/etc/draft-jennings-impp-vcard-04.txt deleted file mode 100644 index 97ca770..0000000 --- a/etc/draft-jennings-impp-vcard-04.txt +++ /dev/null @@ -1,405 +0,0 @@ -IMPP C. Jennings -Internet-Draft Cisco Systems -Expires: April 22, 2005 October 22, 2004 - - - - vCard Extensions for IM - draft-jennings-impp-vcard-04 - - -Status of this Memo - - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - This Internet-Draft will expire on April 22, 2005. - - -Copyright Notice - - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - -Abstract - - - This document describes an extension to vCard to support Instant - Messaging (IM) and Presence Protocol (PP) applications. IM and PP - are becoming increasingly common ways of communicating, and users - want to save this contact information in their address books. This - draft allows a URI that is associated with IM or PP to be specified - inside of a vCard. - - -1. Conventions - - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - - - - -Jennings Expires April 22, 2005 [Page 1] -Internet-Draft IMPP vCard October 2004 - - - - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [3]. - - -2. Overview - - - As more and more people use various instant messaging (IM) and - presence protocol (PP) applications, it becomes important for them to - be able to share this contact address information along with the rest - of their contact information. RFC 2425 [1] and RFC 2426 [2] define a - standard format for this information which is referred to as vCard. - This document defines a new type in a vCard for representing instant - IM and PP URIs. It is very similar to existing types for - representing email address and telephone contact information. - - - The type entry to hold this new contact information is an IMPP type. - The IMPP entry has a single URI that indicates the address of a - service that provides IM, PP, or both. Also defined are some - parameters that give hints as to when certain URIs would be - appropriate. A given vCard can have multiple IMPP entries but each - entry can contain only one URI. Each IMPP entry can contain multiple - parameters. Any combination of parameters is valid, though a - parameter should occur at most once in a given IMPP entry. - - - The type of URI indicates what protocols might be useable for - accessing it, but this document does not define any of the types. - For example a URI type of - - - "sip"[6] indicates to use SIP/SIMPLE, - "xmpp"[7] indicates to use XMPP, - "irc"[5] indicates to use IRC, - "ymsgr" indicates to use yahoo, - "msn" might indicate to use Microsoft messenger, - "aim" indicates to use AOL, and - "im"[9] or "pres"[8] indicates to use a CPIM or CPP gateway. - - - The normative definition of this new vCard type is given in Section - 3, and an informational ABNF is provided in Section 4. - - -3. IMPP Type Definition - - - To: ietf-mime-direct@imc.org - - - Subject: Registration of text/directory MIME type IMPP - - - Type name: IMPP - - - Type purpose: To specify the URI for instant messaging and presence - protocol communication with the object the vCard represents. - - - - -Jennings Expires April 22, 2005 [Page 2] -Internet-Draft IMPP vCard October 2004 - - - - Type encoding: 8bit - - - Type value: A single URI. The type of the URI indicates the protocol - that can be used for this contact. - - - Type special notes: The type can include the type parameter "TYPE" to - specify an intended use for the URI. The TYPE parameter values can - include: - - - An indication of the type of communication for which this URI is - appropriate. This can be a value of PERSONAL or BUSINESS. - - - An indication of the location of a device associated with this - URI. Values can be HOME, WORK, or MOBILE. - - - The value PREF indicates this is a preferred address and has the - same semantics as the PREF value in a TEL type. - - - Intended usage: COMMON - - -4. Formal Grammar - - - The following ABNF grammar[4] extends the grammar found in RFC 2425 - [1] and RFC 2426 [2]. - - - - ;For name="IMPP" - param = impp-param ; Only impp parameters are allowed - - - value = uri - - - impp-param = "TYPE" "=" impp-type *("," impp-type) - - - impp-type = "PERSONAL" / "BUSINESS" / ; purpose of communications - "HOME" / "WORK" / "MOBILE" / - "PREF" / - iana-token / x-name; - ; Values are case insensitive - - - -5. Example - - - - BEGIN:vCard - VERSION:3.0 - FN:Alice Doe - IMPP;TYPE=personal,pref:im:alice@example.com - END:vCard - - - - -Jennings Expires April 22, 2005 [Page 3] -Internet-Draft IMPP vCard October 2004 - - - -6. IANA Considerations - - - Section 3 forms the IANA registration. - - -7. Security Considerations - - - This does not introduce additional security issues beyond current - vCard specification. It is worth noting that many people consider - their presence information more sensitive than some other address - information. Any system that stores or transfers vCards needs to - carefully consider the privacy issues around this information. - - -8. Acknowledgments - - - Thanks to Paul Hoffman, Sam Roberts and Pekka Pessi for comments. - - -9. References - - -9.1 Normative References - - - [1] Howes, T., Smith, M. and F. Dawson, "A MIME -- --Content-Type - for Directory Information", RFC 2425, September 1998. - - - [2] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC - 2426, September 1998. - - - [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - -9.2 Informational References - - - [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - - [5] Butcher, S., "Uniform Resource Locator Schemes for Internet - Relay Chat Entities", draft-butcher-irc-url-04 (work in - progress), January 2004. - - - [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., - Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: - Session Initiation Protocol", RFC 3261, June 2002. - - - [7] Saint-Andre, P., "XMPP URI Format", draft-saintandre-xmpp-uri-06 - (work in progress), October 2004. - - - [8] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, - August 2004. - - - - - -Jennings Expires April 22, 2005 [Page 4] -Internet-Draft IMPP vCard October 2004 - - - - [9] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC - 3860, August 2004. - - - -Author's Address - - - Cullen Jennings - Cisco Systems - 170 West Tasman Drive - MS: SJC-21/2 - San Jose, CA 95134 - USA - - - Phone: +1 408 902-3341 - EMail: fluffy@cisco.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jennings Expires April 22, 2005 [Page 5] -Internet-Draft IMPP vCard October 2004 - - - -Intellectual Property Statement - - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - -Disclaimer of Validity - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - -Copyright Statement - - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - - -Acknowledgment - - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Jennings Expires April 22, 2005 [Page 6] \ No newline at end of file diff --git a/etc/draft-saintandre-xmpp-uri-08.txt b/etc/draft-saintandre-xmpp-uri-08.txt deleted file mode 100644 index 093393a..0000000 --- a/etc/draft-saintandre-xmpp-uri-08.txt +++ /dev/null @@ -1,1010 +0,0 @@ - -Network Working Group P. Saint-Andre -Internet-Draft Jabber Software Foundation -Expires: June 9, 2005 December 9, 2004 - - A Uniform Resource Identifier (URI) Scheme for the Extensible - Messaging and Presence Protocol (XMPP) - draft-saintandre-xmpp-uri-08 - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on June 9, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). - -Abstract - - This document defines a Uniform Resource Identifier (URI) scheme for - use in identifying or interacting with entities that can communicate - via the Extensible Messaging and Presence Protocol (XMPP). - - - - -Saint-Andre Expires June 9, 2005 [Page 1] -Internet-Draft XMPP-URI December 2004 - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Description of xmpp: URI Scheme . . . . . . . . . . . . . . . 3 - 2.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2.2 Form . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.3 Authority Component . . . . . . . . . . . . . . . . . . . 5 - 2.4 Path Component . . . . . . . . . . . . . . . . . . . . . . 6 - 2.5 Query Component . . . . . . . . . . . . . . . . . . . . . 6 - 2.6 Fragment Identifier Component . . . . . . . . . . . . . . 8 - 2.7 Generation of XMPP URIs . . . . . . . . . . . . . . . . . 8 - 2.8 Processing of XMPP URIs . . . . . . . . . . . . . . . . . 11 - 2.9 Internationalization . . . . . . . . . . . . . . . . . . . 14 - 3. IANA Registration of xmpp: URI Scheme . . . . . . . . . . . . 14 - 3.1 URI scheme name . . . . . . . . . . . . . . . . . . . . . 14 - 3.2 URI scheme syntax . . . . . . . . . . . . . . . . . . . . 14 - 3.3 Character encoding considerations . . . . . . . . . . . . 15 - 3.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . 15 - 3.5 Applications and/or protocols which use this URL - scheme name . . . . . . . . . . . . . . . . . . . . . . . 15 - 3.6 Security considerations . . . . . . . . . . . . . . . . . 15 - 3.7 Relevant publications . . . . . . . . . . . . . . . . . . 16 - 3.8 Person and email address to contact for further - information . . . . . . . . . . . . . . . . . . . . . . . 16 - 3.9 Author/change controller . . . . . . . . . . . . . . . . . 16 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 - 6.2 Informative References . . . . . . . . . . . . . . . . . . . 17 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 - Intellectual Property and Copyright Statements . . . . . . . . 20 - - - - - - - - - -Saint-Andre Expires June 9, 2005 [Page 2] -Internet-Draft XMPP-URI December 2004 - -1. Introduction - - The Extensible Messaging and Presence Protocol (XMPP) is a streaming - XML technology that enables any two entities on a network to exchange - well-defined but extensible XML elements (called "XML stanzas") in - close to real time. [XMPP-CORE] specifies that on an XMPP network - itself, the address of an XMPP entity MUST NOT be prepended with a - Uniform Resource Identifier (URI) scheme (as defined in [URI]). - However, many applications external to an XMPP network may need to - identify XMPP entities as full URIs; examples include databases that - need to store XMPP addresses and non-native user agents (e.g., web - browsers and calendaring applications) that provide interfaces to - XMPP services. In order to address the needs of such applications, - this memo defines an xmpp: URI scheme that conforms to both the - requirements in [URL-REG] and the recommendations in [URL-GUIDE]. - -1.1 Terminology - - This document inherits terminology described in [URI] and - [XMPP-CORE]. - - The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", - "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in RFC - 2119 [TERMS]. - -2. Description of xmpp: URI Scheme - -2.1 Rationale - - Many types of application can be built using XMPP. As specified in - [XMPP-IM], instant messaging and presence applications of XMPP MUST - handle the im: and pres: URI schemes specified by [CPIM] and [CPP]. - However, it is appropriate to define an XMPP-specific URI scheme for - other applications of XMPP (such as network management, workflow - applications, generic publish-subscribe, remote procedure calls, - content syndication, gaming, and middleware) since these applications - do not necessarily implement instant messaging and presence - semantics. Therefore, this document defines a generic URI scheme - that will enable applications to address as a URI any entity that can - communicate via XMPP. - - The xmpp: URI scheme is provided mainly for use by non-native - interfaces and applications, and primarily for the purpose of - identification rather than interaction (on the latter distinction, - see Section 1.2.2 of [URI]). In order to ensure interoperability on - XMPP networks, when data is routed to an XMPP entity (e.g., when an - XMPP address is contained in the 'to' or 'from' attribute of an XML - - -Saint-Andre Expires June 9, 2005 [Page 3] -Internet-Draft XMPP-URI December 2004 - - stanza) or an XMPP entity is otherwise identified in standard XMPP - protocol elements, the entity MUST be addressed as - <[node@]domain[/resource]> (i.e., without a URI scheme), where the - "node identifier", "domain identifier", and "resource identifier" - portions of an XMPP address conform to the definitions provided in - Section 3 of [XMPP-CORE]. - - (Note: For historical reasons, the term "resource identifier" is used - in XMPP to refer to the optional portion of an XMPP address that - follows the domain identifier and the "/" separator character (for - details, refer to Section 3.4 of [XMPP-CORE]); this use of the term - "resource identifier" is not to be confused with the meanings of - "resource" and "identifier" provided in Section 1.1 of [URI].) - -2.2 Form - - As described in [XMPP-CORE], an XMPP address (also known as a "JID") - used natively on an XMPP network is a string of Unicode characters - that (1) conforms to a certain set of [STRINGPREP] profiles and - [IDNA] restrictions, (2) follows a certain set of syntax rules, and - (3) is encoded as [UTF-8]. The form of such an address can be - represented using Augmented Backus-Naur Form ([ABNF]) as: - - [ node "@" ] domain [ "/" resource ] - - The "node" and "resource" rules rely on distinct profiles of - [STRINGPREP] and the "domain" rule relies on the concept of an - internationalized domain name as described in [IDNA]. However, - because a URI is allowed to contain [US-ASCII] characters only and - certain characters are reserved in URIs (the "reserved" rule defined - in [URI]), an XMPP address must be properly handled when transformed - into an XMPP URI (see Section 2.7 of this memo) and the ABNF syntax - needs to be adjusted in order to accurately capture the form of an - XMPP URI as opposed to a native XMPP address. Furthermore, it is - desirable to take advantage of more advanced aspects of URI syntax - and semantics in XMPP URIs, such as authority components, query - components, and fragment identifier components. Therefore, using the - "fragment", "host", "pct-encoded", "query", "sub-delims", and - "unreserved" rules defined in [URI], the ABNF syntax for an XMPP URI - is defined as follows: - - - - - - -Saint-Andre Expires June 9, 2005 [Page 4] -Internet-Draft XMPP-URI December 2004 - - xmppuri = "xmpp:" hier-xmpp [ "?" querycomp ] [ "#" fragment ] - hier-xmpp = authpath / path-xmpp - authpath = "//" auth-xmpp [ "/" path-xmpp ] - auth-xmpp = nodeid "@" host - path-xmpp = [ nodeid "@" ] host [ "/" resid ] - nodeid = *( unreserved / pct-encoded / nodeallow ) - nodeallow = "!" / "$" / "%" / "(" / ")" / "*" / "+" / "," - / ";" / "=" / "^" / "`" / "{" / "|" / "}" - resid = *( unreserved / pct-encoded / sub-delims ) - querycomp = querytype [ *pair ] - querytype = *( ALPHA / DIGIT / '-' / '_' / '.' / ':' ) - pair = "&" key "=" value - key = *unreserved - value = *( unreserved / pct-encoded ) - - (Note: It would have been desirable to re-use the "userinfo" rule - from [URI]; however, this was not possible since the "userinfo" rule - allows characters that conform to the "sub-delims" rule, but the "&" - and "'" characters (which are allowed by the "sub-delims" rule) are - disallowed in XMPP node identifiers by the Nodeprep profile of - [STRINGPREP] as specified in Appendix A of [XMPP-CORE]. Furthermore, - there is no need to refer to punycode in the URI syntax itself, since - any punycode representation would occur only inside an XMPP - application in order to represent internationalized domain names.) - - The following is an example of a basic XMPP URI used for purposes of - identifying a node associated with an XMPP server (an IM user is one - type of such a node, but by no means the only type): - - xmpp:juliet@example.com - - Further descriptions of the various components of an XMPP URI are - provided in the following sections. - -2.3 Authority Component - - As explained in Section 2.8 of this memo, in the absence of an - authority component the processing application would authenticate as - a configured user at a configured XMPP server. The presence of an - authority component (always preceded by "//") signals the processing - application to authenticate as the node@domain specified in the - authority component, rather than as a configured node@domain. Thus, - the following XMPP URI indicates to authenticate as - "guest@example.com": - - xmpp://guest@example.com - - Note well that this is quite different from the following XMPP URI, - - -Saint-Andre Expires June 9, 2005 [Page 5] -Internet-Draft XMPP-URI December 2004 - - which identifies a node "guest@example.com" but does not signal the - processing application to authenticate as that node: - - xmpp:guest@example.com - - Similarly, using a possible query component of "?message" to trigger - an interface for sending a message, the following XMPP URI signals - the processing application to authenticate as "guest@example.com" and - send a message to "support@example.com": - - xmpp://guest@example.com/support@example.com?message - - By contrast, the following XMPP URI signals the processing - application to authenticate as its configured default account and - send a message to "support@example.com": - - xmpp:support@example.com?message - - (Note: It is unlikely that the authority component will be included - in most XMPP URIs; however, the scheme allows for inclusion of the - authority component if appropriate.) - -2.4 Path Component - - The path component of an XMPP URI identifies an XMPP address or - specifies the XMPP address to which an XML stanza shall be directed - at the end of URI processing. - - For example, the following XMPP URI identifies a node associated with - an XMPP server: - - xmpp:juliet@example.com - - The following XMPP URI identifies a node associated with an XMPP - server along with a particular XMPP resource identifier associated - with that node: - - xmpp:juliet@example.com/balcony - - Inclusion of a node is optional in XMPP addresses, so that the - following XMPP URI simply identifies an XMPP server: - - xmpp:example.com - -2.5 Query Component - - There are many potential use cases for encapsulating information in - - -Saint-Andre Expires June 9, 2005 [Page 6] -Internet-Draft XMPP-URI December 2004 - - the query component of an XMPP URI; examples include but are not - limited to: - - o Sending an XMPP message stanza. - o Adding a roster item. - o Sending a presence subscription. - o Probing for current presence information. - o Joining an XMPP-based text chat room (see [JEP-0045]). - o Registering with another entity (see [JEP-0077]). - o Triggering a remote procedure call (see [JEP-0009]). - o Providing a SOAP interface (see [JEP-0072]). - o Discovering the identity or capabilities of another entity (see - [JEP-0030]). - o Interacting with publish-subscribe channels (see [JEP-0060]). - - Many of these potential use cases are application-specific, and the - full range of such applications cannot be foreseen in advance given - the continued expansion in XMPP development; however, there is - agreement within the Jabber/XMPP developer community that all of the - uses envisioned to date can be encapsulated via a "query type", - optionally supplemented by one or more "key-value" pairs (this is - similar to the "application/x-www-form-urlencoded" MIME type - described in [HTML]). - - As an example, an XMPP URI intended to launch an interface for - sending a message to the XMPP entity "juliet@example.com" might be - represented as follows: - - xmpp:juliet@example.com?message - - Similarly, an XMPP URI intended to launch an interface for sending a - message to the XMPP entity "juliet@example.com" with a particular - subject might be represented as follows: - - xmpp:juliet@example.com?message&subject=Hello%20World - - If included, the query component MUST first be encoded as a [UTF-8] - string; any [UTF-8] encoded octets MUST then be converted into - US-ASCII characters, making sure to represent any reserved character - (i.e., any character that conforms to the "reserved" rule defined in - [URI]) and any character that is outside the range of the US-ASCII - coded character set as a percent-encoded octet (see Section 2.1 of - [URI]). - - If the processing application does not understand query components, - it MUST ignore the query component and treat the URI as consisting - of, for example, rather than - . If the processing application does - - -Saint-Andre Expires June 9, 2005 [Page 7] -Internet-Draft XMPP-URI December 2004 - - not understand a particular key within the query component, it MUST - ignore that key and its associated value. - - In pursuit of interoperability, it may be valuable to maintain a - registry of query types and perhaps even of keys for use in the query - component portion of XMPP URIs. Given that such values will most - likely be specific to particular applications of XMPP rather than - core to XMPP itself, it seems reasonable that such a registry, if - created, would be maintained by the Jabber Registrar function of the - Jabber Software Foundation as described in [JEP-0053], rather than by - the IANA. A proposal for creating such a registry is described in - [JEP-0147]. - -2.6 Fragment Identifier Component - - As stated in Section 3.5 of [URI], "The fragment identifier component - of a URI allows indirect identification of a secondary resource by - reference to a primary resource and additional identifying - information." Because the resource identified by an XMPP URI does - not make available any media type (see [MIME]) and therefore (in the - terminology of [URI]) no representation exists at an XMPP resource, - the semantics of the fragment identifier component in XMPP URIs are - to be "considered unknown and, effectively, unconstrained" (ibid.). - Particular XMPP applications MAY make use of the fragment identifier - component for their own purposes. However, if a processing - application does not understand fragment identifier components or the - syntax of a particular fragment identifier component included in an - XMPP URI, it MUST ignore the fragment identifier component. - - If included, the fragment identifier component MUST first be encoded - as a [UTF-8] string; any [UTF-8] encoded octets MUST then be - converted into US-ASCII characters, making sure to represent any - reserved character (i.e., any character that conforms to the - "reserved" rule defined in [URI]) and any character that is outside - the range of the US-ASCII coded character set as a percent-encoded - octet (see Section 2.1 of [URI]). - -2.7 Generation of XMPP URIs - -2.7.1 URI Generation Method - - When generating a conformant XMPP URI from an XMPP address, it is - necessary to use consistent methods for transforming (1) an XMPP - "node identifier" into a string of US-ASCII characters that conforms - to the "nodeid" rule, (2) an XMPP "domain identifier" into a string - of US-ASCII characters that conforms to the "host" rule, and (3) an - XMPP "resource identifier" into a string of US-ASCII characters that - conforms to the "resid" rule; such methods are described below. - - -Saint-Andre Expires June 9, 2005 [Page 8] -Internet-Draft XMPP-URI December 2004 - - Naturally, if the XMPP address exists in a non-UTF-8 form (e.g., - having been written on a piece of paper or having been represented - internally in a computer program as UTF-16), it MUST first be - converted to [UTF-8] before the XMPP URI is generated. - - In order to transform an XMPP "node identifier" into a string of - US-ASCII characters that conforms to the "nodeid" rule, the node - identifier MUST first be constructed in accordance with the rules - specified in [XMPP-CORE], including application of the Nodeprep - profile of [STRINGPREP] (see Appendix A of [XMPP-CORE]) and encoding - as a [UTF-8] string; any [UTF-8] encoded octets of the XMPP "node - identifier" MUST then be converted into US-ASCII characters, making - sure to represent any reserved character (i.e., any character that - conforms to the "reserved" rule defined in [URI]) and any character - that is outside the range of the US-ASCII coded character set as a - percent-encoded octet (see Section 2.1 of [URI]). - - In order to transform an XMPP "domain identifier" into a string of - US-ASCII characters that conforms to the "host" rule, the domain - identifier MUST first be constructed in accordance with the rules - specified in [XMPP-CORE], including application of the [NAMEPREP] - profile of [STRINGPREP] and encoding as a [UTF-8] string; any [UTF-8] - encoded octets of the XMPP "domain identifier" MUST then be converted - into US-ASCII characters, making sure to represent any reserved - character (i.e., any character that conforms to the "reserved" rule - defined in [URI]) and any character that is outside the range of the - US-ASCII coded character set as a percent-encoded octet (see Section - 2.1 of [URI]). - - In order to transform an XMPP "resource identifier" into a string of - US-ASCII characters that conforms to the "resid" rule, the resource - identifier MUST first be constructed in accordance with the rules - specified in [XMPP-CORE], including application of the Resourceprep - profile of [STRINGPREP] (see Appendix B of [XMPP-CORE]) and encoding - as a [UTF-8] string; any [UTF-8] encoded octets of the XMPP "resource - identifier" MUST then be converted into US-ASCII characters, making - sure to represent any reserved character (i.e., any character that - conforms to the "reserved" rule defined in [URI]) and any character - that is outside the range of the US-ASCII coded character set as a - percent-encoded octet (see Section 2.1 of [URI]). - - In order to form an XMPP URI from the foregoing components, the - generating application MUST concatenate: - - 1. the "xmpp:" scheme - 2. optionally (if an authority component is to be included), the - characters "//", an authority component of the form node@domain, - and the character "/" - - -Saint-Andre Expires June 9, 2005 [Page 9] -Internet-Draft XMPP-URI December 2004 - - 3. optionally (if the XMPP address contained an XMPP "node - identifier"), a string of US-ASCII characters that conforms to - the "nodeid" rule, followed by the "@" character - 4. a string of US-ASCII characters that conforms to the "host" rule - 5. optionally (if the XMPP address contained an XMPP "resource - identifier"), the character "/" and a string of US-ASCII - characters that conforms to the "resid" rule - 6. optionally (if a query component is to be included), the "?" - character and query component - 7. optionally (if a fragment identifier component is to be - included), the "#" character and fragment identifier component - -2.7.2 URI Generation Example - - Consider the following XMPP address: - - - - (Note: The string "ř" stands for the Unicode character LATIN - SMALL LETTER R WITH CARON and the string "č" stands for the - Unicode character LATIN SMALL LETTER C WITH CARON, following the "XML - Notation" used in [IRI] to represent characters that cannot be - rendered in ASCII-only documents. The '<' and '>' characters are - not part of the address itself, but are provided to set off the - address for legibility. For those who do not read Czech, this - example could be Anglicized as "george@czech-lands.example/In - Prague".) - - In accordance with the process specified above, the generating - application would do the following to generate a valid XMPP URI from - this address: - - 1. First ensure that the XMPP address conforms to the rules - specified in [XMPP-CORE], including application of the relevant - [STRINGPREP] profiles and encoding as a [UTF-8] string. - 2. Split the address into an XMPP "node identifier" ("jiři"), - XMPP "domain identifier" ("čechy.example"), and XMPP - "resource identifier" ("v Praze"). - 3. Transform the XMPP "node identifier" into a string of US-ASCII - characters that conforms to the "nodeid" rule by converting the - [UTF-8] string to US-ASCII, including conversion of the LATIN - SMALL LETTER R WITH CARON character to its percent-encoded - representation "%C5%99"; the result is the string "ji%C5%99i". - 4. Transform the XMPP "domain identifier" into a string of US-ASCII - characters that conforms to the "host" rule by converting the - [UTF-8] string to US-ASCII, including conversion of the LATIN - SMALL LETTER C WITH CARON character to its percent-encoded - representation "%C4%8C"; the result is the string - - -Saint-Andre Expires June 9, 2005 [Page 10] -Internet-Draft XMPP-URI December 2004 - - "%C4%8Cechy.example". - 5. Transform the XMPP "resource identifier" into a string of - US-ASCII characters that conforms to the "resid" rule by - converting the [UTF-8] string to US-ASCII, including conversion - of the " " (SP) character to its percent-encoded representation - "%20"; the result is the string "v%20Praze". - 6. Concatenate the following: - 1. the "xmpp:" scheme - 2. a URI "authority component" if included (not shown in this - example) - 3. the string of US-ASCII characters that conforms to the - "nodeid" rule, followed by the "@" character - 4. the string of US-ASCII characters that conforms to the "host" - rule - 5. the "/" character followed by the string of US-ASCII - characters that conforms to the "resid" rule - 6. the "?" character followed by a URI "query component" if - appropriate to the application (not shown in this example) - 7. the "#" character followed by a URI "fragment identifier - component" if appropriate to the application (not shown in - this example) - - The result is this XMPP URI: - - - -2.8 Processing of XMPP URIs - -2.8.1 URI Processing Method - - As with the generation of an XMPP URI from an XMPP address, so also - with the processing of an XMPP URI (including the extraction of an - XMPP address therefrom): it is necessary to use consistent methods; - such methods are described below. - - In order to decompose an XMPP URI, a processing application MUST - separate: - - 1. the "xmpp:" scheme - 2. optionally (if the XMPP URI contains an authority component), the - authority component (the string of US-ASCII characters between - the "//" characters and the first "/" character or the end of the - URI) - 3. optionally a string of US-ASCII characters that conforms to the - "nodeid" rule (if any), using the "@" character as a separator - 4. a string of US-ASCII characters that conforms to the "host" rule - - -Saint-Andre Expires June 9, 2005 [Page 11] -Internet-Draft XMPP-URI December 2004 - - 5. optionally a string of US-ASCII characters that conforms to the - "resid" rule (if any), using the "/" character as a separator - 6. optionally the query component (if any), using the "?" character - as a separator - 7. optionally the fragment identifier component (if any), using the - "#" character as a separator - - In order to reconstruct the XMPP address from the foregoing - components, the processing application MUST: - - o Transform the string of US-ASCII characters that conforms to the - "nodeid" rule into an XMPP "node identifier" by converting each - sequence of percent-encoded octets into the appropriate sequence - of reserved or non-US-ASCII octets by (1) decoding percent-encoded - octets into actual octets, (2) interpreting the octets as [UTF-8], - and (3) applying the Nodeprep profile of [STRINGPREP] as specified - in Appendix A of [XMPP-CORE]. - o Transform the string of US-ASCII characters that conforms to the - "host" rule into an XMPP "domain identifier" by converting each - sequence of percent-encoded octets into the appropriate sequence - of reserved or non-US-ASCII octets by (1) decoding percent-encoded - octets into actual octets, (2) interpreting the octets as [UTF-8], - and (3) applying the [NAMEPREP] profile of [STRINGPREP]. - o Transform the string of US-ASCII characters that conforms to the - "resid" rule into an XMPP "resource identifier" by converting each - sequence of percent-encoded octets into the appropriate sequence - of reserved or non-US-ASCII octets by (1) decoding percent-encoded - octets into actual octets, (2) interpreting the octets as [UTF-8], - and (3) applying the Resourceprep profile of [STRINGPREP] as - specified in Appendix B of [XMPP-CORE]. - o Concatenate the following (ensuring that the resulting string is - encoded as [UTF-8]): - 1. the XMPP "node identifier" and the "@" character (if a string - of US-ASCII characters that conforms to the "nodeid" rule was - included) - 2. the XMPP "domain identifier" - 3. the "/" character and XMPP "resource identifier" (if a string - of US-ASCII characters that conforms to the "resid" rule was - included) - - At this point, the processing application would either (1) complete - further XMPP handling itself or (2) invoke a helper application to - complete XMPP handling; such XMPP handling would most likely consist - of the following steps: - - 1. Authenticating either as the user specified in the authority - component or as the configured user at the configured XMPP server - if not already so authenticated. - - -Saint-Andre Expires June 9, 2005 [Page 12] -Internet-Draft XMPP-URI December 2004 - - 2. Optionally determining the nature of the intended recipient - (e.g., via [JEP-0030]). - 3. Optionally presenting an appropriate interface to a user based on - the nature of the intended recipient and/or the contents of the - query component. - 4. Generating an XMPP stanza that translates any user or application - inputs into their corresponding XMPP equivalents. - 5. Sending the XMPP stanza via the authenticated server connection - for delivery to the intended recipient. - - Note: It may help implementors to note that the first two steps of - the "further XMPP handling" are similar to HTTP authentication - ([HTTP-AUTH]), while the next three steps are similar to the handling - of mailto: URIs ([MAILTO]). - -2.8.2 URI Processing Example - - Consider the XMPP URI that resulted from the previous example: - - - - In accordance with the process specified above, the processing - application would do the following to extract the XMPP address from - this XMPP URI: - - 1. Split the URI into a string of US-ASCII characters that conforms - to the "nodeid" rule ("ji%C5%99i"), a string of US-ASCII - characters that conforms to the "host" rule - ("%C4%8Cechy.example"), and a string of US-ASCII characters that - conforms to the "resid" rule ("v%20Praze"). - 2. Transform the string of US-ASCII characters that conforms to the - "nodeid" rule into an XMPP "node identifier" by converting the - percent-encoded representation "%C5%99" to its equivalent [UTF-8] - character (LATIN SMALL LETTER R WITH CARON), making sure that the - entire string is encoded as [UTF-8]; the result is an XMPP "node - identifier" of "jiři". - 3. Transform the string of US-ASCII characters that conforms to the - "host" rule into an XMPP "domain identifier" by converting the - US-ASCII string to [UTF-8] and converting the percent-encoded - representation "%C4%8C" to its equivalent [UTF-8] character - (LATIN SMALL LETTER C WITH CARON), making sure that the entire - string is encoded as [UTF-8]; the result is an XMPP "domain - identifier" of "čechy.example" (encoded as a [UTF-8] - string). - 4. Transform the string of US-ASCII characters that conforms to the - "resid" rule into an XMPP "resource identifier" by converting the - percent-encoded representation "%20" to its equivalent [UTF-8] - character (SP), making sure that the entire string is encoded as - - -Saint-Andre Expires June 9, 2005 [Page 13] -Internet-Draft XMPP-URI December 2004 - - [UTF-8]; the result is an XMPP "resource identifier" of "v - Praze". - 5. Concatenate the following (ensuring that the resulting string is - encoded as [UTF-8]): - 1. the XMPP "node identifier" and the "@" character - 2. the XMPP "domain identifier" - 3. the "/" character and the XMPP "resource identifier" - - The result is this XMPP address: - - - -2.9 Internationalization - - Because XMPP addresses are [UTF-8] strings and because the - non-US-ASCII octets in XMPP addresses can be easily converted to - percent-encoded octets, XMPP addresses are designed to work well with - Internationalized Resource Identifiers ([IRI]). In particular, with - the exception of stringprep verification and the conversion of - syntax-relevant US-ASCII characters (e.g., "?"), an XMPP IRI can be - constructed directly by prepending "xmpp:" to an XMPP address. - -3. IANA Registration of xmpp: URI Scheme - - This section provides the information required to register the xmpp: - URI scheme. - -3.1 URI scheme name - - xmpp - -3.2 URI scheme syntax - - The syntax for an xmpp: URI is defined below using Augmented - Backus-Naur Form as specified by [ABNF]. The "fragment", "host", - "pct-encoded", "query", "sub-delims", and "unreserved" rules are - defined in [URI]. - - - - - - - -Saint-Andre Expires June 9, 2005 [Page 14] -Internet-Draft XMPP-URI December 2004 - - xmppuri = "xmpp:" hier-xmpp [ "?" querycomp ] [ "#" fragment ] - hier-xmpp = authpath / path-xmpp - authpath = "//" auth-xmpp [ "/" path-xmpp ] - auth-xmpp = nodeid "@" host - path-xmpp = [ nodeid "@" ] host [ "/" resid ] - nodeid = *( unreserved / pct-encoded / nodeallow ) - nodeallow = "!" / "$" / "%" / "(" / ")" / "*" / "+" / "," - / ";" / "=" / "^" / "`" / "{" / "|" / "}" - resid = *( unreserved / pct-encoded / sub-delims ) - querycomp = querytype [ *pair ] - querytype = *( ALPHA / DIGIT / '-' / '_' / '.' / ':' ) - pair = "&" key "=" value - key = *unreserved - value = *( unreserved / pct-encoded ) - -3.3 Character encoding considerations - - Prior to any conversion into a URI and in accordance with - [XMPP-CORE], an Extensible Messaging and Presence Protocol (XMPP) - address MUST be represented as [UTF-8] by the generating application - (e.g., by transforming an application's internal representation of - the address as a UTF-16 string into a UTF-8 string). The UTF-8 - string MUST then be converted into a US-ASCII string in order to be - included in a URI; as part of this conversion, non-US-ASCII octets - MUST be percent-encoded as described in Section 2.1 of [URI]. - -3.4 Intended usage - - The xmpp: URI identifies entities that natively communicate using the - Extensible Messaging and Presence Protocol (XMPP), and is mainly used - for identification rather than processing. However, an application - that processes an xmpp: URI SHOULD reconstruct the encapsulated XMPP - address, authenticate with the appropriate XMPP server, and send an - appropriate XMPP "stanza" (XML fragment) to the XMPP address. There - is no MIME type associated with this URI. - -3.5 Applications and/or protocols which use this URL scheme name - - The xmpp: URI is intended to be used by interfaces to an XMPP network - from non-native user agents such as web browsers, as well as by - non-native applications that need to identify XMPP entities as full - URIs. - -3.6 Security considerations - - See Security Considerations (Section 5) of XXXX. - - -Saint-Andre Expires June 9, 2005 [Page 15] -Internet-Draft XMPP-URI December 2004 - -3.7 Relevant publications - - [XMPP-CORE] - -3.8 Person and email address to contact for further information - - Peter Saint-Andre [mailto:stpeter@jabber.org] - -3.9 Author/change controller - - This scheme is registered under the IETF tree. As such, the IETF - maintains change control. - -4. IANA Considerations - - This document registers a URI scheme. The registration template can - be found in Section 3 of this document. - -5. Security Considerations - - Detailed security considerations for Uniform Resource Identifiers are - given in [URI], and for the Extensible Messaging and Presence - Protocol in [XMPP-CORE]. Providing an interface to XMPP services - from non-native applications introduces new security concerns. For - example, the ability to interact with XMPP entities via a web browser - may expose sensitive information to attacks that are not possible or - that are unlikely on a native XMPP network. Due care must be taken - in deciding what information is appropriate for representation in - XMPP URIs. Care must also be taken in exposing XMPP addresses in the - authority and path components of XMPP URIs that are publicly - accessible. - -6. References - -6.1 Normative References - - [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [TERMS] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", - draft-fielding-uri-rfc2396bis-07 (work in progress), - September 2004. - - [URL-GUIDE] - - -Saint-Andre Expires June 9, 2005 [Page 16] -Internet-Draft XMPP-URI December 2004 - - Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke, - "Guidelines for new URL Schemes", RFC 2718, November 1999. - - [URL-REG] Petke, R. and I. King, "Registration Procedures for URL - Scheme Names", BCP 35, RFC 2717, November 1999. - - [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [XMPP-CORE] - Saint-Andre, P., "Extensible Messaging and Presence - Protocol (XMPP): Core", RFC 3920, October 2004. - - [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence - Protocol (XMPP): Instant Messaging and Presence", RFC - 3921, October 2004. - -6.2 Informative References - - [CPIM] Peterson, J., "Common Profile for Instant Messaging - (CPIM)", RFC 3860, August 2004. - - [CPP] Peterson, J., "Common Profile for Presence (CPP)", RFC - 3859, August 2004. - - [HTML] Raggett, D., "HTML 4.0 Specification", W3C REC - REC-html40-19980424, April 1998. - - [HTTP-AUTH] - Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., - Leach, P., Luotonen, A. and L. Stewart, "HTTP - Authentication: Basic and Digest Access Authentication", - RFC 2617, June 1999. - - [IDNA] Faltstrom, P., Hoffman, P. and A. Costello, - "Internationalizing Domain Names in Applications (IDNA)", - RFC 3490, March 2003. - - [IMP-MODEL] - Day, M., Rosenberg, J. and H. Sugano, "A Model for - Presence and Instant Messaging", RFC 2778, February 2000. - - [IMP-REQS] - Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / - Presence Protocol Requirements", RFC 2779, February 2000. - - [IRI] Duerst, M. and M. Suignard, "Internationalized Resource - Identifiers (IRIs)", draft-duerst-iri-11 (work in - - -Saint-Andre Expires June 9, 2005 [Page 17] -Internet-Draft XMPP-URI December 2004 - - progress), December 2004. - - [JEP-0009] - Adams, D., "Jabber-RPC", JSF JEP 0009, December 2002. - - [JEP-0030] - Hildebrand, J., Millard, P., Eatmon, R. and P. - Saint-Andre, "Service Discovery", JSF JEP 0030, July 2004. - - [JEP-0045] - Saint-Andre, P., "Multi-User Chat", JSF JEP 0045, October - 2004. - - [JEP-0053] - Saint-Andre, P., "Jabber Registrar", JSF JEP 0053, May - 2004. - - [JEP-0060] - Millard, P., "Publish-Subscribe", JSF JEP 0060, July 2004. - - [JEP-0072] - Forno, F., "SOAP Over XMPP", JSF JEP 0072, May 2004. - - [JEP-0077] - Saint-Andre, P., "In-Band Registration", JSF JEP 0077, - August 2004. - - [JEP-0147] - Saint-Andre, P., "XMPP URI Query Components", JSF JEP - 0147, November 2004. - - [MAILTO] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL - scheme", RFC 2368, July 1998. - - [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part Two: Media Types", RFC 2046, - November 1996. - - [NAMEPREP] - Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep - Profile for Internationalized Domain Names (IDN)", RFC - 3491, March 2003. - - [STRINGPREP] - Hoffman, P. and M. Blanchet, "Preparation of - Internationalized Strings ("STRINGPREP")", RFC 3454, - December 2002. - - -Saint-Andre Expires June 9, 2005 [Page 18] -Internet-Draft XMPP-URI December 2004 - - [US-ASCII] - American National Standards Institute, "Coded Character - Set - 7-bit American Standard Code for Information - Interchange", ANSI X3.4, 1986. - -Author's Address - - Peter Saint-Andre - Jabber Software Foundation - - EMail: stpeter@jabber.org - - - - - - - - - - - - - - - - - - - - -Saint-Andre Expires June 9, 2005 [Page 19] -Internet-Draft XMPP-URI December 2004 - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - -Saint-Andre Expires June 9, 2005 [Page 20] diff --git a/etc/ics-api-notes.txt b/etc/ics-api-notes.txt deleted file mode 100644 index 2c6e9ff..0000000 --- a/etc/ics-api-notes.txt +++ /dev/null @@ -1,522 +0,0 @@ -vim:expandtab - -props and params with lists of values use , - -properties with multiple parts (as opposed to a list of values), use ; - -property params with values containg ":", ",", or ";" must be placed in quoted text - -property param values cannot contain '"' - -property param values not in quoted strings are case insensitive... - -two forms of mult-valued properties: - -"," seperated values of a single property - -new content line for each value - - -API should perhaps hide this difference? Also, some properties docs prefer -one or the other of the forms. - - -All iCal parameters are documented in RFC2445s4.2. Variations: - -param-value - -DQUOTE value DQUOTE *( "," DQUOTE value DQUOTE ) - -List of case-insensitive token: "ACCEPTED", .., x-name, iana-token - -paramtext - -Some have refererences to property value types. - - -value parameter must be speced if property value is not of the default type -for that property. - -Not too long a list of property value types, see RFC2445s4.3: - -"BINARY" -/ "BOOLEAN" -/ "CAL-ADDRESS" -/ "DATE" -/ "DATE-TIME" -/ "DURATION" -/ "FLOAT" -/ "INTEGER" -/ "PERIOD" -/ "RECUR" -/ "TEXT" -/ "TIME" -/ "URI" -/ "UTC-OFFSET" - - -Components and their allowed/required/etc. properties are described in RFC2445s4.6. - -Values and semantics of property values are in 4.7 and 4.8. - -Allowed property values can vary depending on the calendar component they are -used within, or at least STATUS can. - -Property spec includes expect value type, as well as allowed parameters. - - -Also, there are inter-related "hooks" for propetries, such as the list of -properties that cause the SEQUENCE property to be incrmented whenever one of -those properties are changed. - - -Should be able to parse the examples in s5. - - -APIs: - -Vpim -Icalendar -Rrule - Attendee - Attachment - ...? - - Vevent - Vtodo - V... - - Property - Common (summary/description/...) - Times (dtstart/dtend/duration) - ... - - -Rrule - -Shouldn't this be under Icalendar? - -Also, I think it needs to take DTEND and/or DURATION as an arg, or in Vevent, -both #dtend and #duration need to take an optional +ytime+, so you can find -the how long each occurence is. - -Icalendar# -prodid -n: 1 -#value TEXT - -version -n: 1 -#value "2.0" - -calscale -n:0-1 -#value "GREGORIAN" - - -method -n:0-1 -#value ... see iTIP - -components... -#event -#todo -#journal -#freebusy -#timezone -#iana... -#x... - - -Vevent# - - #properties --> a Dirinfo? - - #class - n:0-1 - #value "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / ... - (default is "PUBLIC") - - #created - n:0-1 - #value DATE-TIME, must be UTC - (default is "PUBLIC") - - #dtstamp - n:0-1 - #value DATE-TIME, must be UTC - - #last-modified - n:0-1 - #value DATE-TIME, must be UTC - - #dtstart, #dtend, - n:0-1 - #value DATE-TIME, or optionally DATE - param VALUE - param TZID supported? - (dtstart is required for VEVENT, different criteria by component) - - #duration - n:0-1 - #value special format... currently return seconds, but that is only - with respect to the specific occurence. Perhaps it should take an - arg, where it's arg is start time. Default is DTSTART, but if you - want to know the duration of each occurence, you can ask with the - new start time. Or does Rrule already handle this? - - note: either DTEND or DURATION, but not both - - #description/#location/#summary - n:0-1 - #value TEXT - param ALTREP - param LANGUAGE - - Deal with altrep by having #description_altrep, etc, returning a URI - - #geo - n:0-1 - #value [ FLOAT, FLOAT ], the latitude and longitude - - #organizer - n:0-1 - #value CAL-ADDRESS - param CN - param DIR - param SENTBY - param LANGUAGE - - #priority - n:0-1 - #value INTEGER, range is 0-9, 0 being unspecified (the default), 1 being highest priority - - #sequence - n:0-1 - #value INTEGER - - #status - n:0-1 - #value "TENTATIVE"/ "CONFIRMED"/ "CANCELLED" (different for each component) - - #transp - n:0-1 - #value "OPAQUE" / "TRANSPARENT" - - #uid - n:0-1 - #value TEXT - - #url - n:0-1 - #value URI, return as text? probably easiest... maybe accept URI though, particularly - if it has a to_str or to_s method - - #recurid - n:0-1 - #value DATE-TIME, or optionally DATE - param VALUE - param TZID supported? - param RANGE - -Should be a class, and it has tons of special handling... deal with later -if I ever do iTIP. - - #attachments - n:0-* - ... array of class Attachment - Attachment - #uri TEXT (default) - #binary String, ENCODING=BASE64, VALUE=BINARY - #format param FMTTYPE, application/x-word, etc., default to "" or nil? - #value either binary, or download the URI, can it be a StringIO? - - #attendees - n:0-* - ... array of class Address - - #categories - n:0-* - #value TEXT - ... array of String - param LANGUAGE ... don't support - - (Concatenate all the categories found, comma seperated in each value, all - the property values in one array) - - #resources - n:0-* - #value TEXT - ... array of String - param LANGUAGE ... don't support - param ALTREP ... don't support - - (Concatenate all the resources found, comma seperated in each value, all - the property values in one array) - - #comments - n:0-* - #value TEXT - ... array of String - param LANGUAGE ... don't support - param ALTREP ... don't support - - (Concatenate all the comments found, all the property values in one array) - - #contacts - n:0-* - #value TEXT - ... array of String - param LANGUAGE ... don't support - param ALTREP ... don't support - - #exrules - n:0-* - #value RRULE - ... array of Rrule - - #exdates - n:0-* - #value DATE-TIME, or optionally DATE - ... array of Time, or Date? - param VALUE - param TZID supported? - - #rstatus - n:0-* - #value TEXT, kindof - ... array of class Status: - #code - #description - #extra - - #relationships "RELATED-TO" - n:0-* - #value TEXT - ... array of class Related: - #uid String - #type "PARENT"/ "CHILD" / "SIBLING" (parent is default) - #target ... a component? - - could use special handing: - - #parents (default) - #children - #siblings - - --> type should be components, that I look up by UID - - #rrule - #rdate - ... both may occur multiple times, how to handle? I think - I need a #recurrences that returns an object that has all the - rrules, rdates, and exceptional conditions in it, and returns - them in sorted order.... - - Not trivial! Definitely could use some test code. - - -; the following are optional, ; and MAY occur more than once - x-prop - - Give access to the underlying fields if they want to do something special. - - -For multi-valued properties where it might be useful to have access to the -params, sometime, I could do #comments(detailed=false) where detailed returns -objects if its needed. In the meantime, there's always the dirinfo APIs. - - -alarms... -n:0-* - ... array of Alarm: - - TBD... - -Notes: - - Vtodo - either 'due' or 'duration' may appear in a 'todoprop', but 'due' and - 'duration' - MUST NOT occur in the same 'todoprop' - - due - duration - - Vevent - either 'dtend' or 'duration' may appear in a 'eventprop', but 'dtend' - and 'duration' MUST NOT occur in the same 'eventprop' - - dtend - duration - - -Summary of properties by component type: - -can have *alarmc: - - vevent - vtodo - - -Done: Vtodo: Vevent: Vjournal: - - the following are optional, but MUST NOT occur more than once - -x class x x x -x created x x x -x description x x x -x dtstamp x x x -x dtstart x x x -x last-mod x x x -x organizer x x x - recurid x x x (postponed, iTip) -x seq x x x -x status x x x -x summary x x x -x uid x x x -x url x x x -x categories x x x -x comment x x x -x contact x x x -x attach x x x -x attendee x x x - related x x x (postponed, iTip) - rstatus x x x (postponed, iTip) - -x geo x x -x location x x -x priority x x -x resources x x - duration x x (done for Vevent, but needs more work) - -x completed x -x percent x -x due x - -x transp x -x dtend x - - -These all need handling together, its quite complex: - rrule x x x (single RRULE: is handled) - exdate x x x - exrule x x x - rdate x x x - ---> Download and use the UUID class from rubyforge. - -Valarm: - - - Required. -action -trigger - - Optional, but if 1, must have other. -duration -repeat - -attach -attendee -description -summary -x-prop - - - - -audioprop = 2*( - - ; 'action' and 'trigger' are both REQUIRED, - ; but MUST NOT occur more than once - - action / trigger / - - ; 'duration' and 'repeat' are both optional, - ; and MUST NOT occur more than once each, - ; but if one occurs, so MUST the other - - duration / repeat / - - ; the following is optional, - ; but MUST NOT occur more than once - - attach / - - ; the following is optional, - ; and MAY occur more than once - - x-prop - - ) - -dispprop = 3*( - - ; the following are all REQUIRED, - ; but MUST NOT occur more than once - - action / description / trigger / - - ; 'duration' and 'repeat' are both optional, - ; and MUST NOT occur more than once each, - ; but if one occurs, so MUST the other - - duration / repeat / - - ; the following is optional, - - ; and MAY occur more than once - - *x-prop - - ) - -emailprop = 5*( - - ; the following are all REQUIRED, - ; but MUST NOT occur more than once - - action / description / trigger / summary - - ; the following is REQUIRED, - ; and MAY occur more than once - - attendee / - - ; 'duration' and 'repeat' are both optional, - ; and MUST NOT occur more than once each, - ; but if one occurs, so MUST the other - - duration / repeat / - - ; the following are optional, - ; and MAY occur more than once - - attach / x-prop - - ) - -procprop = 3*( - - ; the following are all REQUIRED, - ; but MUST NOT occur more than once - - action / attach / trigger / - - ; 'duration' and 'repeat' are both optional, - ; and MUST NOT occur more than once each, - ; but if one occurs, so MUST the other - - duration / repeat / - - ; 'description' is optional, - ; and MUST NOT occur more than once - - description / - - ; the following is optional, - ; and MAY occur more than once - - x-prop - - ) - diff --git a/etc/ics-apple-observed.txt b/etc/ics-apple-observed.txt deleted file mode 100644 index e4bfb28..0000000 --- a/etc/ics-apple-observed.txt +++ /dev/null @@ -1,84 +0,0 @@ - - ... ; y/n (whether I've seen it in Apple's calendars) - name - section - type/comments - - - icalbody = icalprops component - - icalprops = - prodid / ; y PRODID 4.7.3 required, TEXT - version / ; y 4.7.4 required, TEXT, "2.0" - calscal / ; y 4.7.1 only defined value is GREGORIAN - method / ; n METHOD 4.7.2 used with transport protocols - - component = - eventc / ; y VEVENT 4.6.1 - todoc / ; y VTODO 4.6.2 - journalc / ; n - freebusyc / ; n - timezonec / ; n - - alarmc ; y VALARM 4.6.6 occurs inside a VEVENT or a VTODO - - class ; y CLASS 4.8.1.3 private/public/confidentical/... (default=public) - - comment ; n 4.8.1.4 TEXT - description ; y 4.8.1.5 TEXT - summary ; y 4.8.1.12 TEXT - location ; y 4.8.1.7 TEXT intended venue - - priority ; n why? 4.8.1.9 INTEGER, why isn't this seen for my TODO items? - - status ; y 4.8.1.11 TEXT, different values defined for event, todo, journal - - Event: TENTATIVE, CONFIRMED, CANCELLED - - Todo: NEEDS-ACTION, COMPLETED, IN-PROCESS, CANCELLED - - Journal: DRAFT, FINAL, CANCELLED - - dtstart ; y DTSTART 4.8.2.4 DATE-TIME is default, value=date can be set - dtend ; y DTEND 4.8.2.2 Unless it has Z (UTC), or a tzid, then it is local-time. - - dtstamp ; y DTSTAMP 4.8.7.2 DATE-TIME, creation time, inclusion is mandatory, but what does - it mean? It seems to be when the icalendar was actually created (as opposed to when the user entered - the information into the calendar database, for example), but in that case my Apple icalendars should - have all components having the same DTSTAMP, but they don't! - - duration ; y DURATION 4.8.2.5 dur-value - - dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) - - dur-date = dur-day [dur-time] - = 1*DIGIT "D" [ dur-time ] - - dur-time = "T" (dur-hour / dur-minute / dur-second) - = "T" ( - 1*DIGIT "H" [ 1*DIGIT "M" [ 1*DIGIT "S" ] ] / - 1*DIGIT "M" [ 1*DIGIT "S" ] / - 1*DIGIT "S" - ) - - dur-week = 1*DIGIT "W" - dur-day = 1*DIGIT "D" - dur-hour = 1*DIGIT "H" [dur-minute] - dur-minute = 1*DIGIT "M" [dur-second] - dur-second = 1*DIGIT "S" - - The EBNF is complicated, because they want to say that /some/ component - must be present, and that if you have a "T", you need a time after it, - and that you can't have an hour followed by seconds with no intervening - minutes... but we don't care about that during decoding, so we rewrite - the EBNF as: - - dur-value = ["+" / "-"] "P" [ 1*DIGIT "W" ] [ 1*DIGIT "D" ] [ "T" [ 1*DIGIT "H" ] [ 1*DIGIT "M" ] [ 1*DIGIT "S" ] ] - - dtdue ; n DTDUE 4.8.2.3 - - uid ; y UID 4.8.4.7 TEXT, recommended to generate them in RFC822 form - - rrule ; y RRULE 4.8.5.4 RECUR, can occur multiple times! - - diff --git a/etc/notes-ical.txt b/etc/notes-ical.txt deleted file mode 100644 index bfe7720..0000000 --- a/etc/notes-ical.txt +++ /dev/null @@ -1,108 +0,0 @@ -iCalendar is specified in RFC2445. It uses "BEGIN:VCALENDAR" with a version of "2.0". - -Here are all the lines used in my calendars, with non-unique ones removed: - -ACTION:DISPLAY -ACTION:EMAIL -ATTENDEE:mailto:sroberts@certicom.com -BEGIN:VALARM -BEGIN:VCALENDAR -BEGIN:VEVENT -BEGIN:VTODO -CALSCALE:GREGORIAN -CLASS:PRIVATE -DESCRIPTION:hot Docs 2003\nBloor Cinema\n\nFree!!\n -DTEND;TZID=Canada/Eastern:20031113T210000 -DTEND;VALUE=DATE:20040106 -DTSTAMP:20031125T035743Z -DTSTART;TZID=Canada/Eastern:20031113T200000 -DTSTART;VALUE=DATE:20031228 -DURATION:P1D -DURATION:PT1H -DURATION:PT1H30M -END:VALARM -END:VCALENDAR -END:VEVENT -END:VTODO -LOCATION:Wheel Club - Montreal -PRODID:-//Apple Computer\, Inc//iCal 1.0//EN - -RRULE:FREQ=DAILY;INTERVAL=1;UNTIL=20031117T045959Z -RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=2MO -RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=3SU -RRULE:FREQ=WEEKLY;INTERVAL=1 -RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=10 -RRULE:FREQ=YEARLY;INTERVAL=1;UNTIL=20031231T045959Z;BYMONTH=12 - - There is a definition of the value type in 4.3.10. - -SEQUENCE:11 -STATUS:CONFIRMED -SUMMARY:Julie in Sept Iles -TRIGGER;VALUE=DURATION:-P2D -TRIGGER;VALUE=DURATION:-PT15M -TRIGGER;VALUE=DURATION:-PT6H -UID:FF728BEF-8BF2-11D7-BE61-000393AD088C -VERSION:2.0 -X-WR-CALNAME;VALUE=TEXT:Holidays -X-WR-RELCALID;VALUE=TEXT:F46F3F6E-4C08-11D7-97C4-000393AD088C -X-WR-TIMEZONE;VALUE=TEXT:Canada/Eastern -X;MEMBER=AlarmLength;VALUE=TEXT:15 -X;MEMBER=AlarmUnits;VALUE=TEXT:minutes -X;MEMBER=AllDay;VALUE=TEXT:TRUE -X;MEMBER=RecurInterval;VALUE=TEXT:1 -X;MEMBER=RecurInterval;VALUE=TEXT:12 -X;MEMBER=RecurUnits;VALUE=TEXT:months -X;MEMBER=RecurUnits;VALUE=TEXT:years - - -The only parameters found were: - - ..member=[alarmlength] - ..member=[alarmunits] - ..member=[allday] - ..member=[recurinterval] - ..member=[recurunits] - - I don't think this is the MEMBER of 4.2.11, I think its iCal-specific. - - ..tzid=[canada/eastern] - - Should be a matching VTIMEZONE, shouldn't there be? - - ..value=[date] - -page 36, detailed description of date-time formats, utc, etc. Same as 2045? - - ..value=[duration] - - From 4.3.6 - - ..value=[text] - -Notes - -parameter names for vendors are structred, x-- - -prop parameter values NOT in quoted strings are case-insensitive - - --> encoding, create a field with a Date and have the value=date set automatically --> quote during encoding, if needed - -Do I handle encodings of 8bit? - -Errata: - -section 4.2.7, 'base64' is not an rfc2045 encoding type! - -section , pg 138, the content-type doesn't have a method MIME parameter matching -the METHOD parameter in the calendar object, as required. - -pg 139, the DESCRIPTION value is wrapped, but one word, 'Definition', is missing -the whitespace in front that was likely intended. - -section 4.6.1 claims dtstart is optional, but 4.8.2.4 days it is REQUIRED - - - diff --git a/etc/osx-addressbook.html b/etc/osx-addressbook.html deleted file mode 100644 index 1403163..0000000 --- a/etc/osx-addressbook.html +++ /dev/null @@ -1,10 +0,0 @@ - - -http://www.macdevcenter.com/pub/a/mac/2002/03/29/ibook_linux.html - -http://www.ddj.com/articles/2002/0205/ - -cocoadev.com - - - diff --git a/etc/rfc2234.txt b/etc/rfc2234.txt deleted file mode 100644 index edea302..0000000 --- a/etc/rfc2234.txt +++ /dev/null @@ -1,787 +0,0 @@ - - - - - - -Network Working Group D. Crocker, Ed. -Request for Comments: 2234 Internet Mail Consortium -Category: Standards Track P. Overell - Demon Internet Ltd. - November 1997 - - - Augmented BNF for Syntax Specifications: ABNF - - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1997). All Rights Reserved. - -TABLE OF CONTENTS - - 1. INTRODUCTION .................................................. 2 - - 2. RULE DEFINITION ............................................... 2 - 2.1 RULE NAMING .................................................. 2 - 2.2 RULE FORM .................................................... 3 - 2.3 TERMINAL VALUES .............................................. 3 - 2.4 EXTERNAL ENCODINGS ........................................... 5 - - 3. OPERATORS ..................................................... 5 - 3.1 CONCATENATION RULE1 RULE2 ............................. 5 - 3.2 ALTERNATIVES RULE1 / RULE2 ................................... 6 - 3.3 INCREMENTAL ALTERNATIVES RULE1 =/ RULE2 .................... 6 - 3.4 VALUE RANGE ALTERNATIVES %C##-## ........................... 7 - 3.5 SEQUENCE GROUP (RULE1 RULE2) ................................. 7 - 3.6 VARIABLE REPETITION *RULE .................................... 8 - 3.7 SPECIFIC REPETITION NRULE .................................... 8 - 3.8 OPTIONAL SEQUENCE [RULE] ..................................... 8 - 3.9 ; COMMENT .................................................... 8 - 3.10 OPERATOR PRECEDENCE ......................................... 9 - - 4. ABNF DEFINITION OF ABNF ....................................... 9 - - 5. SECURITY CONSIDERATIONS ....................................... 10 - - - - -Crocker & Overell Standards Track [Page 1] - -RFC 2234 ABNF for Syntax Specifications November 1997 - - - 6. APPENDIX A - CORE ............................................. 11 - 6.1 CORE RULES ................................................... 11 - 6.2 COMMON ENCODING .............................................. 12 - - 7. ACKNOWLEDGMENTS ............................................... 12 - - 8. REFERENCES .................................................... 13 - - 9. CONTACT ....................................................... 13 - - 10. FULL COPYRIGHT STATEMENT ..................................... 14 - -1. INTRODUCTION - - Internet technical specifications often need to define a format - syntax and are free to employ whatever notation their authors deem - useful. Over the years, a modified version of Backus-Naur Form - (BNF), called Augmented BNF (ABNF), has been popular among many - Internet specifications. It balances compactness and simplicity, - with reasonable representational power. In the early days of the - Arpanet, each specification contained its own definition of ABNF. - This included the email specifications, RFC733 and then RFC822 which - have come to be the common citations for defining ABNF. The current - document separates out that definition, to permit selective - reference. Predictably, it also provides some modifications and - enhancements. - - The differences between standard BNF and ABNF involve naming rules, - repetition, alternatives, order-independence, and value ranges. - Appendix A (Core) supplies rule definitions and encoding for a core - lexical analyzer of the type common to several Internet - specifications. It is provided as a convenience and is otherwise - separate from the meta language defined in the body of this document, - and separate from its formal status. - -2. RULE DEFINITION - -2.1 Rule Naming - - The name of a rule is simply the name itself; that is, a sequence of - characters, beginning with an alphabetic character, and followed by - a combination of alphabetics, digits and hyphens (dashes). - - NOTE: Rule names are case-insensitive - - The names , , and all refer - to the same rule. - - - - -Crocker & Overell Standards Track [Page 2] - -RFC 2234 ABNF for Syntax Specifications November 1997 - - - Unlike original BNF, angle brackets ("<", ">") are not required. - However, angle brackets may be used around a rule name whenever their - presence will facilitate discerning the use of a rule name. This is - typically restricted to rule name references in free-form prose, or - to distinguish partial rules that combine into a string not separated - by white space, such as shown in the discussion about repetition, - below. - -2.2 Rule Form - - A rule is defined by the following sequence: - - name = elements crlf - - where is the name of the rule, is one or more rule - names or terminal specifications and is the end-of- line - indicator, carriage return followed by line feed. The equal sign - separates the name from the definition of the rule. The elements - form a sequence of one or more rule names and/or value definitions, - combined according to the various operators, defined in this - document, such as alternative and repetition. - - For visual ease, rule definitions are left aligned. When a rule - requires multiple lines, the continuation lines are indented. The - left alignment and indentation are relative to the first lines of the - ABNF rules and need not match the left margin of the document. - -2.3 Terminal Values - - Rules resolve into a string of terminal values, sometimes called - characters. In ABNF a character is merely a non-negative integer. - In certain contexts a specific mapping (encoding) of values into a - character set (such as ASCII) will be specified. - - Terminals are specified by one or more numeric characters with the - base interpretation of those characters indicated explicitly. The - following bases are currently defined: - - b = binary - - d = decimal - - x = hexadecimal - - - - - - - - -Crocker & Overell Standards Track [Page 3] - -RFC 2234 ABNF for Syntax Specifications November 1997 - - - Hence: - - CR = %d13 - - CR = %x0D - - respectively specify the decimal and hexadecimal representation of - [US-ASCII] for carriage return. - - A concatenated string of such values is specified compactly, using a - period (".") to indicate separation of characters within that value. - Hence: - - CRLF = %d13.10 - - ABNF permits specifying literal text string directly, enclosed in - quotation-marks. Hence: - - command = "command string" - - Literal text strings are interpreted as a concatenated set of - printable characters. - - NOTE: ABNF strings are case-insensitive and - the character set for these strings is us-ascii. - - Hence: - - rulename = "abc" - - and: - - rulename = "aBc" - - will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC" and "ABC". - - To specify a rule which IS case SENSITIVE, - specify the characters individually. - - For example: - - rulename = %d97 %d98 %d99 - - or - - rulename = %d97.98.99 - - - - - -Crocker & Overell Standards Track [Page 4] - -RFC 2234 ABNF for Syntax Specifications November 1997 - - - will match only the string which comprises only lowercased - characters, abc. - -2.4 External Encodings - - External representations of terminal value characters will vary - according to constraints in the storage or transmission environment. - Hence, the same ABNF-based grammar may have multiple external - encodings, such as one for a 7-bit US-ASCII environment, another for - a binary octet environment and still a different one when 16-bit - Unicode is used. Encoding details are beyond the scope of ABNF, - although Appendix A (Core) provides definitions for a 7-bit US-ASCII - environment as has been common to much of the Internet. - - By separating external encoding from the syntax, it is intended that - alternate encoding environments can be used for the same syntax. - -3. OPERATORS - -3.1 Concatenation Rule1 Rule2 - - A rule can define a simple, ordered string of values -- i.e., a - concatenation of contiguous characters -- by listing a sequence of - rule names. For example: - - foo = %x61 ; a - - bar = %x62 ; b - - mumble = foo bar foo - - So that the rule matches the lowercase string "aba". - - LINEAR WHITE SPACE: Concatenation is at the core of the ABNF - parsing model. A string of contiguous characters (values) is - parsed according to the rules defined in ABNF. For Internet - specifications, there is some history of permitting linear white - space (space and horizontal tab) to be freelyPand - implicitlyPinterspersed around major constructs, such as - delimiting special characters or atomic strings. - - NOTE: This specification for ABNF does not - provide for implicit specification of linear white - space. - - Any grammar which wishes to permit linear white space around - delimiters or string segments must specify it explicitly. It is - often useful to provide for such white space in "core" rules that are - - - -Crocker & Overell Standards Track [Page 5] - -RFC 2234 ABNF for Syntax Specifications November 1997 - - - then used variously among higher-level rules. The "core" rules might - be formed into a lexical analyzer or simply be part of the main - ruleset. - -3.2 Alternatives Rule1 / Rule2 - - Elements separated by forward slash ("/") are alternatives. - Therefore, - - foo / bar - - will accept or . - - NOTE: A quoted string containing alphabetic - characters is special form for specifying alternative - characters and is interpreted as a non-terminal - representing the set of combinatorial strings with the - contained characters, in the specified order but with - any mixture of upper and lower case.. - -3.3 Incremental Alternatives Rule1 =/ Rule2 - - It is sometimes convenient to specify a list of alternatives in - fragments. That is, an initial rule may match one or more - alternatives, with later rule definitions adding to the set of - alternatives. This is particularly useful for otherwise- independent - specifications which derive from the same parent rule set, such as - often occurs with parameter lists. ABNF permits this incremental - definition through the construct: - - oldrule =/ additional-alternatives - - So that the rule set - - ruleset = alt1 / alt2 - - ruleset =/ alt3 - - ruleset =/ alt4 / alt5 - - is the same as specifying - - ruleset = alt1 / alt2 / alt3 / alt4 / alt5 - - - - - - - - -Crocker & Overell Standards Track [Page 6] - -RFC 2234 ABNF for Syntax Specifications November 1997 - - -3.4 Value Range Alternatives %c##-## - - A range of alternative numeric values can be specified compactly, - using dash ("-") to indicate the range of alternative values. Hence: - - DIGIT = %x30-39 - - is equivalent to: - - DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / - - "7" / "8" / "9" - - Concatenated numeric values and numeric value ranges can not be - specified in the same string. A numeric value may use the dotted - notation for concatenation or it may use the dash notation to specify - one value range. Hence, to specify one printable character, between - end of line sequences, the specification could be: - - char-line = %x0D.0A %x20-7E %x0D.0A - -3.5 Sequence Group (Rule1 Rule2) - - Elements enclosed in parentheses are treated as a single element, - whose contents are STRICTLY ORDERED. Thus, - - elem (foo / bar) blat - - which matches (elem foo blat) or (elem bar blat). - - elem foo / bar blat - - matches (elem foo) or (bar blat). - - NOTE: It is strongly advised to use grouping - notation, rather than to rely on proper reading of - "bare" alternations, when alternatives consist of - multiple rule names or literals. - - Hence it is recommended that instead of the above form, the form: - - (elem foo) / (bar blat) - - be used. It will avoid misinterpretation by casual readers. - - The sequence group notation is also used within free text to set off - an element sequence from the prose. - - - - -Crocker & Overell Standards Track [Page 7] - -RFC 2234 ABNF for Syntax Specifications November 1997 - - -3.6 Variable Repetition *Rule - - The operator "*" preceding an element indicates repetition. The full - form is: - - *element - - where and are optional decimal values, indicating at least - and at most occurrences of element. - - Default values are 0 and infinity so that * allows any - number, including zero; 1* requires at least one; - 3*3 allows exactly 3 and 1*2 allows one or two. - -3.7 Specific Repetition nRule - - A rule of the form: - - element - - is equivalent to - - *element - - That is, exactly occurrences of . Thus 2DIGIT is a - 2-digit number, and 3ALPHA is a string of three alphabetic - characters. - -3.8 Optional Sequence [RULE] - - Square brackets enclose an optional element sequence: - - [foo bar] - - is equivalent to - - *1(foo bar). - -3.9 ; Comment - - A semi-colon starts a comment that continues to the end of line. - This is a simple way of including useful notes in parallel with the - specifications. - - - - - - - - -Crocker & Overell Standards Track [Page 8] - -RFC 2234 ABNF for Syntax Specifications November 1997 - - -3.10 Operator Precedence - - The various mechanisms described above have the following precedence, - from highest (binding tightest) at the top, to lowest and loosest at - the bottom: - - Strings, Names formation - Comment - Value range - Repetition - Grouping, Optional - Concatenation - Alternative - - Use of the alternative operator, freely mixed with concatenations can - be confusing. - - Again, it is recommended that the grouping operator be used to - make explicit concatenation groups. - -4. ABNF DEFINITION OF ABNF - - This syntax uses the rules provided in Appendix A (Core). - - rulelist = 1*( rule / (*c-wsp c-nl) ) - - rule = rulename defined-as elements c-nl - ; continues if next line starts - ; with white space - - rulename = ALPHA *(ALPHA / DIGIT / "-") - - defined-as = *c-wsp ("=" / "=/") *c-wsp - ; basic rules definition and - ; incremental alternatives - - elements = alternation *c-wsp - - c-wsp = WSP / (c-nl WSP) - - c-nl = comment / CRLF - ; comment or newline - - comment = ";" *(WSP / VCHAR) CRLF - - alternation = concatenation - *(*c-wsp "/" *c-wsp concatenation) - - - - -Crocker & Overell Standards Track [Page 9] - -RFC 2234 ABNF for Syntax Specifications November 1997 - - - concatenation = repetition *(1*c-wsp repetition) - - repetition = [repeat] element - - repeat = 1*DIGIT / (*DIGIT "*" *DIGIT) - - element = rulename / group / option / - char-val / num-val / prose-val - - group = "(" *c-wsp alternation *c-wsp ")" - - option = "[" *c-wsp alternation *c-wsp "]" - - char-val = DQUOTE *(%x20-21 / %x23-7E) DQUOTE - ; quoted string of SP and VCHAR - without DQUOTE - - num-val = "%" (bin-val / dec-val / hex-val) - - bin-val = "b" 1*BIT - [ 1*("." 1*BIT) / ("-" 1*BIT) ] - ; series of concatenated bit values - ; or single ONEOF range - - dec-val = "d" 1*DIGIT - [ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ] - - hex-val = "x" 1*HEXDIG - [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ] - - prose-val = "<" *(%x20-3D / %x3F-7E) ">" - ; bracketed string of SP and VCHAR - without angles - ; prose description, to be used as - last resort - - -5. SECURITY CONSIDERATIONS - - Security is truly believed to be irrelevant to this document. - - - - - - - - - - - -Crocker & Overell Standards Track [Page 10] - -RFC 2234 ABNF for Syntax Specifications November 1997 - - -6. APPENDIX A - CORE - - This Appendix is provided as a convenient core for specific grammars. - The definitions may be used as a core set of rules. - -6.1 Core Rules - - Certain basic rules are in uppercase, such as SP, HTAB, CRLF, - DIGIT, ALPHA, etc. - - ALPHA = %x41-5A / %x61-7A ; A-Z / a-z - - BIT = "0" / "1" - - CHAR = %x01-7F - ; any 7-bit US-ASCII character, - excluding NUL - - CR = %x0D - ; carriage return - - CRLF = CR LF - ; Internet standard newline - - CTL = %x00-1F / %x7F - ; controls - - DIGIT = %x30-39 - ; 0-9 - - DQUOTE = %x22 - ; " (Double Quote) - - HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" - - HTAB = %x09 - ; horizontal tab - - LF = %x0A - ; linefeed - - LWSP = *(WSP / CRLF WSP) - ; linear white space (past newline) - - OCTET = %x00-FF - ; 8 bits of data - - SP = %x20 - - - -Crocker & Overell Standards Track [Page 11] - -RFC 2234 ABNF for Syntax Specifications November 1997 - - - ; space - - VCHAR = %x21-7E - ; visible (printing) characters - - WSP = SP / HTAB - ; white space - -6.2 Common Encoding - - Externally, data are represented as "network virtual ASCII", namely - 7-bit US-ASCII in an 8-bit field, with the high (8th) bit set to - zero. A string of values is in "network byte order" with the - higher-valued bytes represented on the left-hand side and being sent - over the network first. - -7. ACKNOWLEDGMENTS - - The syntax for ABNF was originally specified in RFC 733. Ken L. - Harrenstien, of SRI International, was responsible for re-coding the - BNF into an augmented BNF that makes the representation smaller and - easier to understand. - - This recent project began as a simple effort to cull out the portion - of RFC 822 which has been repeatedly cited by non-email specification - writers, namely the description of augmented BNF. Rather than simply - and blindly converting the existing text into a separate document, - the working group chose to give careful consideration to the - deficiencies, as well as benefits, of the existing specification and - related specifications available over the last 15 years and therefore - to pursue enhancement. This turned the project into something rather - more ambitious than first intended. Interestingly the result is not - massively different from that original, although decisions such as - removing the list notation came as a surprise. - - The current round of specification was part of the DRUMS working - group, with significant contributions from Jerome Abela , Harald - Alvestrand, Robert Elz, Roger Fajman, Aviva Garrett, Tom Harsch, Dan - Kohn, Bill McQuillan, Keith Moore, Chris Newman , Pete Resnick and - Henning Schulzrinne. - - - - - - - - - - - -Crocker & Overell Standards Track [Page 12] - -RFC 2234 ABNF for Syntax Specifications November 1997 - - -8. REFERENCES - - [US-ASCII] Coded Character Set--7-Bit American Standard Code for - Information Interchange, ANSI X3.4-1986. - - [RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, - "Standard for the Format of ARPA Network Text Message," RFC 733, - November 1977. - - [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text - Messages", STD 11, RFC 822, August 1982. - -9. CONTACT - - David H. Crocker Paul Overell - - Internet Mail Consortium Demon Internet Ltd - 675 Spruce Dr. Dorking Business Park - Sunnyvale, CA 94086 USA Dorking - Surrey, RH4 1HN - UK - - Phone: +1 408 246 8253 - Fax: +1 408 249 6205 - EMail: dcrocker@imc.org paulo@turnpike.com - - - - - - - - - - - - - - - - - - - - - - - - - - -Crocker & Overell Standards Track [Page 13] - -RFC 2234 ABNF for Syntax Specifications November 1997 - - -10. Full Copyright Statement - - Copyright (C) The Internet Society (1997). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Crocker & Overell Standards Track [Page 14] - diff --git a/etc/rfc2425-ex.txt b/etc/rfc2425-ex.txt deleted file mode 100644 index ce82f32..0000000 --- a/etc/rfc2425-ex.txt +++ /dev/null @@ -1,87 +0,0 @@ - cn:Babs Jensen - cn:Barbara J Jensen - sn:Jensen - email:babs@umich.edu - phone:+1 313 747-4454 - x-id:1234567890 - -Content-Type: text/directory; - charset="iso-8859-1"; - profile="vCard" -Content-ID: -Content-Transfer-Encoding: Quoted-Printable - -begin:VCARD -source:ldap://cn=bjorn%20Jensen, o=university%20of%20Michigan, c=US -name:Bjorn Jensen -fn:Bj=F8rn Jensen -n:Jensen;Bj=F8rn -email;type=internet:bjorn@umich.edu -tel;type=work,voice,msg:+1 313 747-4454 -key;type=x509;encoding=B:dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlmaWNhdGUK -end:VCARD - -Content-Type: text/directory; profile="vcard"; charset=iso-8859-1 -Content-ID: -Content-Transfer-Encoding: Quoted-Printable - -begin:vcard -source:ldap://cn=Meister%20Berger,o=Universitaet%20Goerlitz,c=DE -name:Meister Berger -fn:Meister Berger -n:Berger;Meister -bday;value=date:1963-09-21 -o:Universit=E6t G=F6rlitz -title:Mayor -title;language=de;value=text:Burgermeister -note:The Mayor of the great city of - Goerlitz in the great country of Germany. -email;internet:mb@goerlitz.de -home.tel;type=fax,voice,msg:+49 3581 123456 -home.label:Hufenshlagel 1234\n - 02828 Goerlitz\n - Deutschland -key;type=X509;encoding=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQ - AwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zI - ENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQD - ExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNjE5NDc1OVoXDTk3MTIwMzE5NDc - 1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYDVQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW - 9ucyBDb3JwLjEYMBYGA1UEAxMPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBF - hJob3dlc0BuZXRzY2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqG - SIb3DQEBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2dXc - oX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MBEGCWCGSAGG+E - IBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9 - w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIPmx93HGp0Kgyx1jIVMyNgsemeAwBM+M - SlhMfcpbTrONwNjZYW8vJDSoi//yrZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8V - UMk1U7jt8LYpo4YULU7UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ== -end:vcard - - -source:ldap://cn=Bjorn%20Jensen,o=University%20of%20Michigan,c=US -cn:Bj=F8rn Jensen -sn:Jensen -email:bjorn@umich.edu -image;value=uri:cid:id6@host.com -image;value=uri;format=jpeg:ftp://some.host/some/path.jpg -sound;value=uri:cid:id7@host.com -phone:+1 313 747-4454 - ---woof -Content-Type: image/jpeg -Content-ID: - -<...image data...> - ---woof -Content-Type: message/external-body; - name="myvoice.au"; - site="myhost.com"; - access-type=ANON-FTP; - directory="pub/myname"; - mode="image" - -Content-Type: audio/basic -Content-ID: - ---woof-- - diff --git a/etc/rfc2425.txt b/etc/rfc2425.txt deleted file mode 100644 index 2e37e24..0000000 --- a/etc/rfc2425.txt +++ /dev/null @@ -1,1851 +0,0 @@ - - - - - - -Network Working Group T. Howes -Request for Comments: 2425 M. Smith -Category: Standards Track Netscape Communications Corp. - F. Dawson - Lotus Development Corporation - September 1998 - - - A MIME Content-Type for Directory Information - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -1. Abstract - - This document defines a MIME Content-Type for holding directory - information. The definition is independent of any particular - directory service or protocol. The text/directory Content-Type is - defined for holding a variety of directory information, for example, - name, or email address, or logo. The text/directory Content-Type can - also be used as the root body part in a multipart/related Content- - Type for handling more complicated situations, especially those in - which non-textual information that already has a natural MIME - representation, for example, a photograph or sound, is to be - represented. - - The text/directory Content-Type defines a general framework and - format for holding directory information in a simple "type:value" - form. We refer to "type" in this context meaning a property or - attribute with which the value is associated. Mechanisms are defined - to specify alternate languages, encodings and other meta-information. - This document also defines the procedure by which particular formats, - called profiles, for carrying application-specific information within - a text/directory Content-Type can be defined and registered, and the - conventions such formats must follow. It is expected that other - documents will be produced that define such formats for various - applications (e.g., white pages). - - - - - -Howes, et. al. Standards Track [Page 1] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this - document are to be interpreted as described in [RFC-2119]. - -2. Table of Contents - - Status of the Memo................................................ 1 - Copyright Notice.................................................. 1 - 1. Abstract...................................................... 1 - 2. Table of Contents............................................. 2 - 3. Need for a MIME Directory Type................................ 3 - 4. Overview...................................................... 4 - 5. The text/directory Content-Type............................... 4 - 5.1. MIME media type name........................................ 4 - 5.2. MIME subtype name........................................... 5 - 5.3. Required parameters......................................... 5 - 5.4. Optional parameters......................................... 5 - 5.5. Encoding considerations..................................... 5 - 5.6. Security considerations..................................... 6 - 5.7. Interoperability considerations............................. 6 - 5.8. Published specification..................................... 6 - 5.8.1. Line delimiting and folding............................... 6 - 5.8.2. ABNF content-type definition.............................. 7 - 5.8.3. Pre-defined Parameters.................................... 9 - 5.8.4. Pre-defined Value Types...................................11 - 5.9. Applications which use this media type......................14 - 5.10. Additional information.....................................14 - 5.11. Person & email address to contact for further information..14 - 5.12. Intended usage.............................................14 - 5.13. Author/Change controller...................................15 - 6. Predefined Types..............................................15 - 6.1. SOURCE Type Definition......................................15 - 6.2. NAME Type Definition........................................16 - 6.3. PROFILE Type Definition.....................................16 - 6.4. BEGIN Type Definition.......................................17 - 6.5. END Type Definition.........................................17 - 7. Use of the multipart/related Content-Type.....................18 - 8. Examples.......................................................18 - 8.1. Example 1...................................................19 - 8.2. Example 2...................................................19 - 8.3. Example 3...................................................20 - 8.4. Example 4...................................................21 - 9. Registration of new profiles..................................22 - 9.1. Define the profile..........................................22 - 9.2. Post the profile definition.................................23 - 9.3. Allow a comment period......................................23 - 9.4. Submit the profile for approval.............................23 - 10. Profile Change Control.......................................23 - - - -Howes, et. al. Standards Track [Page 2] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - 11. Registration of new types....................................24 - 11.1. Define the type............................................24 - 11.2. Post the type definition...................................25 - 11.3. Allow a comment period.....................................25 - 11.4. Submit the type for approval...............................25 - 12. Type Change Control..........................................25 - 13. Registration of new parameters...............................26 - 13.1. Define the parameter.......................................26 - 13.2. Post the parameter definition..............................27 - 13.3. Allow a comment period.....................................27 - 13.4. Submit the parameter for approval..........................27 - 14. Parameter Change Control.....................................28 - 15. Registration of new value types..............................28 - 15.1. Define the value type......................................28 - 15.2. Post the value type definition.............................29 - 15.3. Allow a comment period.....................................29 - 15.4. Submit the value type for approval.........................29 - 16. Security Considerations......................................30 - 17. Acknowledgements..............................................30 - 18. References....................................................30 - 19. Authors' Addresses...........................................32 - 20. Full Copyright Statement......................................33 - -3. Need for a MIME Directory Type - - For purposes of this document, a directory is a special-purpose - database that contains typed information. A directory usually - supports both read and search of the information it contains, and can - support creation and modification of the information as well. - Directory information is usually accessed far more often than it is - updated. Directories can be local or global in scope. They can be - distributed or centralized. The information they contain can be - replicated, with weak or strong consistency requirements. - - There are several situations in which users of Internet mail might - wish to exchange directory information: the email analogy of a - "business card" exchange; the conveyance of directory information to - a user having only email access to the Internet; the provision of - machine-parseable address information when purchasing goods or - services over the Internet; etc. As MIME [RFC-2045, RFC-2046] is - used increasingly by other protocols, most notably HTTP, it can also - be useful for these protocols to carry directory information in MIME - format. Such a format, for example, could be used to represent URC - (uniform resource characteristics) information about resources on the - World Wide Web, or to provide a rudimentary directory service over - HTTP. - - - - - -Howes, et. al. Standards Track [Page 3] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - -4. Overview - - The scheme defined here for representing directory information in a - MIME Content-Type has two parts. First, the text/directory Content- - Type is defined for use in holding directory information within a - single body part, for example name, title, or email address. In its - simplest form, the format uses a "type:value" approach, which should - be easily parseable by existing MIME implementations and - understandable by users. More complicated situations can be - represented also. This document defines the general form the - information in the Content-Type should have, and the procedure by - which specific types and values (properties) for particular - applications can be defined. The framework is general enough to - handle information from any number of end directory services, - including LDAP [RFC-1777, RFC-1778], WHOIS++ [RFC-1835], and X.500 - [X500]. - - Directory entries can include far more than just textual information. - Some such information (e.g., an image or sound) overlaps with - predefined MIME Content-Types. In these cases it can be desirable to - include the information in its well-known MIME format. This situation - is handled by using a multipart/related Content-Type as defined in - [RFC-2112]. The root component of this type is a text/directory body - part specifying any in-line information, and for information - contained in other Content-Types, the Content-IDs (in URI form) of - those parts. - - In some applications, it can be useful to include a pointer (e.g, a - URI) to some directory information rather than the information - itself. This document defines a general mechanism for accomplishing - this. - -5. The text/directory Content-Type - - The text/directory Content-Type is used to hold basic directory - information and URIs referencing other information, including other - MIME body parts holding supplementary or non-textual directory - information, such as an image or sound. It is defined as follows, - using the MIME media type registration template from [RFC-2048]. - - To: ietf-types@uninett.no - Subject: Registration of MIME media type text/directory - -5.1. MIME media type name - - MIME media type name: text - - - - - -Howes, et. al. Standards Track [Page 4] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - -5.2. MIME subtype name - - MIME subtype name: directory - -5.3. Required parameters - - Required parameters: charset - - The "charset" parameter is as defined in [RFC-2046] for other body - parts. It is used to identify the default character set used within - the body part. - -5.4. Optional parameters - - Optional parameters: profile - - The "profile" parameter is used to convey the type(s) of entity(ies) - to which the directory information pertains and the likely set of - information associated with the entity(ies). It is intended only as a - guide to applications interpreting the information contained within - the body part. It SHOULD NOT be used to exclude or require particular - pieces of information unless a profile definition specifically calls - for this behavior. Unless specifically forbidden by a particular - profile definition, a text/directory content type can contain - arbitrary attribute/value pairs. - - The value of the "profile" parameter is defined as follows. Profile - names are case insensitive (i.e., the profile name "vCard" is the - same as "VCARD" and "vcard" and "vcArD"). - - profile = x-name / iana-token - - x-name = "x-" 1*(ALPHA / DIGIT / "-") - ; Names beginning with "x-" or "X-" are - ; reserved for experimental use not intended for released - ; products, or for use in bilateral agreements. - - iana-token = - -5.5. Encoding considerations - - The default encoding is 8bit. Otherwise, as specified by the - Content-Transfer-Encoding header field. - - - - - - -Howes, et. al. Standards Track [Page 5] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - -5.6. Security considerations - - Directory information can be public or it can be protected from - unauthorized access by the directory service in which it resides. - Once the information leaves its native service, there can be no - guarantee that the same care will be taken by all services handling - the information. Furthermore, this specification defines no access - control mechanism by which information can be protected, or by which - access control information can be conveyed. Note that the integrity - and privacy of a text/directory body part can be protected by - enclosing it within an appropriate MIME-based security mechanism. - -5.7. Interoperability considerations - - In order to make sense of directory information, applications must - share a common understanding of the types of information contained - within the Content-Type (the directory schema). This schema - information is not defined in this document, but rather in companion - documents (e.g., [MIME-VCARD]) that follow the requirements specified - in this document, or in bilateral agreements between communicating - parties. - -5.8. Published specification - - The text/directory Content-Type contains directory information, - typically pertaining to a single directory entity or group of - entities. The content consists of one or more lines in the format - given below. - -5.8.1. Line delimiting and folding - - Individual lines within the MIME text/directory Content Type body are - delimited by the [RFC-822] line break, which is a CRLF sequence - (ASCII decimal 13, followed by ASCII decimal 10). Long logical lines - of text can be split into a multiple-physical-line representation - using the following folding technique. - - A logical line MAY be continued on the next physical line anywhere - between two characters by inserting a CRLF immediately followed by a - single white space character (space, ASCII decimal 32, or horizontal - tab, ASCII decimal 9). At least one character must be present on the - folded line. Any sequence of CRLF followed immediately by a single - white space character is ignored (removed) when processing the - content type. For example the line: - - DESCRIPTION:This is a long description that exists on a long line. - - Can be represented as: - - - -Howes, et. al. Standards Track [Page 6] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - DESCRIPTION:This is a long description - that exists on a long line. - - It could also be represented as: - - DESCRIPTION:This is a long descrip - tion that exists o - n a long line. - - The process of moving from this folded multiple-line representation - of a type definition to its single line representation is called - unfolding. Unfolding is accomplished by regarding CRLF immediately - followed by a white space character (namely HTAB ASCII decimal 9 or - SPACE ASCII decimal 32) as equivalent to no characters at all (i.e., - the CRLF and single white space character are removed). - -5.8.2. ABNF content-type definition - - The following ABNF uses the notation of RFC 2234, which also defines - CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT. After the unfolding of - any folded lines as described above, the syntax for a line of this - content type is as follows: - - contentline = [group "."] name *(";" param) ":" value CRLF - ; When parsing a content line, folded lines MUST first - ; be unfolded according to the unfolding procedure - ; described above. - ; When generating a content line, lines longer than 75 - ; characters SHOULD be folded according to the folding - ; procedure described above. - - group = 1*(ALPHA / DIGIT / "-") - - name = x-name / iana-token - - iana-token = 1*(ALPHA / DIGIT / "-") - ; identifier registered with IANA - - x-name = "x-" 1*(ALPHA / DIGIT / "-") - ; Names that begin with "x-" or "X-" are - ; reserved for experimental use, not intended for released - ; products, or for use in bilateral agreements. - - param = param-name "=" param-value *("," param-value) - - param-name = x-name / iana-token - - param-value = ptext / quoted-string - - - -Howes, et. al. Standards Track [Page 7] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - ptext = *SAFE-CHAR - - value = *VALUE-CHAR - / valuespec ; valuespec defined in section 5.8.4 - - quoted-string = DQUOTE *QSAFE-CHAR DQUOTE - - NON-ASCII = %x80-FF - ; use restricted by charset parameter - ; on outer MIME object (UTF-8 preferred) - - QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-ASCII - ; Any character except CTLs, DQUOTE - - SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII - ; Any character except CTLs, DQUOTE, ";", ":", "," - - VALUE-CHAR = WSP / VCHAR / NON-ASCII - ; any textual character - - A line that begins with a white space character is a continuation of - the previous line, as described above. The white space character and - immediately preceeding CRLF should be discarded when reconstructing - the original line. Note that this line-folding convention differs - from that found in RFC 822, in that the sequence found - anywhere in the content indicates a continued line and should be - removed. - - Various type names and the format of the corresponding values are - defined as specified in Section 11. Specifications MAY impose - ordering on the type constructs within a body part, though none is - required by default. The various x-name constructs are used for - bilaterally-agreed upon type names, parameter names and parameter - values, or for use in experimental settings. - - Type names and parameter names are case insensitive (e.g., the type - name "fn" is the same as "FN" and "Fn"). Parameter values MAY be case - sensitive or case insensitive, depending on their definition. - - The group construct is used to group related attributes together. - The group name is a syntactic convention used to indicate that all - type names prefaced with the same group name SHOULD be grouped - together when displayed by an application. It has no other - significance. Implementations that do not understand or support - grouping MAY simply strip off any text before a "." to the left of - the type name and present the types and values as normal. - - - - - -Howes, et. al. Standards Track [Page 8] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - Each attribute defined in the text/directory body MAY have multiple - values, if allowed in the definition of the profile in which the - attribute is used. The general rule for encoding multi-valued items - is to simply create a new content line for each value (including the - type name). However, it should be noted that some value types - support encoding multiple values in a single content line by - separating the values with a comma ",". This approach has been taken - for several of the content types defined below (date, time, integer, - float), for space-saving reasons. - -5.8.3. Pre-defined Parameters - - The following parameters and value types are defined for general use. - - predefined-param = encodingparm - / valuetypeparm - / languageparm - / contextparm - - encodingparm = "encoding" "=" encodingtype - - encodingtype = "b" ; from RFC 2047 - / iana-token ; registered as described in - ; section 15 of this document - - valuetypeparm = "value" "=" valuetype - - valuetype = "uri" ; genericurl from secion 5 of RFC 1738 - / "text" - / "date" - / "time" - / "date-time" ; date time - / "integer" - / "boolean" - / "float" - / x-name - / iana-token ; registered as described in - ; section 15 of this document - - languageparm = "language" "=" Language-Tag - ; Language-Tag is defined in section 2 of RFC 1766 - - contextparm = "context" "=" context - - context = x-name - / iana-token - - - - - -Howes, et. al. Standards Track [Page 9] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - The "language" type parameter is used to identify data in multiple - languages. There is no concept of "default" language, except as - specified by any "Content-Language" MIME header parameter that is - present. The value of the "language" type parameter is a language - tag as defined in Section 2 of [RFC-1766]. - - The "context" type parameter is used to identify a context (e.g., a - protocol) used in interpreting the value. This is used, for example, - in the "source" type, defined below. - - The "encoding" type parameter is used to specify an alternate - encoding for a value. If the value contains a CRLF, it must be - encoded, since CRLF is used to separate lines in the content-type - itself. Currently, only the "b" encoding is supported. - - The "b" encoding can also be useful for binary values that are mixed - with other text information in the body part (e.g., a certificate). - Using a per-value "b" encoding in this case leaves the other - information in a more readable form. The encoded base 64 value can be - split across multiple physical lines in the content type by using the - line folding technique described above. - - The Content-Transfer-Encoding header field is used to specify the - encoding used for the body part as a whole. The "encoding" type - parameter is used to specify an encoding for a particular value - (e.g., a certificate). In this case, the Content-Transfer-Encoding - header might specify "8bit", while the one certificate value might - specify an encoding of "b" via an "encoding=b" type parameter. - - The Content-Transfer-Encoding and the encodings of individual types - given by the "encoding" type parameter are independent of one - another. When encoding a text/directory body part for transmission, - individual type encodings are performed first, then the entire body - part is encoded according to the Content-Transfer-Encoding. When - decoding a text/directory body part, the Content-Transfer-Encoding is - decoded first, and then any individual types with an "encoding" type - parameter are decoded. - - The "value" parameter is optional, and is used to identify the value - type (data type) and format of the value. The use of these - predefined formats is encouraged even if the value parameter is not - explicity used. By defining a standard set of value types and their - formats, existing parsing and processing code can be leveraged. - - Including the value type explicitly as part of each property provides - an extra hint to keep parsing simple and support more generalized - applications. For example a search engine would not have to know the - particular value types for all of the items for which it is - - - -Howes, et. al. Standards Track [Page 10] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - searching. Because the value type is explicit in the definition, the - search engine could look for dates in any item type and provide - results that can still be interpreted. - -5.8.4. Pre-defined Value Types - - The format for values corresponding to the predefined valuetype - specifications given above are defined. - - valuespec = text-list - / genericurl ; from section 5 of RFC 1738 - / date-list - / time-list - / date-time-list - / boolean - / integer-list - / float-list - / iana-valuespec - - text-list = *TEXT-LIST-CHAR *("," *TEXT-LIST-CHAR) - - TEXT-LIST-CHAR = "\\" / "\," / "\n" - / - ; Backslashes, newlines, and commas must be encoded. - ; \n or \N can be used to encode a newline. - - date-list = date *("," date) - - time-list = time *("," time) - - date-time-list = date "T" time *("," date "T" time) - - boolean = "TRUE" / "FALSE" - - integer-list = integer *("," integer) - - integer = [sign] 1*DIGIT - - float-list = float *("," float) - - float = [sign] 1*DIGIT ["." 1*DIGIT] - - sign = "+" / "-" - - date = date-fullyear ["-"] date-month ["-"] date-mday - - date-fullyear = 4 DIGIT - - - - -Howes, et. al. Standards Track [Page 11] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - date-month = 2 DIGIT ;01-12 - - date-mday = 2 DIGIT ;01-28, 01-29, 01-30, 01-31 - ;based on month/year - - time = time-hour [":"] time-minute [":"] time-second [time-secfrac] - [time-zone] - - time-hour = 2 DIGIT ;00-23 - - time-minute = 2 DIGIT ;00-59 - - time-second = 2 DIGIT ;00-60 (leap second) - - time-secfrac = "," 1*DIGIT - - time-zone = "Z" / time-numzone - - time-numzome = sign time-hour [":"] time-minute - - iana-valuespec = - - Some specific notes on the value types and formats: - - "text": The "text" value type should be used to identify values that - contain human-readable text. The character set and language in which - the text is represented is controlled by the charset content-header - and the language type parameter and content-header. - - Examples for "text": - this is a text value - this is one value,this is another - this is a single value\, with a comma encoded - - A formatted text line break in a text value type MUST be represented - as the character sequence backslash (ASCII decimal 92) followed by a - Latin small letter n (ASCII decimal 110) or a Latin capital letter N - (ASCII decimal 78), that is "\n" or "\N". - - For example a multiple line DESCRIPTION value of: - - Mythical Manager - Hyjinx Software Division - BabsCo, Inc. - - could be represented as: - - - -Howes, et. al. Standards Track [Page 12] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - DESCRIPTION:Mythical Manager\nHyjinx Software Division\n - BabsCo\, Inc.\n - - demonstrating the \n literal formatted line break technique, the - CRLF-followed-by-space line folding technique, and the backslash - escape technique. - - "uri": The "uri" value type should be used to identify values that - are referenced by a URI (including a Content-ID URI), instead of - encoded in-line. These value references might be used if the value is - too large, or otherwise undesirable to include directly. The format - for the URI is as defined in RFC 1738. - - Examples for "uri": - http://www.foobar.com/my/picture.jpg - ldap://ldap.foobar.com/cn=babs%20jensen - - "date", "time", and "date-time": Each of these value types is based - on a subset of the definitions in ISO 8601 standard. Profiles MAY - place further restrictions on "date" and "time" values. Multiple - "date" and "time" values can be specified using the comma-separated - notation, unless restricted by a profile. - - Examples for "date": - 1985-04-12 - 1996-08-05,1996-11-11 - 19850412 - - Examples for "time": - 10:22:00 - 102200 - 10:22:00.33 - 10:22:00.33Z - 10:22:33,11:22:00 - 10:22:00-08:00 - - Examples for "date-time": - 1996-10-22T14:00:00Z - 1996-08-11T12:34:56Z - 19960811T123456Z - 1996-10-22T14:00:00Z,1996-08-11T12:34:56Z - - "boolean": The "boolean" value type is used to express boolen values. - These values are case insensitive. - - Examples: TRUE - false - True - - - -Howes, et. al. Standards Track [Page 13] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - "integer": The "integer" value type is used to express signed - integers in decimal format. If sign is not specified, the value is - assumed positive "+". Multiple "integer" values can be specified - using the comma-separated notation, unless restricted by a profile. - - Examples: 1234567890 - -1234556790 - +1234556790,432109876 - - "float": The "float" value type is used to express real numbers. If - sign is not specified, the value is assumed positive "+". Multiple - "float" values can be specified using the comma-separated notation, - unless restricted by a profile. - - Examples: 20.30 - 1000000.0000001 - 1.333,3.14 - -5.9. Applications which use this media type - - Applications which use this media type: Various - -5.10. Additional information - - Additional information: None - -5.11. Person & email address to contact for further information - - Tim Howes - Netscape Communications Corp. - 501 East Middlefield Rd. - Mountain View, CA 94041 - USA - howes@netscape.com - +1 415 937 3419 - -5.12. Intended usage - - Intended usage: COMMON - - - - - - - - - - - - -Howes, et. al. Standards Track [Page 14] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - -5.13. Author/Change controller - - Tim Howes - Netscape Communications Corp. - 501 East Middlefield Rd. - Mountain View, CA 94041 - USA - howes@netscape.com - +1 415 937 3419 - - Mark Smith - Netscape Communications Corp. - 501 East Middlefield Rd. - Mountain View, CA 94041 - USA - mcs@netscape.com - +1 415 937 3477 - - Frank Dawson - Lotus Development Corporation - 6544 Battleford Drive - Raleigh, NC 27613-3502 - USA - frank_dawson@lotus.com - +1-919-676-9515 - -6. Predefined Types - - The following types are generally useful regardless of the profile - being carried and are defined below using the text/directory MIME - type registration template defined in Section 11.1 of this document. - These types MAY be included in any profile, unless explicitly - forbidden in the profile definition. - -6.1. SOURCE Type Definition - - To: ietf-mime-direct@imc.org - Subject: Registration of text/directory MIME type SOURCE - - Type name: SOURCE - - Type purpose: To identify the source of directory information - contained in the content type. - - Type encoding: 8bit - - Type valuetype: uri - - - - -Howes, et. al. Standards Track [Page 15] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - Type special notes: The SOURCE type is used to provide the means by - which applications knowledgable in the given directory service - protocol can obtain additional or more up-to-date information from - the directory service. It contains a URI as defined in [RFC-1738] - and/or other information referencing the directory entity or entities - to which the information pertains. When directory information is - available from more than one source, the sending entity can pick what - it considers to be the best source, or multiple SOURCE types can be - included. The interpretation of the value for a SOURCE type can - depend on the setting of the CONTEXT type parameter. The value of the - CONTEXT type parameter MUST be compatible with the value of the uri - prefix. - - Type example: - SOURCE;CONTEXT=LDAP:ldap://ldap.host/cn=Babs%20Jensen, - %20o=Babsco,%20c=US - -6.2. NAME Type Definition - - To: ietf-mime-direct@imc.org - Subject: Registration of text/directory MIME type NAME - - Type name: NAME - - Type purpose: To identify the displayable name of the directory - entity to which information in the content type pertains. - - Type encoding: 8bit - - Type valuetype: text - - Type special notes: The NAME type is used to convey the display name - of the entity to which the directory information pertains. - - Type example: - NAME:Babs Jensen's Contact Information - -6.3. PROFILE Type Definition - - To: ietf-mime-direct@imc.org - Subject: Registration of text/directory MIME type PROFILE - - Type name: PROFILE - - Type purpose: To identify the type of directory entity to which - information in the content type pertains. - - Type encoding: 8bit - - - -Howes, et. al. Standards Track [Page 16] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - Type valuetype: A profile name, registered as described in Section 9 - of this document or bilaterally agreed upon as described in Section - 5. - - Type special notes: The PROFILE type is used to convey the type of - the entity to which the directory information in the rest of the body - part pertains. It should be the same as the "profile" header - parameter, if present. - - Type example: - PROFILE:vCard - -6.4. BEGIN Type Definition - - To: ietf-mime-direct@imc.org - Subject: Registration of text/directory MIME type BEGIN - - Type name: BEGIN - - Type purpose: To denote the beginning of a syntactic entity within a - text/directory content-type. - - Type encoding: 8bit - - Type valuetype: text, containing a profile name, registered as - described in Section 9 of this document or bilaterally-agreed upon as - described in Section 5. - - Type special notes: The BEGIN type is used in conjunction with the - END type to delimit a profile containing a related set of properties - within an text/directory content-type. This construct can be used - instead of or in addition to wrapping separate sets of information - inside additional MIME headers. It is provided for applications that - wish to define content that can contain multiple entities within the - same text/directory content-type or to define content that can be - identifiable outside of a MIME environment. - - Type example: - BEGIN:VCARD - -6.5. END Type Definition - - To: ietf-mime-direct@imc.org - Subject: Registration of text/directory MIME type END - - Type name: END - - - - - -Howes, et. al. Standards Track [Page 17] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - Type purpose: To denote the end of a syntactic entity within a - text/directory content-type. - - Type encoding: 8bit - - Type valuetype: text, containing a profile name, registered as - described in Section 9 of this document or bilaterally-agreed upon as - described in Section 5. - - Type special notes: The END type is used in conjunction with the - BEGIN type to delimit a profile containing a related set of - properties within an text/directory content-type. This construct can - be used instead of or in addition to wrapping separate sets of - information inside additional MIME headers. It is provided for - applications that wish to define content that can contain multiple - entities within the same text/directory content-type or to define - content that can be identifiable outside of a MIME environment. - - Type example: - END: VCARD - -7. Use of the multipart/related Content-Type - - The multipart/related Content-Type can be used to hold directory - information comprised of both text and non-text information or - directory information that already has a natural MIME representation. - The root body part within the multipart/related body part is - specified as defined in [RFC-2112] by a "start" parameter, or it is - the first body part in the absence of such a parameter. The root - body part must have a Content-Type of "text/directory". This part - holds inline information and makes reference to subsequent body parts - holding additional text or non-text directory information via their - Content-ID URIs as explained in Section 5. - - The body parts referred to do not have to be in any particular order, - except as noted above for the root body part. - -8. Examples - - The following examples are for illustrative purposes only and are not - part of the definition. - - - - - - - - - - -Howes, et. al. Standards Track [Page 18] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - -8.1. Example 1 - - The first example illustrates simple use of the text/directory - Content-Type. Note that no "profile" parameter is given, so an - application may not know what kind of directory entity the - information applies to. Note also the use of both hypothetical - official and bilaterally agreed upon types. - - From: Whomever@wherever.com - To: Someone@somewhere.com - Subject: whatever - MIME-Version: 1.0 - Message-ID: - Content-Type: text/directory - Content-ID: - - cn:Babs Jensen - cn:Barbara J Jensen - sn:Jensen - email:babs@umich.edu - phone:+1 313 747-4454 - x-id:1234567890 - -8.2. Example 2 - - The next example illustrates the use of the Quoted-Printable transfer - encoding defined in [RFC 2045] to include non-ASCII character in some - of the information returned, and the use of the optional "name" and - "source" types. It also illustrates the use of an "encoding" type - parameter to encode a certificate value in "b". A "vCard" profile - [MIME- VCARD] is used for the example. - -Content-Type: text/directory; - charset="iso-8859-1"; - profile="vCard" -Content-ID: -Content-Transfer-Encoding: Quoted-Printable - -begin:VCARD -source:ldap://cn=bjorn%20Jensen, o=university%20of%20Michigan, c=US -name:Bjorn Jensen -fn:Bj=F8rn Jensen -n:Jensen;Bj=F8rn -email;type=internet:bjorn@umich.edu -tel;type=work,voice,msg:+1 313 747-4454 -key;type=x509;encoding=B:dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlmaWNhdGUK -end:VCARD - - - - -Howes, et. al. Standards Track [Page 19] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - -8.3. Example 3 - - The next example illustrates the use of multi-valued type parameters, - the "language" type parameter, the "value" type parameter, folding of - long lines, the \n encoding for formatted lines, attribute grouping, - and the inline "b" encoding. A "vCard" profile [MIME-VCARD] is used - for the example. - -Content-Type: text/directory; profile="vcard"; charset=iso-8859-1 -Content-ID: -Content-Transfer-Encoding: Quoted-Printable - -begin:vcard -source:ldap://cn=Meister%20Berger,o=Universitaet%20Goerlitz,c=DE -name:Meister Berger -fn:Meister Berger -n:Berger;Meister -bday;value=date:1963-09-21 -o:Universit=E6t G=F6rlitz -title:Mayor -title;language=de;value=text:Burgermeister -note:The Mayor of the great city of - Goerlitz in the great country of Germany. -email;internet:mb@goerlitz.de -home.tel;type=fax,voice,msg:+49 3581 123456 -home.label:Hufenshlagel 1234\n - 02828 Goerlitz\n - Deutschland -key;type=X509;encoding=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQ - AwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zI - ENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQD - ExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNjE5NDc1OVoXDTk3MTIwMzE5NDc - 1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYDVQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW - 9ucyBDb3JwLjEYMBYGA1UEAxMPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBF - hJob3dlc0BuZXRzY2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqG - SIb3DQEBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2dXc - oX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MBEGCWCGSAGG+E - IBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9 - w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIPmx93HGp0Kgyx1jIVMyNgsemeAwBM+M - SlhMfcpbTrONwNjZYW8vJDSoi//yrZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8V - UMk1U7jt8LYpo4YULU7UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ== -end:vcard - - - - - - - - - -Howes, et. al. Standards Track [Page 20] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - -8.4. Example 4 - - The final example illustrates the use of the multipart/related - Content-Type to include non-textual directory data via the "uri" - encoding to refer to other body parts within the same message, or to - external values. Note that no "profile" parameter is given, so an - application may not know what kind of directory entity the - information applies to. Note also the use of both hypothetical - official and bilaterally agreed upon types. - -Content-Type: multipart/related; - boundary=woof; - type="text/directory"; - start="" -Content-ID: - ---woof -Content-Type: text/directory; charset="iso-8859-1" -Content-ID: -Content-Transfer-Encoding: Quoted-Printable - -source:ldap://cn=Bjorn%20Jensen,o=University%20of%20Michigan,c=US -cn:Bj=F8rn Jensen -sn:Jensen -email:bjorn@umich.edu -image;value=uri:cid:id6@host.com -image;value=uri;format=jpeg:ftp://some.host/some/path.jpg -sound;value=uri:cid:id7@host.com -phone:+1 313 747-4454 - ---woof -Content-Type: image/jpeg -Content-ID: - -<...image data...> - ---woof -Content-Type: message/external-body; - name="myvoice.au"; - site="myhost.com"; - access-type=ANON-FTP; - directory="pub/myname"; - mode="image" - -Content-Type: audio/basic -Content-ID: - ---woof-- - - - -Howes, et. al. Standards Track [Page 21] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - -9. Registration of new profiles - - This section defines procedures by which new profiles are registered - with the IANA and made available to the Internet community. Note that - non-IANA profiles can be used by bilateral agreement, provided the - associated profile names follow the "X-" convention defined above. - - The procedures defined here are designed to allow public comment and - review of new profiles, while posing only a small impediment to the - definition of new profiles. - - Registration of a new profile is accomplished by the following steps. - -9.1. Define the profile - - A profile is defined by completing the following template. - - To: ietf-mime-direct@imc.org - Subject: Registration of text/directory MIME profile XXX - - Profile name: - - Profile purpose: - - Profile types: - - Profile special notes (optional): - - Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) - - The explanation of what goes in each field in the template follows. - - Profile name: The name of the profile as it will appear in the - text/directory MIME Content-Type "profile" header parameter, or the - predefined "profile" type name. - - Profile purpose: The purpose of the profile (e.g., to represent - information about people, printers, documents, etc.). Give a short - but clear description. - - Profile types: The list of types associated with the profile. This - list of types is to be expected but not required in the profile, - unless otherwise noted in the profile definition. Other types not - mentioned in the profile definition MAY also be present. Note that - any new types referenced by the profile MUST be defined separately as - described in Section 10. - - - - - -Howes, et. al. Standards Track [Page 22] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - Profile special notes: Any special notes about the profile, how it is - to be used, etc. This section of the template can also be used to - define an ordering on the types that appear in the Content-Type, if - such an ordering is required. - -9.2. Post the profile definition - - The profile description must be posted to the new profile discussion - list, ietf-mime-direct@imc.org - -9.3. Allow a comment period - - Discussion on the new profile must be allowed to take place on the - list for a minimum of two weeks. Consensus must be reached on the - profile before proceeding to step 4. - -9.4. Submit the profile for approval - - Once the two-week comment period has elapsed, and the proposer is - convinced consensus has been reached on the profile, the registration - application should be submitted to the Profile Reviewer for approval. - The Profile Reviewer is appointed by the Application Area Directors - and can either accept or reject the profile registration. An accepted - registration is passed on by the Profile Reviewer to the IANA for - inclusion in the official IANA profile registry. The registration may - be rejected for any of the following reasons. 1) Insufficient comment - period; 2) Consensus not reached; 3) Technical deficiencies raised on - the list or elsewhere have not been addressed. The Profile Reviewer's - decision to reject a profile can be appealed by the proposer to the - IESG, or the objections raised can be addressed by the proposer and - the profile resubmitted. - -10. Profile Change Control - - Existing profiles can be changed using the same process by which they - were registered. - - Define the change - - Post the change - - Allow a comment period - - Submit the changed profile for approval - - - - - - - -Howes, et. al. Standards Track [Page 23] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - Note that the original author or any other interested party can - propose a change to an existing profile, but that such changes should - only be proposed when there are serious omissions or errors in the - published specification. The Profile Reviewer can object to a change - if it is not backwards compatible, but is not required to do so. - - Profile definitions can never be deleted from the IANA registry, but - profiles which are no longer believed to be useful can be declared - OBSOLETE by a change to their "intended use" field. - -11. Registration of new types - - This section defines procedures by which new types are registered - with the IANA. Note that non-IANA types can be used by bilateral - agreement, provided the associated types names follow the "X-" - convention defined above. - - The procedures defined here are designed to allow public comment and - review of new types, while posing only a small impediment to the - definition of new types. - - Registration of a new type is accomplished by the following steps. - -11.1. Define the type - - A type is defined by completing the following template. - - To: ietf-mime-direct@imc.org - Subject: Registration of text/directory MIME type XXX - - Type name: - - Type purpose: - - Type encoding: - - Type valuetype: - - Type special notes (optional): - - Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) - - The meaning of each field in the template is as follows. - - Type name: The name of the type, as it will appear in the body of an - text/directory MIME Content-Type "type: value" line to the left of - the colon ":". - - - - -Howes, et. al. Standards Track [Page 24] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - Type purpose: The purpose of the type (e.g., to represent a name, - postal address, IP address, etc.). Give a short but clear - description. - - Type encoding: The default encoding a value of the type must have in - the body of a text/directory MIME Content-Type. - - Type valuetype: The format a value of the type must have in the body - of a text/directory MIME Content-Type. This description must be - precise and must not violate the general encoding rules defined in - section 5 of this document. - - Type special notes: Any special notes about the type, how it is to be - used, etc. - -11.2. Post the type definition - - The type description must be posted to the new type discussion list, - ietf-mime-direct@imc.org - -11.3. Allow a comment period - - Discussion on the new type must be allowed to take place on the list - for a minimum of two weeks. Consensus must be reached on the type - before proceeding to step 4. - -11.4. Submit the type for approval - - Once the two-week comment period has elapsed, and the proposer is - convinced consensus has been reached on the type, the registration - application should be submitted to the Profile Reviewer for approval. - The Profile Reviewer is appointed by the Application Area Directors - and can either accept or reject the type registration. An accepted - registration is passed on by the Profile Reviewer to the IANA for - inclusion in the official IANA profile registry. The registration can - be rejected for any of the following reasons. 1) Insufficient comment - period; 2) Consensus not reached; 3) Technical deficiencies raised on - the list or elsewhere have not been addressed. The Profile - Reviewer's decision to reject a type can be appealed by the proposer - to the IESG, or the objections raised can be addressed by the - proposer and the type resubmitted. - - - - - - - - - - -Howes, et. al. Standards Track [Page 25] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - -12. Type Change Control - - Existing types can be changed using the same process by which they - were registered. - - Define the change - - Post the change - - Allow a comment period - - Submit the type for approval - - Note that the original author or any other interested party can - propose a change to an existing type, but that such changes should - only be proposed when there are serious omissions or errors in the - published specification. The Profile Reviewer can object to a change - if it is not backwards compatible, but is not required to do so. - - Type definitions can never be deleted from the IANA registry, but - types which are nolonger believed to be useful can be declared - OBSOLETE by a change to their "intended use" field. - -13. Registration of new parameters - - This section defines procedures by which new parameters are - registered with the IANA and made available to the Internet - community. Note that non-IANA parameters can be used by bilateral - agreement, provided the associated parameters names follow the "X-" - convention defined above. - - The procedures defined here are designed to allow public comment and - review of new parameters, while posing only a small impediment to the - definition of new parameters. - - Registration of a new parameter is accomplished by the following - steps. - -13.1. Define the parameter - - A parameter is defined by completing the following template. - - To: ietf-mime-direct@imc.org - Subject: Registration of text/directory MIME type parameter XXX - - Parameter name: - - Parameter purpose: - - - -Howes, et. al. Standards Track [Page 26] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - Parameter values: - - Parameter special notes (optional): - - Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) - - The explanation of what goes in each field in the template follows. - - Parameter name: The name of the parameter as it will appear in the - text/directory MIME Content-Type. - - Parameter purpose: The purpose of the parameter (e.g., to represent - the format of an image, type of a phone number, etc.). Give a short - but clear description. If defining a general paramemter like "format" - or "type" keep in mind that other applications might wish to extend - its use. - - Parameter values: The list or description of values associated with - the parameter. - - Parameter special notes: Any special notes about the parameter, how - it is to be used, etc. - -13.2. Post the parameter definition - - The parameter description must be posted to the new parameter - discussion list, ietf-mime-direct@imc.org - -13.3. Allow a comment period - - Discussion on the new parameter must be allowed to take place on the - list for a minimum of two weeks. Consensus must be reached on the - parameter before proceeding to step 4. - -13.4. Submit the parameter for approval - - Once the two-week comment period has elapsed, and the proposer is - convinced consensus has been reached on the parameter, the - registration application should be submitted to the Profile Reviewer - for approval. The Profile Reviewer is appointed by the Application - Area Directors and can either accept or reject the parameter - registration. An accepted registration is passed on by the Profile - Reviewer to the IANA for inclusion in the official IANA parameter - registry. The registration can be rejected for any of the following - reasons. 1) Insufficient comment period; 2) Consensus not reached; 3) - Technical deficiencies raised on the list or elsewhere have not been - addressed. The Profile Reviewer's decision to reject a profile can be - appealed by the proposer to the IESG, or the objections raised can be - - - -Howes, et. al. Standards Track [Page 27] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - addressed by the proposer and the parameter registration resubmitted. - -14. Parameter Change Control - - Existing parameters can be changed using the same process by which - they were registered. - - Define the change - - Post the change - - Allow a comment period - - Submit the parameter for approval - - Note that the original author or any other interested party can - propose a change to an existing parameter, but that such changes - should only be proposed when there are serious omissions or errors in - the published specification. The Profile Reviewer can object to a - change if it is not backwards compatible, but is not required to do - so. - - Parameter definitions can never be deleted from the IANA registry, - but parameters which are nolonger believed to be useful can be - declared OBSOLETE by a change to their "intended use" field. - -15. Registration of new value types - - This section defines procedures by which new value types are - registered with the IANA and made available to the Internet - community. Note that non-IANA value types can be used by bilateral - agreement, provided the associated value types names follow the "X-" - convention defined above. - - The procedures defined here are designed to allow public comment and - review of new value types, while posing only a small impediment to - the definition of new value types. - - Registration of a new value types is accomplished by the following - steps. - -15.1. Define the value type - - A value type is defined by completing the following template. - - To: ietf-mime-direct@imc.org - Subject: Registration of text/directory MIME value type XXX - - - - -Howes, et. al. Standards Track [Page 28] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - value type name: - - value type purpose: - - value type format: - - value type special notes (optional): - - Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) - - The explanation of what goes in each field in the template follows. - - value type name: The name of the value type as it will appear in the - text/directory MIME Content-Type. - - value type purpose: The purpose of the value type. Give a short but - clear description. - - value type format: The definition of the format for the value, - usually using ABNF grammar. - - value type special notes: Any special notes about the value type, how - it is to be used, etc. - -15.2. Post the value type definition - - The value type description must be posted to the new value type - discussion list, ietf-mime-direct@imc.org - -15.3. Allow a comment period - - Discussion on the new value type must be allowed to take place on the - list for a minimum of two weeks. Consensus must be reached before - proceeding to step 4. - -15.4. Submit the value type for approval - - Once the two-week comment period has elapsed, and the proposer is - convinced consensus has been reached on the value type, the - registration application should be submitted to the Profile Reviewer - for approval. The Profile Reviewer is appointed by the Application - Area Directors and can either accept or reject the value type - registration. An accepted registration should be passed on by the - Profile Reviewer to the IANA for inclusion in the official IANA value - type registry. The registration can be rejected for any of the - following reasons. 1) Insufficient comment period; 2) Consensus not - reached; 3) Technical deficiencies raised on the list or elsewhere - have not been addressed. The Profile Reviewer's decision to reject a - - - -Howes, et. al. Standards Track [Page 29] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - profile can be appealed by the proposer to the IESG, or the - objections raised can be addressed by the proposer and the value type - registration resubmitted. - -16. Security Considerations - - Internet mail is subject to many well known security attacks, - including monitoring, replay, and forgery. Care should be taken by - any directory service in allowing information to leave the scope of - the service itself, where any access controls can no longer be - guaranteed. Applications should also take care to display directory - data in a "safe" environment (e.g., PostScript-valued types). - -17. Acknowledgements - - The registration procedures defined here were shamelessly lifted from - the MIME registration RFC. - - The many valuable comments contributed by members of the IETF ASID - working group are gratefully acknowledged, as are the contributions - of the Versit Consortium. Chris Newman was especially helpful in - navigating the intricacies of ABNF lore. - -18. References - - [RFC-1777] Yeong, W., Howes, T., and S. Kille, "Lightweight - Directory Access Protocol", RFC 1777, March 1995. - - [RFC-1778] Howes, T., Kille, S., Yeong, W., and C. Robbins, "The - String Representation of Standard Attribute Syntaxes", - RFC 1778, March 1995. - - [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet - Text Messages", STD 11, RFC 822, August 1982. - - [RFC-2045] Borenstein, N., and N. Freed, "Multipurpose Internet - Mail Extensions (MIME) Part One: Format of Internet - Message Bodies", RFC 2045, November 1996. - - [RFC-2046] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996. - - [RFC-2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose - Internet Mail Extensions (MIME) Part Four: Registration - Procedures", RFC 2048, November 1996. - - [RFC-1766] Alvestrand, H., "Tags for the Identification of - Languages", RFC 1766, March 1995. - - - -Howes, et. al. Standards Track [Page 30] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - - [RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type", - RFC 2112, March 1997. - - [X500] "Information Processing Systems - Open Systems - Interconnection - The Directory: Overview of Concepts, - Models and Services", ISO/IEC JTC 1/SC21, International - Standard 9594-1, 1988. - - [RFC-1835] Deutsch, P., Schoultz, R., Faltstrom, P., and C. Weider, - "Architecture of the WHOIS++ service", RFC 1835, August - 1995. - - [RFC-1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform - Resource Locators (URL)", RFC 1738, December 1994. - - [MIME-VCARD] Dawson, F., and T. Howes, "VCard MIME Directory - Profile", RFC 2426, September 1998. - - [VCARD] Internet Mail Consortium, "vCard - The Electronic - Business Card", Version 2.1, - http://www.imc.com/pdi/vcard-21.txt, September, 1996. - - [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC-2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - - - - - - - - - - - - - - - - - - - - - - - -Howes, et. al. Standards Track [Page 31] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - -19. Authors' Addresses - - Tim Howes - Netscape Communications Corp. - 501 East Middlefield Rd. - Mountain View, CA 94041 - USA - - Phone: +1.415.937.3419 - EMail: howes@netscape.com - - - Mark Smith - Netscape Communications Corp. - 501 East Middlefield Rd. - Mountain View, CA 94041 - USA - - Phone: +1.415.937.3477 - EMail: mcs@netscape.com - - - Frank Dawson - Lotus Development Corporation - 6544 Battleford Drive - Raleigh, NC 27613 - USA - - Phone: +1-919-676-9515 - EMail: frank_dawson@lotus.com - - - - - - - - - - - - - - - - - - - - - -Howes, et. al. Standards Track [Page 32] - -RFC 2425 MIME Content-Type for Directory Information September 1998 - - -20. Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Howes, et. al. Standards Track [Page 33] - diff --git a/etc/rfc2426.txt b/etc/rfc2426.txt deleted file mode 100644 index a393a67..0000000 --- a/etc/rfc2426.txt +++ /dev/null @@ -1,2355 +0,0 @@ - - - - - - -Network Working Group F. Dawson -Request for Comments: 2426 Lotus Development Corporation -Category: Standards Track T. Howes - Netscape Communications - September 1998 - - - vCard MIME Directory Profile - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - This memo defines the profile of the MIME Content-Type [MIME-DIR] for - directory information for a white-pages person object, based on a - vCard electronic business card. The profile definition is independent - of any particular directory service or protocol. The profile is - defined for representing and exchanging a variety of information - about an individual (e.g., formatted and structured name and delivery - addresses, email address, multiple telephone numbers, photograph, - logo, audio clips, etc.). The directory information used by this - profile is based on the attributes for the person object defined in - the X.520 and X.521 directory services recommendations. The profile - also provides the method for including a [VCARD] representation of a - white-pages directory entry within the MIME Content-Type defined by - the [MIME-DIR] document. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this - document are to be interpreted as described in [RFC 2119]. - - - - - - - - - - - -Dawson & Howes Standards Track [Page 1] - -RFC 2426 vCard MIME Directory Profile September 1998 - - -Table of Contents - - Overview.........................................................3 - 1. THE VCARD MIME DIRECTORY PROFILE REGISTRATION.................4 - 2. MIME DIRECTORY FEATURES.......................................5 - 2.1 PREDEFINED TYPE USAGE ......................................5 - 2.1.1 BEGIN and END Type ......................................5 - 2.1.2 NAME Type ...............................................5 - 2.1.3 PROFILE Type ............................................5 - 2.1.4 SOURCE Type .............................................5 - 2.2 PREDEFINED TYPE PARAMETER USAGE ............................6 - 2.3 PREDEFINED VALUE TYPE USAGE ................................6 - 2.4 EXTENSIONS TO THE PREDEFINED VALUE TYPES ...................6 - 2.4.1 BINARY ..................................................6 - 2.4.2 VCARD ...................................................6 - 2.4.3 PHONE-NUMBER ............................................7 - 2.4.4 UTC-OFFSET ..............................................7 - 2.5 STRUCTURED TYPE VALUES .....................................7 - 2.6 LINE DELIMITING AND FOLDING ................................8 - 3. VCARD PROFILE FEATURES........................................8 - 3.1 IDENTIFICATION TYPES .......................................8 - 3.1.1 FN Type Definition ......................................8 - 3.1.2 N Type Definition .......................................9 - 3.1.3 NICKNAME Type Definition ................................9 - 3.1.4 PHOTO Type Definition ..................................10 - 3.1.5 BDAY Type Definition ...................................11 - 3.2 DELIVERY ADDRESSING TYPES .................................11 - 3.2.1 ADR Type Definition ....................................11 - 3.2.2 LABEL Type Definition ..................................13 - 3.3 TELECOMMUNICATIONS ADDRESSING TYPES .......................13 - 3.3.1 TEL Type Definition ....................................14 - 3.3.2 EMAIL Type Definition ..................................15 - 3.3.3 MAILER Type Definition .................................15 - 3.4 GEOGRAPHICAL TYPES ........................................16 - 3.4.1 TZ Type Definition .....................................16 - 3.4.2 GEO Type Definition ....................................16 - 3.5 ORGANIZATIONAL TYPES ......................................17 - 3.5.1 TITLE Type Definition ..................................17 - 3.5.2 ROLE Type Definition ...................................18 - 3.5.3 LOGO Type Definition ...................................18 - 3.5.4 AGENT Type Definition ..................................19 - 3.5.5 ORG Type Definition ....................................20 - 3.6 EXPLANATORY TYPES .........................................20 - 3.6.1 CATEGORIES Type Definition .............................20 - 3.6.2 NOTE Type Definition ...................................21 - 3.6.3 PRODID Type Definition .................................21 - 3.6.4 REV Type Definition ....................................22 - 3.6.5 SORT-STRING Type Definition ............................22 - - - -Dawson & Howes Standards Track [Page 2] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - 3.6.6 SOUND Type Definition ..................................23 - 3.6.7 UID Type Definition ....................................24 - 3.6.8 URL Type Definition ....................................25 - 3.6.9 VERSION Type Definition ................................25 - 3.7 SECURITY TYPES ............................................25 - 3.7.1 CLASS Type Definition ..................................26 - 3.7.2 KEY Type Definition ....................................26 - 3.8 EXTENDED TYPES ............................................27 - 4. FORMAL GRAMMAR...............................................27 - 5. DIFFERENCES FROM VCARD V2.1..................................37 - 6. ACKNOWLEDGEMENTS.............................................39 - 7. AUTHORS' ADDRESSES...........................................39 - 8. SECURITY CONSIDERATIONS......................................39 - 9. REFERENCES...................................................40 - 10. FULL COPYRIGHT STATEMENT....................................42 - -Overview - - The [MIME-DIR] document defines a MIME Content-Type for holding - different kinds of directory information. The directory information - can be based on any of a number of directory schemas. This document - defines a [MIME-DIR] usage profile for conveying directory - information based on one such schema; that of the white-pages type of - person object. - - The schema is based on the attributes for the person object defined - in the X.520 and X.521 directory services recommendations. The schema - has augmented the basic attributes defined in the X.500 series - recommendation in order to provide for an electronic representation - of the information commonly found on a paper business card. This - schema was first defined in the [VCARD] document. Hence, this [MIME- - DIR] profile is referred to as the vCard MIME Directory Profile. - - A directory entry based on this usage profile can include traditional - directory, white-pages information such as the distinguished name - used to uniquely identify the entry, a formatted representation of - the name used for user-interface or presentation purposes, both the - structured and presentation form of the delivery address, various - telephone numbers and organizational information associated with the - entry. In addition, traditional paper business card information such - as an image of an organizational logo or identify photograph can be - included in this person object. - - The vCard MIME Directory Profile also provides support for - representing other important information about the person associated - with the directory entry. For instance, the date of birth of the - person; an audio clip describing the pronunciation of the name - associated with the directory entry, or some other application of the - - - -Dawson & Howes Standards Track [Page 3] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - digital sound; longitude and latitude geo-positioning information - related to the person associated with the directory entry; date and - time that the directory information was last updated; annotations - often written on a business card; Uniform Resource Locators (URL) for - a website; public key information. The profile also provides support - for non-standard extensions to the schema. This provides the - flexibility for implementations to augment the current capabilities - of the profile in a standardized way. More information about this - electronic business card format can be found in [VCARD]. - -1. The vCard Mime Directory Profile Registration - - This profile is identified by the following [MIME-DIR] registration - template information. Subsequent sections define the profile - definition. - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME profile VCARD - - Profile name: VCARD - - Profile purpose: To hold person object or white-pages type of - directory information. The person schema captured in the directory - entries is that commonly found in an electronic business card. - - Predefined MIME Directory value specifications used: uri, date, - date-time, float - - New value specifications: This profile places further constraints on - the [MIME-DIR] text value specification. In addition, it adds a - binary, phone-number, utc-offset and vcard value specifications. - - Predefined MIME Directory types used: SOURCE, NAME, PROFILE, BEGIN, - END. - - Predefined MIME Directory parameters used: ENCODING, VALUE, CHARSET, - LANGUAGE, CONTEXT. - - New types: FN, N, NICKNAME, PHOTO, BDAY, ADR, LABEL, TEL, EMAIL, - MAILER, TZ, GEO, TITLE, ROLE, LOGO, AGENT, ORG, CATEGORIES, NOTE, - PRODID, REV, SORT-STRING, SOUND, URL, UID, VERSION, CLASS, KEY - - New parameters: TYPE - - Profile special notes: The vCard object MUST contain the FN, N and - VERSION types. The type-grouping feature of [MIME-DIR] is supported - by this profile to group related vCard properties about a directory - - - -Dawson & Howes Standards Track [Page 4] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - entry. For example, vCard properties describing WORK or HOME related - characteristics can be grouped with a unique group label. - - The profile permits the use of non-standard types (i.e., those - identified with the prefix string "X-") as a flexible method for - implementations to extend the functionality currently defined within - this profile. - -2. MIME Directory Features - - The vCard MIME Directory Profile makes use of many of the features - defined by [MIME-DIR]. The following sections either clarify or - extend the content-type definition of [MIME-DIR]. - -2.1 Predefined Type Usage - - The vCard MIME Directory Profile uses the following predefined types - from [MIME-DIR]. - -2.1.1 BEGIN and END Type - - The content entity MUST begin with the BEGIN type with a value of - "VCARD". The content entity MUST end with the END type with a value - of "VCARD". - -2.1.2 NAME Type - - If the NAME type is present, then its value is the displayable, - presentation text associated with the source for the vCard, as - specified in the SOURCE type. - -2.1.3 PROFILE Type - - If the PROFILE type is present, then its value MUST be "VCARD". - -2.1.4 SOURCE Type - - If the SOURCE type is present, then its value provides information - how to find the source for the vCard. - - - - - - - - - - - - -Dawson & Howes Standards Track [Page 5] - -RFC 2426 vCard MIME Directory Profile September 1998 - - -2.2 Predefined Type Parameter Usage - - The vCard MIME Directory Profile uses the following predefined type - parameters as defined by [MIME-DIR]. - - - LANGUAGE - - - ENCODING - - - VALUE - -2.3 Predefined VALUE Type Usage - - The predefined data type values specified in [MIME-DIR] MUST NOT be - repeated in COMMA separated value lists except within the N, - NICKNAME, ADR and CATEGORIES value types. - - The text value type defined in [MIME-DIR] is further restricted such - that any SEMI-COLON character (ASCII decimal 59) in the value MUST be - escaped with the BACKSLASH character (ASCII decimal 92). - -2.4 Extensions To The Predefined VALUE Types - - The predefined data type values specified in [MIME-DIR] have been - extended by the vCard profile to include a number of value types that - are specific to this profile. - -2.4.1 BINARY - - The "binary" value type specifies that the type value is inline, - encoded binary data. This value type can be specified in the PHOTO, - LOGO, SOUND, and KEY types. - - If inline encoded binary data is specified, the ENCODING type - parameter MUST be used to specify the encoding format. The binary - data MUST be encoded using the "B" encoding format. Long lines of - encoded binary data SHOULD BE folded to 75 characters using the - folding method defined in [MIME-DIR]. - - The value type is defined by the following notation: - - binary = - -2.4.2 VCARD - - The "vcard" value type specifies that the type value is another - vCard. This value type can be specified in the AGENT type. The value - type is defined by this specification. Since each of the type - - - -Dawson & Howes Standards Track [Page 6] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - declarations with in the vcard value type are being specified within - a text value themselves, they MUST be terminated with the backslash - escape sequence "\n" or "\N", instead of the normal newline character - sequence CRLF. In addition, any COMMA character (ASCII decimal 44), - SEMI-COLON character (ASCII decimal 59) and COLON character (ASCII - decimal 58) MUST be escaped with the BACKSLASH character (ASCII - decimal 92). For example, with the AGENT type a value would be - specified as: - - AGENT:BEGIN:VCARD\nFN:Joe Friday\nTEL:+1-919-555-7878\n - TITLE:Area Administrator\, Assistant\n EMAIL\;TYPE=INTERN\n - ET:jfriday@host.com\nEND:VCARD\n - -2.4.3 PHONE-NUMBER - - The "phone-number" value type specifies that the type value is a - telephone number. This value type can be specified in the TEL type. - The value type is a text value that has the special semantics of a - telephone number as defined in [CCITT E.163] and [CCITT X.121]. - -2.4.4 UTC-OFFSET - - The "utc-offset" value type specifies that the type value is a signed - offset from UTC. This value type can be specified in the TZ type. - - The value type is an offset from Coordinated Universal Time (UTC). It - is specified as a positive or negative difference in units of hours - and minutes (e.g., +hh:mm). The time is specified as a 24-hour clock. - Hour values are from 00 to 23, and minute values are from 00 to 59. - Hour and minutes are 2-digits with high order zeroes required to - maintain digit count. The extended format for ISO 8601 UTC offsets - MUST be used. The extended format makes use of a colon character as a - separator of the hour and minute text fields. - - The value is defined by the following notation: - - time-hour = 2DIGIT ;00-23 - time-minute = 2DIGIT ;00-59 - utc-offset = ("+" / "-") time-hour ":" time-minute - -2.5 Structured Type Values - - Compound type values are delimited by a field delimiter, specified by - the SEMI-COLON character (ASCII decimal 59). A SEMI-COLON in a - component of a compound property value MUST be escaped with a - BACKSLASH character (ASCII decimal 92). - - - - - -Dawson & Howes Standards Track [Page 7] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - Lists of values are delimited by a list delimiter, specified by the - COMMA character (ASCII decimal 44). A COMMA character in a value MUST - be escaped with a BACKSLASH character (ASCII decimal 92). - - This profile supports the type grouping mechanism defined in [MIME- - DIR]. Grouping of related types is a useful technique to communicate - common semantics concerning the properties of a vCard. - -2.6 Line Delimiting and Folding - - This profile supports the same line delimiting and folding methods - defined in [MIME-DIR]. Specifically, when parsing a content line, - folded lines must first be unfolded according to the unfolding - procedure described in [MIME-DIR]. After generating a content line, - lines longer than 75 characters SHOULD be folded according to the - folding procedure described in [MIME DIR]. - - Folding is done after any content encoding of a type value. Unfolding - is done before any decoding of a type value in a content line. - -3. vCard Profile Features - - The vCard MIME Directory Profile Type contains directory information, - typically pertaining to a single directory entry. The information is - described using an attribute schema that is tailored for capturing - personal contact information. The vCard can include attributes that - describe identification, delivery addressing, telecommunications - addressing, geographical, organizational, general explanatory and - security and access information about the particular object - associated with the vCard. - -3.1 Identification Types - - These types are used in the vCard profile to capture information - associated with the identification and naming of the person or - resource associated with the vCard. - -3.1.1 FN Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type FN - - Type name:FN - - Type purpose: To specify the formatted text corresponding to the name - of the object the vCard represents. - - - - -Dawson & Howes Standards Track [Page 8] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - Type encoding: 8bit - - Type value: A single text value. - - Type special notes: This type is based on the semantics of the X.520 - Common Name attribute. The property MUST be present in the vCard - object. - - Type example: - - FN:Mr. John Q. Public\, Esq. - -3.1.2 N Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type N - - Type name: N - - Type purpose: To specify the components of the name of the object the - vCard represents. - - Type encoding: 8bit - - Type value: A single structured text value. Each component can have - multiple values. - - Type special note: The structured type value corresponds, in - sequence, to the Family Name, Given Name, Additional Names, Honorific - Prefixes, and Honorific Suffixes. The text components are separated - by the SEMI-COLON character (ASCII decimal 59). Individual text - components can include multiple text values (e.g., multiple - Additional Names) separated by the COMMA character (ASCII decimal - 44). This type is based on the semantics of the X.520 individual name - attributes. The property MUST be present in the vCard object. - - Type example: - - N:Public;John;Quinlan;Mr.;Esq. - - N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P. - -3.1.3 NICKNAME Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type NICKNAME - - - -Dawson & Howes Standards Track [Page 9] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - Type name: NICKNAME - - Type purpose: To specify the text corresponding to the nickname of - the object the vCard represents. - - Type encoding: 8bit - - Type value: One or more text values separated by a COMMA character - (ASCII decimal 44). - - Type special note: The nickname is the descriptive name given instead - of or in addition to the one belonging to a person, place, or thing. - It can also be used to specify a familiar form of a proper name - specified by the FN or N types. - - Type example: - - NICKNAME:Robbie - - NICKNAME:Jim,Jimmie - -3.1.4 PHOTO Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type PHOTO - - Type name: PHOTO - - Type purpose: To specify an image or photograph information that - annotates some aspect of the object the vCard represents. - - Type encoding: The encoding MUST be reset to "b" using the ENCODING - parameter in order to specify inline, encoded binary data. If the - value is referenced by a URI value, then the default encoding of 8bit - is used and no explicit ENCODING parameter is needed. - - Type value: A single value. The default is binary value. It can also - be reset to uri value. The uri value can be used to specify a value - outside of this MIME entity. - - Type special notes: The type can include the type parameter "TYPE" to - specify the graphic image format type. The TYPE parameter values MUST - be one of the IANA registered image formats or a non-standard image - format. - - - - - - -Dawson & Howes Standards Track [Page 10] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - Type example: - - PHOTO;VALUE=uri:http://www.abc.com/pub/photos - /jqpublic.gif - - - PHOTO;ENCODING=b;TYPE=JPEG:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN - AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm - ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 - <...remainder of "B" encoded binary data...> - -3.1.5 BDAY Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type BDAY - - Type name: BDAY - - Type purpose: To specify the birth date of the object the vCard - represents. - - Type encoding: 8bit - - Type value: The default is a single date value. It can also be reset - to a single date-time value. - - Type examples: - - BDAY:1996-04-15 - - BDAY:1953-10-15T23:10:00Z - - BDAY:1987-09-27T08:30:00-06:00 - -3.2 Delivery Addressing Types - - These types are concerned with information related to the delivery - addressing or label for the vCard object. - -3.2.1 ADR Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type ADR - - Type name: ADR - - - - -Dawson & Howes Standards Track [Page 11] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - Type purpose: To specify the components of the delivery address for - the vCard object. - - Type encoding: 8bit - - Type value: A single structured text value, separated by the - SEMI-COLON character (ASCII decimal 59). - - Type special notes: The structured type value consists of a sequence - of address components. The component values MUST be specified in - their corresponding position. The structured type value corresponds, - in sequence, to the post office box; the extended address; the street - address; the locality (e.g., city); the region (e.g., state or - province); the postal code; the country name. When a component value - is missing, the associated component separator MUST still be - specified. - - The text components are separated by the SEMI-COLON character (ASCII - decimal 59). Where it makes semantic sense, individual text - components can include multiple text values (e.g., a "street" - component with multiple lines) separated by the COMMA character - (ASCII decimal 44). - - The type can include the type parameter "TYPE" to specify the - delivery address type. The TYPE parameter values can include "dom" to - indicate a domestic delivery address; "intl" to indicate an - international delivery address; "postal" to indicate a postal - delivery address; "parcel" to indicate a parcel delivery address; - "home" to indicate a delivery address for a residence; "work" to - indicate delivery address for a place of work; and "pref" to indicate - the preferred delivery address when more than one address is - specified. These type parameter values can be specified as a - parameter list (i.e., "TYPE=dom;TYPE=postal") or as a value list - (i.e., "TYPE=dom,postal"). This type is based on semantics of the - X.520 geographical and postal addressing attributes. The default is - "TYPE=intl,postal,parcel,work". The default can be overridden to some - other set of values by specifying one or more alternate values. For - example, the default can be reset to "TYPE=dom,postal,work,home" to - specify a domestic delivery address for postal delivery to a - residence that is also used for work. - - Type example: In this example the post office box and the extended - address are absent. - - ADR;TYPE=dom,home,postal,parcel:;;123 Main - Street;Any Town;CA;91921-1234 - - - - - -Dawson & Howes Standards Track [Page 12] - -RFC 2426 vCard MIME Directory Profile September 1998 - - -3.2.2 LABEL Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type LABEL - - Type name: LABEL - - Type purpose: To specify the formatted text corresponding to delivery - address of the object the vCard represents. - - Type encoding: 8bit - - Type value: A single text value. - - Type special notes: The type value is formatted text that can be used - to present a delivery address label for the vCard object. The type - can include the type parameter "TYPE" to specify delivery label type. - The TYPE parameter values can include "dom" to indicate a domestic - delivery label; "intl" to indicate an international delivery label; - "postal" to indicate a postal delivery label; "parcel" to indicate a - parcel delivery label; "home" to indicate a delivery label for a - residence; "work" to indicate delivery label for a place of work; and - "pref" to indicate the preferred delivery label when more than one - label is specified. These type parameter values can be specified as a - parameter list (i.e., "TYPE=dom;TYPE=postal") or as a value list - (i.e., "TYPE=dom,postal"). This type is based on semantics of the - X.520 geographical and postal addressing attributes. The default is - "TYPE=intl,postal,parcel,work". The default can be overridden to some - other set of values by specifying one or more alternate values. For - example, the default can be reset to "TYPE=intl,post,parcel,home" to - specify an international delivery label for both postal and parcel - delivery to a residential location. - - Type example: A multi-line address label. - - LABEL;TYPE=dom,home,postal,parcel:Mr.John Q. Public\, Esq.\n - Mail Drop: TNE QB\n123 Main Street\nAny Town\, CA 91921-1234 - \nU.S.A. - -3.3 Telecommunications Addressing Types - - These types are concerned with information associated with the - telecommunications addressing of the object the vCard represents. - - - - - - - -Dawson & Howes Standards Track [Page 13] - -RFC 2426 vCard MIME Directory Profile September 1998 - - -3.3.1 TEL Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type TEL - - Type name: TEL - - Type purpose: To specify the telephone number for telephony - communication with the object the vCard represents. - - Type encoding: 8bit - - Type value: A single phone-number value. - - Type special notes: The value of this type is specified in a - canonical form in order to specify an unambiguous representation of - the globally unique telephone endpoint. This type is based on the - X.500 Telephone Number attribute. - - The type can include the type parameter "TYPE" to specify intended - use for the telephone number. The TYPE parameter values can include: - "home" to indicate a telephone number associated with a residence, - "msg" to indicate the telephone number has voice messaging support, - "work" to indicate a telephone number associated with a place of - work, "pref" to indicate a preferred-use telephone number, "voice" to - indicate a voice telephone number, "fax" to indicate a facsimile - telephone number, "cell" to indicate a cellular telephone number, - "video" to indicate a video conferencing telephone number, "pager" to - indicate a paging device telephone number, "bbs" to indicate a - bulletin board system telephone number, "modem" to indicate a MODEM - connected telephone number, "car" to indicate a car-phone telephone - number, "isdn" to indicate an ISDN service telephone number, "pcs" to - indicate a personal communication services telephone number. The - default type is "voice". These type parameter values can be specified - as a parameter list (i.e., "TYPE=work;TYPE=voice") or as a value list - (i.e., "TYPE=work,voice"). The default can be overridden to another - set of values by specifying one or more alternate values. For - example, the default TYPE of "voice" can be reset to a WORK and HOME, - VOICE and FAX telephone number by the value list - "TYPE=work,home,voice,fax". - - Type example: - - TEL;TYPE=work,voice,pref,msg:+1-213-555-1234 - - - - - - -Dawson & Howes Standards Track [Page 14] - -RFC 2426 vCard MIME Directory Profile September 1998 - - -3.3.2 EMAIL Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type EMAIL - - Type name: EMAIL - - Type purpose: To specify the electronic mail address for - communication with the object the vCard represents. - - Type encoding: 8bit - - Type value: A single text value. - - Type special notes: The type can include the type parameter "TYPE" to - specify the format or preference of the electronic mail address. The - TYPE parameter values can include: "internet" to indicate an Internet - addressing type, "x400" to indicate a X.400 addressing type or "pref" - to indicate a preferred-use email address when more than one is - specified. Another IANA registered address type can also be - specified. The default email type is "internet". A non-standard value - can also be specified. - - Type example: - - EMAIL;TYPE=internet:jqpublic@xyz.dom1.com - - EMAIL;TYPE=internet:jdoe@isp.net - - EMAIL;TYPE=internet,pref:jane_doe@abc.com - -3.3.3 MAILER Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type MAILER - - Type name: MAILER - - Type purpose: To specify the type of electronic mail software that is - used by the individual associated with the vCard. - - Type encoding: 8bit - - Type value: A single text value. - - - - - -Dawson & Howes Standards Track [Page 15] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - Type special notes: This information can provide assistance to a - correspondent regarding the type of data representation which can be - used, and how they can be packaged. This property is based on the - private MIME type X-Mailer that is generally implemented by MIME user - agent products. - - Type example: - - MAILER:PigeonMail 2.1 - -3.4 Geographical Types - - These types are concerned with information associated with - geographical positions or regions associated with the object the - vCard represents. - -3.4.1 TZ Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type TZ - - Type name: TZ - - Type purpose: To specify information related to the time zone of the - object the vCard represents. - - Type encoding: 8bit - - Type value: The default is a single utc-offset value. It can also be - reset to a single text value. - - Type special notes: The type value consists of a single value. - - Type examples: - - TZ:-05:00 - - TZ;VALUE=text:-05:00; EST; Raleigh/North America - ;This example has a single value, not a structure text value. - -3.4.2 GEO Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type GEO - - Type name: GEO - - - -Dawson & Howes Standards Track [Page 16] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - Type purpose: To specify information related to the global - positioning of the object the vCard represents. - - Type encoding: 8bit - - Type value: A single structured value consisting of two float values - separated by the SEMI-COLON character (ASCII decimal 59). - - Type special notes: This type specifies information related to the - global position of the object associated with the vCard. The value - specifies latitude and longitude, in that order (i.e., "LAT LON" - ordering). The longitude represents the location east and west of the - prime meridian as a positive or negative real number, respectively. - The latitude represents the location north and south of the equator - as a positive or negative real number, respectively. The longitude - and latitude values MUST be specified as decimal degrees and should - be specified to six decimal places. This will allow for granularity - within a meter of the geographical position. The text components are - separated by the SEMI-COLON character (ASCII decimal 59). The simple - formula for converting degrees-minutes-seconds into decimal degrees - is: - - decimal = degrees + minutes/60 + seconds/3600. - - Type example: - - GEO:37.386013;-122.082932 - -3.5 Organizational Types - - These types are concerned with information associated with - characteristics of the organization or organizational units of the - object the vCard represents. - -3.5.1 TITLE Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type TITLE - - Type name: TITLE - - Type purpose: To specify the job title, functional position or - function of the object the vCard represents. - - Type encoding: 8bit - - Type value: A single text value. - - - -Dawson & Howes Standards Track [Page 17] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - Type special notes: This type is based on the X.520 Title attribute. - - Type example: - - TITLE:Director\, Research and Development - -3.5.2 ROLE Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type ROLE - - Type name: ROLE - - Type purpose: To specify information concerning the role, occupation, - or business category of the object the vCard represents. - - Type encoding: 8bit - - Type value: A single text value. - - Type special notes: This type is based on the X.520 Business Category - explanatory attribute. This property is included as an organizational - type to avoid confusion with the semantics of the TITLE type and - incorrect usage of that type when the semantics of this type is - intended. - - Type example: - - ROLE:Programmer - -3.5.3 LOGO Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type LOGO - - Type name: LOGO - - Type purpose: To specify a graphic image of a logo associated with - the object the vCard represents. - - Type encoding: The encoding MUST be reset to "b" using the ENCODING - parameter in order to specify inline, encoded binary data. If the - value is referenced by a URI value, then the default encoding of 8bit - is used and no explicit ENCODING parameter is needed. - - - - - -Dawson & Howes Standards Track [Page 18] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - Type value: A single value. The default is binary value. It can also - be reset to uri value. The uri value can be used to specify a value - outside of this MIME entity. - - Type special notes: The type can include the type parameter "TYPE" to - specify the graphic image format type. The TYPE parameter values MUST - be one of the IANA registered image formats or a non-standard image - format. - - Type example: - - LOGO;VALUE=uri:http://www.abc.com/pub/logos/abccorp.jpg - - LOGO;ENCODING=b;TYPE=JPEG:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN - AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm - ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 - <...the remainder of "B" encoded binary data...> - -3.5.4 AGENT Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type AGENT - - Type name: AGENT - - Type purpose: To specify information about another person who will - act on behalf of the individual or resource associated with the - vCard. - - Type encoding: 8-bit - - Type value: The default is a single vcard value. It can also be reset - to either a single text or uri value. The text value can be used to - specify textual information. The uri value can be used to specify - information outside of this MIME entity. - - Type special notes: This type typically is used to specify an area - administrator, assistant, or secretary for the individual associated - with the vCard. A key characteristic of the Agent type is that it - represents somebody or something that is separately addressable. - - Type example: - - AGENT;VALUE=uri: - CID:JQPUBLIC.part3.960129T083020.xyzMail@host3.com - - - - - -Dawson & Howes Standards Track [Page 19] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - AGENT:BEGIN:VCARD\nFN:Susan Thomas\nTEL:+1-919-555- - 1234\nEMAIL\;INTERNET:sthomas@host.com\nEND:VCARD\n - -3.5.5 ORG Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type ORG - - Type name: ORG - - Type purpose: To specify the organizational name and units associated - with the vCard. - - Type encoding: 8bit - - Type value: A single structured text value consisting of components - separated the SEMI-COLON character (ASCII decimal 59). - - Type special notes: The type is based on the X.520 Organization Name - and Organization Unit attributes. The type value is a structured type - consisting of the organization name, followed by one or more levels - of organizational unit names. - - Type example: A type value consisting of an organizational name, - organizational unit #1 name and organizational unit #2 name. - - ORG:ABC\, Inc.;North American Division;Marketing - -3.6 Explanatory Types - - These types are concerned with additional explanations, such as that - related to informational notes or revisions specific to the vCard. - -3.6.1 CATEGORIES Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type CATEGORIES - - Type name: CATEGORIES - - Type purpose: To specify application category information about the - vCard. - - Type encoding: 8bit - - - - - -Dawson & Howes Standards Track [Page 20] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - Type value: One or more text values separated by a COMMA character - (ASCII decimal 44). - - Type example: - - CATEGORIES:TRAVEL AGENT - - CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY - -3.6.2 NOTE Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type NOTE - - Type name: NOTE - - Type purpose: To specify supplemental information or a comment that - is associated with the vCard. - - Type encoding: 8bit - - Type value: A single text value. - - Type special notes: The type is based on the X.520 Description - attribute. - - Type example: - - NOTE:This fax number is operational 0800 to 1715 - EST\, Mon-Fri. - -3.6.3 PRODID Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type PRODID - - Type name: PRODID - - Type purpose: To specify the identifier for the product that created - the vCard object. - - Type encoding: 8-bit - - Type value: A single text value. - - - - - -Dawson & Howes Standards Track [Page 21] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - Type special notes: Implementations SHOULD use a method such as that - specified for Formal Public Identifiers in ISO 9070 to assure that - the text value is unique. - - Type example: - - PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN - -3.6.4 REV Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type REV - - Type name: REV - - Type purpose: To specify revision information about the current - vCard. - - Type encoding: 8-bit - - Type value: The default is a single date-time value. Can also be - reset to a single date value. - - Type special notes: The value distinguishes the current revision of - the information in this vCard for other renditions of the - information. - - Type example: - - REV:1995-10-31T22:27:10Z - - REV:1997-11-15 - -3.6.5 SORT-STRING Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type SORT-STRING - - Type Name: SORT-STRING - - Type purpose: To specify the family name or given name text to be - used for national-language-specific sorting of the FN and N types. - - Type encoding: 8bit - - Type value: A single text value. - - - -Dawson & Howes Standards Track [Page 22] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - Type special notes: The sort string is used to provide family name or - given name text that is to be used in locale- or national-language- - specific sorting of the formatted name and structured name types. - Without this information, sorting algorithms could incorrectly sort - this vCard within a sequence of sorted vCards. When this type is - present in a vCard, then this family name or given name value is used - for sorting the vCard. - - Type examples: For the case of family name sorting, the following - examples define common sort string usage with the FN and N types. - - FN:Rene van der Harten - N:van der Harten;Rene;J.;Sir;R.D.O.N. - SORT-STRING:Harten - - FN:Robert Pau Shou Chang - N:Pau;Shou Chang;Robert - SORT-STRING:Pau - - FN:Osamu Koura - N:Koura;Osamu - SORT-STRING:Koura - - FN:Oscar del Pozo - N:del Pozo Triscon;Oscar - SORT-STRING:Pozo - - FN:Chistine d'Aboville - N:d'Aboville;Christine - SORT-STRING:Aboville - -3.6.6 SOUND Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type SOUND - - Type name: SOUND - - Type purpose: To specify a digital sound content information that - annotates some aspect of the vCard. By default this type is used to - specify the proper pronunciation of the name type value of the vCard. - - Type encoding: The encoding MUST be reset to "b" using the ENCODING - parameter in order to specify inline, encoded binary data. If the - value is referenced by a URI value, then the default encoding of 8bit - is used and no explicit ENCODING parameter is needed. - - - - -Dawson & Howes Standards Track [Page 23] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - Type value: A single value. The default is binary value. It can also - be reset to uri value. The uri value can be used to specify a value - outside of this MIME entity. - - Type special notes: The type can include the type parameter "TYPE" to - specify the audio format type. The TYPE parameter values MUST be one - of the IANA registered audio formats or a non-standard audio format. - - Type example: - - SOUND;TYPE=BASIC;VALUE=uri:CID:JOHNQPUBLIC.part8. - 19960229T080000.xyzMail@host1.com - - SOUND;TYPE=BASIC;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN - AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm - ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 - <...the remainder of "B" encoded binary data...> - -3.6.7 UID Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type UID - - Type name: UID - - Type purpose: To specify a value that represents a globally unique - identifier corresponding to the individual or resource associated - with the vCard. - - Type encoding: 8bit - - Type value: A single text value. - - Type special notes: The type is used to uniquely identify the object - that the vCard represents. - - The type can include the type parameter "TYPE" to specify the format - of the identifier. The TYPE parameter value should be an IANA - registered identifier format. The value can also be a non-standard - format. - - Type example: - - UID:19950401-080045-40000F192713-0052 - - - - - - -Dawson & Howes Standards Track [Page 24] - -RFC 2426 vCard MIME Directory Profile September 1998 - - -3.6.8 URL Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type URL - - Type name: URL - - Type purpose: To specify a uniform resource locator associated with - the object that the vCard refers to. - - Type encoding: 8bit - - Type value: A single uri value. - - Type example: - - URL:http://www.swbyps.restaurant.french/~chezchic.html - -3.6.9 VERSION Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type VERSION - - Type name: VERSION - - Type purpose: To specify the version of the vCard specification used - to format this vCard. - - Type encoding: 8bit - - Type value: A single text value. - - Type special notes: The property MUST be present in the vCard object. - The value MUST be "3.0" if the vCard corresponds to this - specification. - - Type example: - - VERSION:3.0 - -3.7 Security Types - - These types are concerned with the security of communication pathways - or access to the vCard. - - - - - -Dawson & Howes Standards Track [Page 25] - -RFC 2426 vCard MIME Directory Profile September 1998 - - -3.7.1 CLASS Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type CLASS - - Type name: CLASS - - Type purpose: To specify the access classification for a vCard - object. - - Type encoding: 8bit - - Type value: A single text value. - - Type special notes: An access classification is only one component of - the general security model for a directory service. The - classification attribute provides a method of capturing the intent of - the owner for general access to information described by the vCard - object. - - Type examples: - - CLASS:PUBLIC - - CLASS:PRIVATE - - CLASS:CONFIDENTIAL - -3.7.2 KEY Type Definition - - To: ietf-mime-directory@imc.org - - Subject: Registration of text/directory MIME type KEY - - Type name: KEY - - Type purpose: To specify a public key or authentication certificate - associated with the object that the vCard represents. - - Type encoding: The encoding MUST be reset to "b" using the ENCODING - parameter in order to specify inline, encoded binary data. If the - value is a text value, then the default encoding of 8bit is used and - no explicit ENCODING parameter is needed. - - Type value: A single value. The default is binary. It can also be - reset to text value. The text value can be used to specify a text - key. - - - -Dawson & Howes Standards Track [Page 26] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - Type special notes: The type can also include the type parameter TYPE - to specify the public key or authentication certificate format. The - parameter type should specify an IANA registered public key or - authentication certificate format. The parameter type can also - specify a non-standard format. - - Type example: - - KEY;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQA - wdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENbW11bmljYX - Rpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 - ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNj - E5NDc1OVoXDTk3MTIwMzE5NDc1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYD - VQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3JwLjEYMBYGA1UEAx - MPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBFhJob3dlc0BuZXRz - Y2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqGSIb3DQ - EBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2 - dXcoX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MB - EGCWCGSAGG+EIBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau - +hUMbsQukjANBgkqhkiG9w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIP - mx93HGp0Kgyx1jIVMyNgsemeAwBM+MSlhMfcpbTrONwNjZYW8vJDSoi//y - rZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8VUMk1U7jt8LYpo4YULU7 - UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ== - -3.8 Extended Types - - The types defined by this document can be extended with private types - using the non-standard, private values mechanism defined in [RFC - 2045]. Non-standard, private types with a name starting with "X-" may - be defined bilaterally between two cooperating agents without outside - registration or standardization. - -4. Formal Grammar - - The following formal grammar is provided to assist developers in - building parsers for the vCard. - - This syntax is written according to the form described in RFC 2234, - but it references just this small subset of RFC 2234 literals: - - ;******************************************* - ; Commonly Used Literal Definition - ;******************************************* - - ALPHA = %x41-5A / %x61-7A - ; Latin Capital Letter A-Latin Capital Letter Z / - ; Latin Small Letter a-Latin Small Letter z - - - - -Dawson & Howes Standards Track [Page 27] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - CHAR = %x01-7F - ; Any C0 Controls and Basic Latin, excluding NULL from - ; Code Charts, pages 7-6 through 7-9 in [UNICODE] - - CR = %x0D - ; Carriage Return - - LF = %0A - ; Line Feed - - CRLF = CR LF - ; Internet standard newline - - ;CTL = %x00-1F / %x7F - ; Controls. Not used, but referenced in comments. - - DIGIT = %x30-39 - ; Digit Zero-Digit Nine - - DQUOTE = %x22 - ; Quotation Mark - - HTAB = %x09 - ; Horizontal Tabulation - - SP = %x20 - ; space - - VCHAR = %x21-7E - ; Visible (printing) characters - - WSP = SP / HTAB - ; White Space - - ;******************************************* - ; Basic vCard Definition - ;******************************************* - - vcard_entity = 1*(vcard) - - vcard = [group "."] "BEGIN" ":" "VCARD" 1*CRLF - 1*(contentline) - ;A vCard object MUST include the VERSION, FN and N types. - [group "."] "END" ":" "VCARD" 1*CRLF - - contentline = [group "."] name *(";" param ) ":" value CRLF - ; When parsing a content line, folded lines must first - ; be unfolded according to the unfolding procedure - - - -Dawson & Howes Standards Track [Page 28] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - ; described above. When generating a content line, lines - ; longer than 75 characters SHOULD be folded according to - ; the folding procedure described in [MIME DIR]. - - group = 1*(ALPHA / DIGIT / "-") - - name = iana-token / x-name - ; Parsing of the param and value is - ; based on the "name" or type identifier - ; as defined in ABNF sections below - - iana-token = 1*(ALPHA / DIGIT / "-") - ; vCard type or parameter identifier registered with IANA - - x-name = "X-" 1*(ALPHA / DIGIT / "-") - ; Reserved for non-standard use - - param = param-name "=" param-value *("," param-value) - - param-name = iana-token / x-name - - param-value = ptext / quoted-string - - ptext = *SAFE-CHAR - - value = *VALUE-CHAR - - quoted-string = DQUOTE QSAFE-CHAR DQUOTE - - NON-ASCII = %x80-FF - ; Use is restricted by CHARSET parameter - ; on outer MIME object (UTF-8 preferred) - - QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-ASCII - ; Any character except CTLs, DQUOTE - - SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII - ; Any character except CTLs, DQUOTE, ";", ":", "," - - VALUE-CHAR = WSP / VCHAR / NON-ASCII - ; Any textual character - - ;******************************************* - ; vCard Type Definition - ; - ; Provides type-specific definitions for how the - ; "value" and "param" are defined. - ;******************************************* - - - -Dawson & Howes Standards Track [Page 29] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - ;For name="NAME" - param = "" - ; No parameters allowed - - value = text-value - - ;For name="PROFILE" - param = "" - ; No parameters allowed - - value = text-value - ; Value MUST be the case insensitive value "VCARD - - ;For name="SOURCE" - param = source-param - ; No parameters allowed - - value = uri - - source-param = ("VALUE" "=" "uri") - / ("CONTEXT" "=" "word") - ; Parameter value specifies the protocol context - ; for the uri value. - / (x-name "=" *SAFE-CHAR) - - ;For name="FN" - ;This type MUST be included in a vCard object. - param = text-param - ; Text parameters allowed - - value = text-value - - ;For name="N" - ;This type MUST be included in a vCard object. - - param = text-param - ; Text parameters allowed - - value = n-value - - n-value = 0*4(text-value *("," text-value) ";") - text-value *("," text-value) - ; Family; Given; Middle; Prefix; Suffix. - ; Example: Public;John;Quincy,Adams;Reverend Dr. III - - ;For name="NICKNAME" - param = text-param - ; Text parameters allowed - - - -Dawson & Howes Standards Track [Page 30] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - value = text-list - - ;For name="PHOTO" - param = img-inline-param - ; Only image parameters allowed - - param =/ img-refer-param - ; Only image parameters allowed - - value = img-inline-value - ; Value and parameter MUST match - - value =/ img-refer-value - ; Value and parameter MUST match - - ;For name="BDAY" - param = ("VALUE" "=" "date") - ; Only value parameter allowed - - param =/ ("VALUE" "=" "date-time") - ; Only value parameter allowed - - value = date-value - ; Value MUST match value type - - value =/ date-time-value - ; Value MUST match value type - - ;For name="ADR" - param = adr-param / text-param - ; Only adr and text parameters allowed - - value = adr-value - - ;For name="LABEL" - param = adr-param / text-param - ; Only adr and text parameters allowed - - value = text-value - - ;For name="TEL" - param = tel-param - ; Only tel parameters allowed - - value = phone-number-value - - tel-param = "TYPE" "=" tel-type *("," tel-type) - - - - -Dawson & Howes Standards Track [Page 31] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - tel-type = "HOME" / "WORK" / "PREF" / "VOICE" / "FAX" / "MSG" - / "CELL" / "PAGER" / "BBS" / "MODEM" / "CAR" / "ISDN" - / "VIDEO" / "PCS" / iana-token / x-name - ; Values are case insensitive - - ;For name="EMAIL" - param = email-param - ; Only email parameters allowed - - value = text-value - - email-param = "TYPE" "=" email-type ["," "PREF"] - ; Value is case insensitive - - email-type = "INTERNET" / "X400" / iana-token / "X-" word - ; Values are case insensitive - - ;For name="MAILER" - param = text-param - ; Only text parameters allowed - - value = text-value - - ;For name="TZ" - param = "" - ; No parameters allowed - - value = utc-offset-value - - ;For name="GEO" - param = "" - ; No parameters allowed - - value = float-value ";" float-value - - ;For name="TITLE" - param = text-param - ; Only text parameters allowed - - value = text-value - - ;For name="ROLE" - param = text-param - ; Only text parameters allowed - - value = text-value - - ;For name="LOGO" - - - -Dawson & Howes Standards Track [Page 32] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - param = img-inline-param / img-refer-param - ; Only image parameters allowed - - value = img-inline-value / img-refer-value - ; Value and parameter MUST match - - ;For name="AGENT" - param = agent-inline-param - - param =/ agent-refer-param - - value = agent-inline-value - ; Value and parameter MUST match - - value =/ agent-refer-value - ; Value and parameter MUST match - - agent-inline-param = "" - ; No parameters allowed - - agent-refer-param = "VALUE" "=" "uri" - ; Only value parameter allowed - - agent-inline-value = text-value - ; Value MUST be a valid vCard object - - agent-refer-value = uri - ; URI MUST refer to image content of given type - - ;For name="ORG" - - param = text-param - ; Only text parameters allowed - - value = org-value - - org-value = *(text-value ";") text-value - ; First is Organization Name, remainder are Organization Units. - - ;For name="CATEGORIES" - param = text-param - ; Only text parameters allowed - - value = text-list - - ;For name="NOTE" - param = text-param - ; Only text parameters allowed - - - -Dawson & Howes Standards Track [Page 33] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - value = text-value - - ;For name="PRODID" - param = "" - ; No parameters allowed - - value = text-value - - ;For name="REV" - param = ["VALUE" =" "date-time"] - ; Only value parameters allowed. Values are case insensitive. - - param =/ "VALUE" =" "date" - ; Only value parameters allowed. Values are case insensitive. - - value = date-time-value - - value =/ date-value - - ;For name="SORT-STRING" - param = text-param - ; Only text parameters allowed - - value = text-value - - ;For name="SOUND" - param = snd-inline-param - ; Only sound parameters allowed - - param =/ snd-refer-param - ; Only sound parameters allowed - - value = snd-line-value - ; Value MUST match value type - - value =/ snd-refer-value - ; Value MUST match value type - - snd-inline-value = binary-value CRLF - ; Value MUST be "b" encoded audio content - - snd-inline-param = ("VALUE" "=" "binary"]) - / ("ENCODING" "=" "b") - / ("TYPE" "=" *SAFE-CHAR) - ; Value MUST be an IANA registered audio type - - snd-refer-value = uri - ; URI MUST refer to audio content of given type - - - -Dawson & Howes Standards Track [Page 34] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - snd-refer-param = ("VALUE" "=" "uri") - / ("TYPE" "=" word) - ; Value MUST be an IANA registered audio type - - ;For name="UID" - param = "" - ; No parameters allowed - - value = text-value - - ;For name="URL" - param = "" - ; No parameters allowed - - value = uri - - ;For name="VERSION" - ;This type MUST be included in a vCard object. - param = "" - ; No parameters allowed - - value = text-value - ; Value MUST be "3.0" - - ;For name="CLASS" - param = "" - ; No parameters allowed - - value = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" - / iana-token / x-name - ; Value are case insensitive - - ;For name="KEY" - param = key-txt-param - ; Only value and type parameters allowed - - param =/ key-bin-param - ; Only value and type parameters allowed - - value = text-value - - value =/ binary-value - - key-txt-param = "TYPE" "=" keytype - - key-bin-param = ("TYPE" "=" keytype) - / ("ENCODING" "=" "b") - ; Value MUST be a "b" encoded key or certificate - - - -Dawson & Howes Standards Track [Page 35] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - keytype = "X509" / "PGP" / iana-token / x-name - ; Values are case insensitive - - ;For name="X-" non-standard type - param = text-param / (x-name "=" param-value) - ; Only text or non-standard parameters allowed - - value = text-value - - ;******************************************* - ; vCard Commonly Used Parameter Definition - ;******************************************* - - text-param = ("VALUE" "=" "ptext") - / ("LANGUAGE" "=" langval) - / (x-name "=" param-value) - - langval = - - img-inline-value = binary-value - ;Value MUST be "b" encoded image content - - img-inline-param - - img-inline-param = ("VALUE" "=" "binary") - / ("ENCODING" "=" "b") - / ("TYPE" "=" param-value - ;TYPE value MUST be an IANA registered image type - - img-refer-value = uri - ;URI MUST refer to image content of given type - - img-refer-param = ("VALUE" "=" "uri") - / ("TYPE" "=" param-value) - ;TYPE value MUST be an IANA registered image type - - adr-param = ("TYPE" "=" adr-type *("," adr-type)) - / (text-param) - - adr-type = "dom" / "intl" / "postal" / "parcel" / "home" - / "work" / "pref" / iana-type / x-name - - adr-value = 0*6(text-value ";") text-value - ; PO Box, Extended Address, Street, Locality, Region, Postal - ; Code, Country Name - - - - - - -Dawson & Howes Standards Track [Page 36] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - ;******************************************* - ; vCard Type Value Definition - ;******************************************* - - text-value-list = 1*text-value *("," 1*text-value) - - text-value = *(SAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) - - ESCAPED-CHAR = "\\" / "\;" / "\," / "\n" / "\N") - ; \\ encodes \, \n or \N encodes newline - ; \; encodes ;, \, encodes , - - binary-value = - - date-value = - - time-value = - - date-time-value = - - phone-number-value = - - uri-value = - - utc-offset-value = ("+" / "-") time-hour ":" time-minute - time-hour = 2DIGIT ;00-23 - time-minute = 2DIGIT ;00-59 - -5. Differences From vCard v2.1 - - This specification has been reviewed by the IETF community. The - review process introduced a number of differences from the [VCARD] - version 2.1. These differences require that vCard objects conforming - to this specification have a different version number than a vCard - conforming to [VCARD]. The differences include the following: - - . The QUOTED-PRINTABLE inline encoding has been eliminated. - Only the "B" encoding of [RFC 2047] is an allowed value for - the ENCODING parameter. - - . The method for specifying CRLF character sequences in text - type values has been changed. The CRLF character sequence in - a text type value is specified with the backslash character - sequence "\n" or "\N". - - - - -Dawson & Howes Standards Track [Page 37] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - . Any COMMA or SEMICOLON in a text type value must be backslash - escaped. - - . VERSION value corresponding to this specification MUST be - "3.0". - - . The [MIME-DIR] predefined types of SOURCE, NAME and PROFILE - are allowed. - - . The [MIME-DIR] VALUE type parameter for value data typing is - allowed. In addition, there are extensions made to these type - values for additional value types used in this specification. - - . The [VCARD] CHARSET type parameter has been eliminated. - Character set can only be specified on the CHARSET parameter - on the Content-Type MIME header field. - - . The [VCARD] support for non-significant WSP character has - been eliminated. - - . The "TYPE=" prefix to parameter values is required. In - [VCARD] this was optional. - - . LOGO, PHOTO and SOUND multimedia formats MUST be either IANA - registered types or non-standard types. - - . Inline binary content must be "B" encoded and folded. A blank - line after the encoded binary content is no longer required. - - . TEL values can be identified as personal communication - services telephone numbers with the PCS type parameter value. - - . The CATEGORIES, CLASS, NICKNAME, PRODID and SORT-STRING types - have been added. - - . The VERSION, N and FN types MUST be specified in a vCard. - This identifies the version of the specification that the - object was formatted to. It also assures that every vCard - will include both a structured and formatted name that can be - used to identify the object. - - - - - - - - - - - -Dawson & Howes Standards Track [Page 38] - -RFC 2426 vCard MIME Directory Profile September 1998 - - -6. Acknowledgements - - The many valuable comments contributed by members of the IETF ASID - working group are gratefully acknowledged, as are the contributions - by Roland Alden, Stephen Bartlett, Alec Dun, Patrik Faltstrom, Daniel - Gurney, Bruce Johnston, Daniel Klaussen, Pete Miller, Keith Moore, - Vinod Seraphin, Michelle Watkins. Chris Newman was especially helpful - in navigating the intricacies of ABNF lore. - -7. Authors' Addresses - - BEGIN:vCard - VERSION:3.0 - FN:Frank Dawson - ORG:Lotus Development Corporation - ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive - ;Raleigh;NC;27613-3502;U.S.A. - TEL;TYPE=VOICE,MSG,WORK:+1-919-676-9515 - TEL;TYPE=FAX,WORK:+1-919-676-9564 - EMAIL;TYPE=INTERNET,PREF:Frank_Dawson@Lotus.com - EMAIL;TYPE=INTERNET:fdawson@earthlink.net - URL:http://home.earthlink.net/~fdawson - END:vCard - - - BEGIN:vCard - VERSION:3.0 - FN:Tim Howes - ORG:Netscape Communications Corp. - ADR;TYPE=WORK:;;501 E. Middlefield Rd.;Mountain View; - CA; 94043;U.S.A. - TEL;TYPE=VOICE,MSG,WORK:+1-415-937-3419 - TEL;TYPE=FAX,WORK:+1-415-528-4164 - EMAIL;TYPE=INTERNET:howes@netscape.com - END:vCard - -8. Security Considerations - - vCards can carry cryptographic keys or certificates, as described in - Section 3.7.2. - - Section 3.7.1 specifies a desired security classification policy for - a particular vCard. That policy is not enforced in any way. - - The vCard objects have no inherent authentication or privacy, but can - easily be carried by any security mechanism that transfers MIME - objects with authentication or privacy. In cases where threats of - "spoofed" vCard information is a concern, the vCard SHOULD BE - - - -Dawson & Howes Standards Track [Page 39] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - transported using one of these secure mechanisms. - - The information in a vCard may become out of date. In cases where the - vitality of data is important to an originator of a vCard, the "URL" - type described in section 3.6.8 SHOULD BE specified. In addition, the - "REV" type described in section 3.6.4 can be specified to indicate - the last time that the vCard data was updated. - -9. References - - [ISO 8601] ISO 8601:1988 - Data elements and interchange formats - - Information interchange - Representation of dates and - times - The International Organization for - Standardization, June, 1988. - - [ISO 8601 TC] ISO 8601, Technical Corrigendum 1 - Data elements and - interchange formats - Information interchange - - Representation of dates and times - The International - Organization for Standardization, May, 1991. - - [ISO 9070] ISO 9070, Information Processing - SGML support - facilities - Registration Procedures for Public Text - Owner Identifiers, April, 1991. - - [CCITT E.163] Recommendation E.163 - Numbering Plan for The - International Telephone Service, CCITT Blue Book, - Fascicle II.2, pp. 128-134, November, 1988. - - [CCITT X.121] Recommendation X.121 - International Numbering Plan for - Public Data Networks, CCITT Blue Book, Fascicle VIII.3, - pp. 317-332, November, 1988. - - [CCITT X.520] Recommendation X.520 - The Directory - Selected - Attribute Types, November 1988. - - [CCITT X.521] Recommendation X.521 - The Directory - Selected Object - Classes, November 1988. - - [MIME-DIR] Howes, T., Smith, M., and F. Dawson, "A MIME Content- - Type for Directory Information", RFC 2425, September - 1998. - - [RFC 1738] Berners-Lee, T., Masinter, L., and M. McCahill, - "Uniform Resource Locators (URL)", RFC 1738, December - 1994. - - [RFC 1766] Alvestrand, H., "Tags for the Identification of - Languages", RFC 1766, March 1995. - - - -Dawson & Howes Standards Track [Page 40] - -RFC 2426 vCard MIME Directory Profile September 1998 - - - [RFC 1872] Levinson, E., "The MIME Multipart/Related Content- - type", RFC 1872, December 1995. - - [RFC 2045] Freed, N., and N. Borenstein, "Multipurpose Internet - Mail Extensions (MIME) - Part One: Format of Internet - Message Bodies", RFC 2045, November 1996. - - [RFC 2046] Freed, N., and N. Borenstein, "Multipurpose Internet - Mail Extensions (MIME) - Part Two: Media Types", RFC - 2046, November 1996. - - [RFC 2047] Moore, K., "Multipurpose Internet Mail Extensions - (MIME) - Part Three: Message Header Extensions for - Non-ASCII Text", RFC 2047, November 1996. - - [RFC 2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose - Internet Mail Extensions (MIME) - Part Four: - Registration Procedures", RFC 2048, January 1997. - - [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC 2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [UNICODE] "The Unicode Standard - Version 2.0", The Unicode - Consortium, July 1996. - - [VCARD] Internet Mail Consortium, "vCard - The Electronic - Business Card Version 2.1", - http://www.imc.org/pdi/vcard-21.txt, September 18, - 1996. - - - - - - - - - - - - - - - - - - - -Dawson & Howes Standards Track [Page 41] - -RFC 2426 vCard MIME Directory Profile September 1998 - - -10. Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Dawson & Howes Standards Track [Page 42] - diff --git a/etc/rfc2445.pdf b/etc/rfc2445.pdf deleted file mode 100644 index ede6cb5..0000000 Binary files a/etc/rfc2445.pdf and /dev/null differ diff --git a/etc/rfc2445.txt b/etc/rfc2445.txt deleted file mode 100644 index 70a3bcd..0000000 --- a/etc/rfc2445.txt +++ /dev/null @@ -1,8291 +0,0 @@ - - - - - - -Network Working Group F. Dawson -Request for Comments: 2445 Lotus -Category: Standards Track D. Stenerson - Microsoft - November 1998 - - - Internet Calendaring and Scheduling Core Object Specification - (iCalendar) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - There is a clear need to provide and deploy interoperable calendaring - and scheduling services for the Internet. Current group scheduling - and Personal Information Management (PIM) products are being extended - for use across the Internet, today, in proprietary ways. This memo - has been defined to provide the definition of a common format for - openly exchanging calendaring and scheduling information across the - Internet. - - This memo is formatted as a registration for a MIME media type per - [RFC 2048]. However, the format in this memo is equally applicable - for use outside of a MIME message content type. - - The proposed media type value is 'text/calendar'. This string would - label a media type containing calendaring and scheduling information - encoded as text characters formatted in a manner outlined below. - - This MIME media type provides a standard content type for capturing - calendar event, to-do and journal entry information. It also can be - used to convey free/busy time information. The content type is - suitable as a MIME message entity that can be transferred over MIME - based email systems, using HTTP or some other Internet transport. In - - - - - - -Dawson & Stenerson Standards Track [Page 1] - -RFC 2445 iCalendar November 1998 - - - addition, the content type is useful as an object for interactions - between desktop applications using the operating system clipboard, - drag/drop or file systems capabilities. - - This memo is based on the earlier work of the vCalendar specification - for the exchange of personal calendaring and scheduling information. - In order to avoid confusion with this referenced work, this memo is - to be known as the iCalendar specification. - - This memo defines the format for specifying iCalendar object methods. - An iCalendar object method is a set of usage constraints for the - iCalendar object. For example, these methods might define scheduling - messages that request an event be scheduled, reply to an event - request, send a cancellation notice for an event, modify or replace - the definition of an event, provide a counter proposal for an - original event request, delegate an event request to another - individual, request free or busy time, reply to a free or busy time - request, or provide similar scheduling messages for a to-do or - journal entry calendar component. The iCalendar Transport-indendent - Interoperability Protocol (iTIP) defined in [ITIP] is one such - scheduling protocol. - -Table of Contents - - 1 Introduction.....................................................5 - 2 Basic Grammar and Conventions....................................6 - 2.1 Formatting Conventions .......................................7 - 2.2 Related Memos ................................................8 - 2.3 International Considerations .................................8 - 3 Registration Information.........................................8 - 3.1 Content Type .................................................8 - 3.2 Parameters ...................................................9 - 3.3 Content Header Fields .......................................10 - 3.4 Encoding Considerations .....................................10 - 3.5 Security Considerations .....................................10 - 3.6 Interoperability Considerations .............................11 - 3.7 Applications Which Use This Media Type ......................11 - 3.8 Additional Information ......................................11 - 3.9 Magic Numbers ...............................................11 - 3.10 File Extensions ............................................11 - 3.11 Contact for Further Information: ...........................12 - 3.12 Intended Usage .............................................12 - 3.13 Authors/Change Controllers .................................12 - 4 iCalendar Object Specification..................................13 - 4.1 Content Lines ...............................................13 - 4.1.1 List and Field Separators ................................16 - 4.1.2 Multiple Values ..........................................16 - 4.1.3 Binary Content ...........................................16 - - - -Dawson & Stenerson Standards Track [Page 2] - -RFC 2445 iCalendar November 1998 - - - 4.1.4 Character Set ............................................17 - 4.2 Property Parameters .........................................17 - 4.2.1 Alternate Text Representation ............................18 - 4.2.2 Common Name ..............................................19 - 4.2.3 Calendar User Type .......................................20 - 4.2.4 Delegators ...............................................20 - 4.2.5 Delegatees ...............................................21 - 4.2.6 Directory Entry Reference ................................21 - 4.2.7 Inline Encoding ..........................................22 - 4.2.8 Format Type ..............................................23 - 4.2.9 Free/Busy Time Type ......................................23 - 4.2.10 Language ................................................24 - 4.2.11 Group or List Membership ................................25 - 4.2.12 Participation Status ....................................25 - 4.2.13 Recurrence Identifier Range .............................27 - 4.2.14 Alarm Trigger Relationship ..............................27 - 4.2.15 Relationship Type .......................................28 - 4.2.16 Participation Role ......................................29 - 4.2.17 RSVP Expectation ........................................29 - 4.2.18 Sent By .................................................30 - 4.2.19 Time Zone Identifier ....................................30 - 4.2.20 Value Data Types ........................................32 - 4.3 Property Value Data Types ...................................32 - 4.3.1 Binary ...................................................33 - 4.3.2 Boolean ..................................................33 - 4.3.3 Calendar User Address ....................................34 - 4.3.4 Date .....................................................34 - 4.3.5 Date-Time ................................................35 - 4.3.6 Duration .................................................37 - 4.3.7 Float ....................................................38 - 4.3.8 Integer ..................................................38 - 4.3.9 Period of Time ...........................................39 - 4.3.10 Recurrence Rule .........................................40 - 4.3.11 Text ....................................................45 - 4.3.12 Time ....................................................47 - 4.3.13 URI .....................................................49 - 4.3.14 UTC Offset ..............................................49 - 4.4 iCalendar Object ............................................50 - 4.5 Property ....................................................51 - 4.6 Calendar Components .........................................51 - 4.6.1 Event Component ..........................................52 - 4.6.2 To-do Component ..........................................55 - 4.6.3 Journal Component ........................................56 - 4.6.4 Free/Busy Component ......................................58 - 4.6.5 Time Zone Component ......................................60 - 4.6.6 Alarm Component ..........................................67 - 4.7 Calendar Properties .........................................73 - 4.7.1 Calendar Scale ...........................................73 - - - -Dawson & Stenerson Standards Track [Page 3] - -RFC 2445 iCalendar November 1998 - - - 4.7.2 Method ...................................................74 - 4.7.3 Product Identifier .......................................75 - 4.7.4 Version ..................................................76 - 4.8 Component Properties ........................................77 - 4.8.1 Descriptive Component Properties .........................77 - 4.8.1.1 Attachment ...........................................77 - 4.8.1.2 Categories ...........................................78 - 4.8.1.3 Classification .......................................79 - 4.8.1.4 Comment ..............................................80 - 4.8.1.5 Description ..........................................81 - 4.8.1.6 Geographic Position ..................................82 - 4.8.1.7 Location .............................................84 - 4.8.1.8 Percent Complete .....................................85 - 4.8.1.9 Priority .............................................85 - 4.8.1.10 Resources ...........................................87 - 4.8.1.11 Status ..............................................88 - 4.8.1.12 Summary .............................................89 - 4.8.2 Date and Time Component Properties .......................90 - 4.8.2.1 Date/Time Completed ..................................90 - 4.8.2.2 Date/Time End ........................................91 - 4.8.2.3 Date/Time Due ........................................92 - 4.8.2.4 Date/Time Start ......................................93 - 4.8.2.5 Duration .............................................94 - 4.8.2.6 Free/Busy Time .......................................95 - 4.8.2.7 Time Transparency ....................................96 - 4.8.3 Time Zone Component Properties ...........................97 - 4.8.3.1 Time Zone Identifier .................................97 - 4.8.3.2 Time Zone Name .......................................98 - 4.8.3.3 Time Zone Offset From ................................99 - 4.8.3.4 Time Zone Offset To .................................100 - 4.8.3.5 Time Zone URL .......................................101 - 4.8.4 Relationship Component Properties .......................102 - 4.8.4.1 Attendee ............................................102 - 4.8.4.2 Contact .............................................104 - 4.8.4.3 Organizer ...........................................106 - 4.8.4.4 Recurrence ID .......................................107 - 4.8.4.5 Related To ..........................................109 - 4.8.4.6 Uniform Resource Locator ............................110 - 4.8.4.7 Unique Identifier ...................................111 - 4.8.5 Recurrence Component Properties .........................112 - 4.8.5.1 Exception Date/Times ................................112 - 4.8.5.2 Exception Rule ......................................114 - 4.8.5.3 Recurrence Date/Times ...............................115 - 4.8.5.4 Recurrence Rule .....................................117 - 4.8.6 Alarm Component Properties ..............................126 - 4.8.6.1 Action ..............................................126 - 4.8.6.2 Repeat Count ........................................126 - 4.8.6.3 Trigger .............................................127 - - - -Dawson & Stenerson Standards Track [Page 4] - -RFC 2445 iCalendar November 1998 - - - 4.8.7 Change Management Component Properties ..................129 - 4.8.7.1 Date/Time Created ...................................129 - 4.8.7.2 Date/Time Stamp .....................................130 - 4.8.7.3 Last Modified .......................................131 - 4.8.7.4 Sequence Number .....................................131 - 4.8.8 Miscellaneous Component Properties ......................133 - 4.8.8.1 Non-standard Properties .............................133 - 4.8.8.2 Request Status ......................................134 - 5 iCalendar Object Examples......................................136 - 6 Recommended Practices..........................................140 - 7 Registration of Content Type Elements..........................141 - 7.1 Registration of New and Modified iCalendar Object Methods ..141 - 7.2 Registration of New Properties .............................141 - 7.2.1 Define the property .....................................142 - 7.2.2 Post the Property definition ............................143 - 7.2.3 Allow a comment period ..................................143 - 7.2.4 Submit the property for approval ........................143 - 7.3 Property Change Control ....................................143 - 8 References.....................................................144 - 9 Acknowledgments................................................145 - 10 Authors' and Chairs' Addresses................................146 - 11 Full Copyright Statement......................................148 - -1 Introduction - - The use of calendaring and scheduling has grown considerably in the - last decade. Enterprise and inter-enterprise business has become - dependent on rapid scheduling of events and actions using this - information technology. However, the longer term growth of - calendaring and scheduling, is currently limited by the lack of - Internet standards for the message content types that are central to - these knowledgeware applications. This memo is intended to progress - the level of interoperability possible between dissimilar calendaring - and scheduling applications. This memo defines a MIME content type - for exchanging electronic calendaring and scheduling information. The - Internet Calendaring and Scheduling Core Object Specification, or - iCalendar, allows for the capture and exchange of information - normally stored within a calendaring and scheduling application; such - as a Personal Information Manager (PIM) or a Group Scheduling - product. - - The iCalendar format is suitable as an exchange format between - applications or systems. The format is defined in terms of a MIME - content type. This will enable the object to be exchanged using - several transports, including but not limited to SMTP, HTTP, a file - system, desktop interactive protocols such as the use of a memory- - based clipboard or drag/drop interactions, point-to-point - asynchronous communication, wired-network transport, or some form of - - - -Dawson & Stenerson Standards Track [Page 5] - -RFC 2445 iCalendar November 1998 - - - unwired transport such as infrared might also be used. - - The memo also provides for the definition of iCalendar object methods - that will map this content type to a set of messages for supporting - calendaring and scheduling operations such as requesting, replying - to, modifying, and canceling meetings or appointments, to-dos and - journal entries. The iCalendar object methods can be used to define - other calendaring and scheduling operations such a requesting for and - replying with free/busy time data. Such a scheduling protocol is - defined in the iCalendar Transport-independent Interoperability - Protocol (iTIP) defined in [ITIP]. - - The memo also includes a formal grammar for the content type based on - the Internet ABNF defined in [RFC 2234]. This ABNF is required for - the implementation of parsers and to serve as the definitive - reference when ambiguities or questions arise in interpreting the - descriptive prose definition of the memo. - -2 Basic Grammar and Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and - "OPTIONAL" in this document are to be interoperated as described in - [RFC 2119]. - - This memo makes use of both a descriptive prose and a more formal - notation for defining the calendaring and scheduling format. - - The notation used in this memo is the ABNF notation of [RFC 2234]. - Readers intending on implementing this format defined in this memo - should be familiar with this notation in order to properly interpret - the specifications of this memo. - - All numeric and hexadecimal values used in this memo are given in - decimal notation. - - All names of properties, property parameters, enumerated property - values and property parameter values are case-insensitive. However, - all other property values are case-sensitive, unless otherwise - stated. - - Note: All indented editorial notes, such as this one, are - intended to provide the reader with additional information. The - information is not essential to the building of an - implementation conformant with this memo. The information is - provided to highlight a particular feature or characteristic of - the memo. - - - - -Dawson & Stenerson Standards Track [Page 6] - -RFC 2445 iCalendar November 1998 - - - The format for the iCalendar object is based on the syntax of the - [RFC 2425] content type. While the iCalendar object is not a profile - of the [RFC 2425] content type, it does reuse a number of the - elements from the [RFC 2425] specification. - -2.1 Formatting Conventions - - The mechanisms defined in this memo are defined in prose. Many of the - terms used to describe these have common usage that is different than - the standards usage of this memo. In order to reference within this - memo elements of the calendaring and scheduling model, core object - (this memo) or interoperability protocol [ITIP] some formatting - conventions have been used. Calendaring and scheduling roles are - referred to in quoted-strings of text with the first character of - each word in upper case. For example, "Organizer" refers to a role of - a "Calendar User" within the scheduling protocol defined by [ITIP]. - Calendar components defined by this memo are referred to with - capitalized, quoted-strings of text. All calendar components start - with the letter "V". For example, "VEVENT" refers to the event - calendar component, "VTODO" refers to the to-do calendar component - and "VJOURNAL" refers to the daily journal calendar component. - Scheduling methods defined by [ITIP] are referred to with - capitalized, quoted-strings of text. For example, "REQUEST" refers to - the method for requesting a scheduling calendar component be created - or modified, "REPLY" refers to the method a recipient of a request - uses to update their status with the "Organizer" of the calendar - component. - - The properties defined by this memo are referred to with capitalized, - quoted-strings of text, followed by the word "property". For example, - "ATTENDEE" property refers to the iCalendar property used to convey - the calendar address of a calendar user. Property parameters defined - by this memo are referred to with lowercase, quoted-strings of text, - followed by the word "parameter". For example, "value" parameter - refers to the iCalendar property parameter used to override the - default data type for a property value. Enumerated values defined by - this memo are referred to with capitalized text, either alone or - followed by the word "value". For example, the "MINUTELY" value can - be used with the "FREQ" component of the "RECUR" data type to specify - repeating components based on an interval of one minute or more. - - - - - - - - - - - -Dawson & Stenerson Standards Track [Page 7] - -RFC 2445 iCalendar November 1998 - - -2.2 Related Memos - - Implementers will need to be familiar with several other memos that, - along with this memo, form a framework for Internet calendaring and - scheduling standards. This memo, [ICAL], specifies a core - specification of objects, data types, properties and property - parameters. - - [ITIP] - specifies an interoperability protocol for scheduling - between different implementations; - - [IMIP] specifies an Internet email binding for [ITIP]. - - This memo does not attempt to repeat the specification of concepts or - definitions from these other memos. Where possible, references are - made to the memo that provides for the specification of these - concepts or definitions. - -2.3 International Considerations - - In the rest of this document, descriptions of characters are of the - form "character name (codepoint)", where "codepoint" is from the US- - ASCII character set. The "character name" is the authoritative - description; (codepoint) is a reference to that character in US-ASCII - or US-ASCII compatible sets (for example the ISO-8859-x family, UTF- - 8, ISO-2022-xx, KOI8-R). If a non-US-ASCII compatible character set - is used, appropriate code-point from that character set MUST be - chosen instead. Use of non-US-ASCII-compatible character sets is NOT - recommended. - -3 Registration Information - - The Calendaring and Scheduling Core Object Specification is intended - for use as a MIME content type. However, the implementation of the - memo is in no way limited solely as a MIME content type. - -3.1 Content Type - - The following text is intended to register this memo as the MIME - content type "text/calendar". - - To: ietf-types@uninett.no - - Subject: Registration of MIME content type text/calendar. - - MIME media type name: text - - MIME subtype name: calendar - - - -Dawson & Stenerson Standards Track [Page 8] - -RFC 2445 iCalendar November 1998 - - -3.2 Parameters - - Required parameters: none - - Optional parameters: charset, method, component and optinfo - - The "charset" parameter is defined in [RFC 2046] for other body - parts. It is used to identify the default character set used within - the body part. - - The "method" parameter is used to convey the iCalendar object method - or transaction semantics for the calendaring and scheduling - information. It also is an identifier for the restricted set of - properties and values that the iCalendar object consists of. The - parameter is to be used as a guide for applications interpreting the - information contained within the body part. It SHOULD NOT be used to - exclude or require particular pieces of information unless the - identified method definition specifically calls for this behavior. - Unless specifically forbidden by a particular method definition, a - text/calendar content type can contain any set of properties - permitted by the Calendaring and Scheduling Core Object - Specification. The "method" parameter MUST be the same value as that - specified in the "METHOD" component property in the iCalendar object. - If one is present, the other MUST also be present. - - The value for the "method" parameter is defined as follows: - - method = 1*(ALPHA / DIGIT / "-") - ; IANA registered iCalendar object method - - The "component" parameter conveys the type of iCalendar calendar - component within the body part. If the iCalendar object contains more - than one calendar component type, then multiple component parameters - MUST be specified. - - The value for the "component" parameter is defined as follows: - - component = ("VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY" - / "VTIMEZONE" / x-name / iana-token) - - The "optinfo" parameter conveys optional information about the - iCalendar object within the body part. This parameter can only - specify semantics already specified by the iCalendar object and that - can be otherwise determined by parsing the body part. In addition, - the optional information specified by this parameter MUST be - consistent with that information specified by the iCalendar object. - For example, it can be used to convey the "Attendee" response status - to a meeting request. The parameter value consists of a string value. - - - -Dawson & Stenerson Standards Track [Page 9] - -RFC 2445 iCalendar November 1998 - - - The parameter can be specified multiple times. - - This parameter MAY only specify semantics already specified by the - iCalendar object and that can be otherwise determined by parsing the - body part. - - The value for the "optinfo" parameter is defined as follows: - - optinfo = infovalue / qinfovalue - - infovalue = iana-token / x-name - - qinfovalue = DQUOTE (infovalue) DQUOTE - -3.3 Content Header Fields - - Optional content header fields: Any header fields defined by [RFC - 2045]. - -3.4 Encoding Considerations - - This MIME content type can contain 8bit characters, so the use of - quoted-printable or BASE64 MIME content-transfer-encodings might be - necessary when iCalendar objects are transferred across protocols - restricted to the 7bit repertoire. Note that a text valued property - in the content entity can also have content encoding of special - characters using a BACKSLASH character (US-ASCII decimal 92) - escapement technique. This means that content values can end up - encoded twice. - -3.5 Security Considerations - - SPOOFING - - In this memo, the "Organizer" is the only person - authorized to make changes to an existing "VEVENT", "VTODO", - "VJOURNAL" calendar component and redistribute the updates to the - "Attendees". An iCalendar object that maliciously changes or cancels - an existing "VEVENT", "VTODO" or "VJOURNAL" or "VFREEBUSY" calendar - component might be constructed by someone other than the "Organizer" - and sent to the "Attendees". In addition in this memo, other than the - "Organizer", an "Attendee" of a "VEVENT", "VTODO", "VJOURNAL" - calendar component is the only other person authorized to update any - parameter associated with their "ATTENDEE" property and send it to - the "Organizer". An iCalendar object that maliciously changes the - "ATTENDEE" parameters can be constructed by someone other than the - real "Attendee" and sent to the "Organizer". - - - - - - -Dawson & Stenerson Standards Track [Page 10] - -RFC 2445 iCalendar November 1998 - - - PROCEDURAL ALARMS - - An iCalendar object can be created that - contains a "VEVENT" and "VTODO" calendar component with "VALARM" - calendar components. The "VALARM" calendar component can be of type - PROCEDURE and can have an attachment containing some sort of - executable program. Implementations that incorporate these types of - alarms are subject to any virus or malicious attack that might occur - as a result of executing the attachment. - - ATTACHMENTS - - An iCalendar object can include references to Uniform - Resource Locators that can be programmed resources. - - Implementers and users of this memo should be aware of the network - security implications of accepting and parsing such information. In - addition, the security considerations observed by implementations of - electronic mail systems should be followed for this memo. - -3.6 Interoperability Considerations - - This MIME content type is intended to define a common format for - conveying calendaring and scheduling information between different - systems. It is heavily based on the earlier [VCAL] industry - specification. - -3.7 Applications Which Use This Media Type - - This content-type is designed for widespread use by Internet - calendaring and scheduling applications. In addition, applications in - the workflow and document management area might find this content- - type applicable. The [ITIP] and [IMIP] Internet protocols directly - use this content-type also. Future work on an Internet calendar - access protocol will utilize this content-type too. - -3.8 Additional Information - - This memo defines this content-type. - -3.9 Magic Numbers - - None. - -3.10 File Extensions - - The file extension of "ics" is to be used to designate a file - containing (an arbitrary set of) calendaring and scheduling - information consistent with this MIME content type. - - - - - - -Dawson & Stenerson Standards Track [Page 11] - -RFC 2445 iCalendar November 1998 - - - The file extension of "ifb" is to be used to designate a file - containing free or busy time information consistent with this MIME - content type. - - Macintosh file type codes: The file type code of "iCal" is to be used - in Apple MacIntosh operating system environments to designate a file - containing calendaring and scheduling information consistent with - this MIME media type. - - The file type code of "iFBf" is to be used in Apple MacIntosh - operating system environments to designate a file containing free or - busy time information consistent with this MIME media type. - -3.11 Contact for Further Information: - - Frank Dawson - 6544 Battleford Drive - Raleigh, NC 27613-3502 - 919-676-9515 (Telephone) - 919-676-9564 (Data/Facsimile) - Frank_Dawson@Lotus.com (Internet Mail) - - Derik Stenerson - One Microsoft Way - Redmond, WA 98052-6399 - 425-936-5522 (Telephone) - 425-936-7329 (Facsimile) - deriks@microsoft.com (Internet Mail) - -3.12 Intended Usage - - COMMON - -3.13 Authors/Change Controllers - - Frank Dawson - 6544 Battleford Drive - Raleigh, NC 27613-3502 - 919-676-9515 (Telephone) - 919-676-9564 (Data/Facsimile) - Frank_Dawson@Lotus.com (Internet Mail) - - Derik Stenerson - One Microsoft Way - Redmond, WA 98052-6399 - 425-936-5522 (Telephone) - 425-936-7329 (Facsimile) - deriks@microsoft.com (Internet Mail) - - - -Dawson & Stenerson Standards Track [Page 12] - -RFC 2445 iCalendar November 1998 - - -4 iCalendar Object Specification - - The following sections define the details of a Calendaring and - Scheduling Core Object Specification. This information is intended to - be an integral part of the MIME content type registration. In - addition, this information can be used independent of such content - registration. In particular, this memo has direct applicability for - use as a calendaring and scheduling exchange format in file-, memory- - or network-based transport mechanisms. - -4.1 Content Lines - - The iCalendar object is organized into individual lines of text, - called content lines. Content lines are delimited by a line break, - which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII - decimal 10). - - Lines of text SHOULD NOT be longer than 75 octets, excluding the line - break. Long content lines SHOULD be split into a multiple line - representations using a line "folding" technique. That is, a long - line can be split between any two characters by inserting a CRLF - immediately followed by a single linear white space character (i.e., - SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence - of CRLF followed immediately by a single linear white space character - is ignored (i.e., removed) when processing the content type. - - For example the line: - - DESCRIPTION:This is a long description that exists on a long line. - - Can be represented as: - - DESCRIPTION:This is a lo - ng description - that exists on a long line. - - The process of moving from this folded multiple line representation - to its single line representation is called "unfolding". Unfolding is - accomplished by removing the CRLF character and the linear white - space character that immediately follows. - - When parsing a content line, folded lines MUST first be unfolded - according to the unfolding procedure described above. When generating - a content line, lines longer than 75 octets SHOULD be folded - according to the folding procedure described above. - - - - - - -Dawson & Stenerson Standards Track [Page 13] - -RFC 2445 iCalendar November 1998 - - - The content information associated with an iCalendar object is - formatted using a syntax similar to that defined by [RFC 2425]. That - is, the content information consists of CRLF-separated content lines. - - The following notation defines the lines of content in an iCalendar - object: - - contentline = name *(";" param ) ":" value CRLF - ; This ABNF is just a general definition for an initial parsing - ; of the content line into its property name, parameter list, - ; and value string - - ; When parsing a content line, folded lines MUST first - ; be unfolded according to the unfolding procedure - ; described above. When generating a content line, lines - ; longer than 75 octets SHOULD be folded according to - ; the folding procedure described above. - - name = x-name / iana-token - - iana-token = 1*(ALPHA / DIGIT / "-") - ; iCalendar identifier registered with IANA - - x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") - ; Reservered for experimental use. Not intended for use in - ; released products. - - vendorid = 3*(ALPHA / DIGIT) ;Vendor identification - - param = param-name "=" param-value - *("," param-value) - ; Each property defines the specific ABNF for the parameters - ; allowed on the property. Refer to specific properties for - ; precise parameter ABNF. - - param-name = iana-token / x-token - - param-value = paramtext / quoted-string - - paramtext = *SAFE-CHAR - - value = *VALUE-CHAR - - quoted-string = DQUOTE *QSAFE-CHAR DQUOTE - - NON-US-ASCII = %x80-F8 - ; Use restricted by charset parameter - ; on outer MIME object (UTF-8 preferred) - - - -Dawson & Stenerson Standards Track [Page 14] - -RFC 2445 iCalendar November 1998 - - - QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII - ; Any character except CTLs and DQUOTE - - SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E - / NON-US-ASCII - ; Any character except CTLs, DQUOTE, ";", ":", "," - - VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII - ; Any textual character - - CR = %x0D - ; carriage return - - LF = %x0A - ; line feed - - CRLF = CR LF - ; Internet standard newline - - CTL = %x00-08 / %x0A-1F / %x7F - ; Controls - - ALPHA = %x41-5A / %x61-7A ; A-Z / a-z - - DIGIT = %x30-39 - ; 0-9 - - DQUOTE = %x22 - ; Quotation Mark - - WSP = SPACE / HTAB - - SPACE = %x20 - - HTAB = %x09 - - The property value component of a content line has a format that is - property specific. Refer to the section describing each property for - a definition of this format. - - All names of properties, property parameters, enumerated property - values and property parameter values are case-insensitive. However, - all other property values are case-sensitive, unless otherwise - stated. - - - - - - - -Dawson & Stenerson Standards Track [Page 15] - -RFC 2445 iCalendar November 1998 - - -4.1.1 List and Field Separators - - Some properties and parameters allow a list of values. Values in a - list of values MUST be separated by a COMMA character (US-ASCII - decimal 44). There is no significance to the order of values in a - list. For those parameter values (such as those that specify URI - values) that are specified in quoted-strings, the individual quoted- - strings are separated by a COMMA character (US-ASCII decimal 44). - - Some property values are defined in terms of multiple parts. These - structured property values MUST have their value parts separated by a - SEMICOLON character (US-ASCII decimal 59). - - Some properties allow a list of parameters. Each property parameter - in a list of property parameters MUST be separated by a SEMICOLON - character (US-ASCII decimal 59). - - Property parameters with values containing a COLON, a SEMICOLON or a - COMMA character MUST be placed in quoted text. - - For example, in the following properties a SEMICOLON is used to - separate property parameters from each other, and a COMMA is used to - separate property values in a value list. - - ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:MAILTO: - jsmith@host.com - - RDATE;VALUE=DATE:19970304,19970504,19970704,19970904 - -4.1.2 Multiple Values - - Some properties defined in the iCalendar object can have multiple - values. The general rule for encoding multi-valued items is to simply - create a new content line for each value, including the property - name. However, it should be noted that some properties support - encoding multiple values in a single property by separating the - values with a COMMA character (US-ASCII decimal 44). Individual - property definitions should be consulted for determining whether a - specific property allows multiple values and in which of these two - forms. - -4.1.3 Binary Content - - Binary content information in an iCalendar object SHOULD be - referenced using a URI within a property value. That is the binary - content information SHOULD be placed in an external MIME entity that - can be referenced by a URI from within the iCalendar object. In - applications where this is not feasible, binary content information - - - -Dawson & Stenerson Standards Track [Page 16] - -RFC 2445 iCalendar November 1998 - - - can be included within an iCalendar object, but only after first - encoding it into text using the "BASE64" encoding method defined in - [RFC 2045]. Inline binary contact SHOULD only be used in applications - whose special circumstances demand that an iCalendar object be - expressed as a single entity. A property containing inline binary - content information MUST specify the "ENCODING" property parameter. - Binary content information placed external to the iCalendar object - MUST be referenced by a uniform resource identifier (URI). - - The following example specifies an "ATTACH" property that references - an attachment external to the iCalendar object with a URI reference: - - ATTACH:http://xyz.com/public/quarterly-report.doc - - The following example specifies an "ATTACH" property with inline - binary encoded content information: - - ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY: - MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U - EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE - <...remainder of "BASE64" encoded binary data...> - -4.1.4 Character Set - - There is not a property parameter to declare the character set used - in a property value. The default character set for an iCalendar - object is UTF-8 as defined in [RFC 2279]. - - The "charset" Content-Type parameter can be used in MIME transports - to specify any other IANA registered character set. - -4.2 Property Parameters - - A property can have attributes associated with it. These "property - parameters" contain meta-information about the property or the - property value. Property parameters are provided to specify such - information as the location of an alternate text representation for a - property value, the language of a text property value, the data type - of the property value and other attributes. - - Property parameter values that contain the COLON (US-ASCII decimal - 58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII decimal 44) - character separators MUST be specified as quoted-string text values. - Property parameter values MUST NOT contain the DOUBLE-QUOTE (US-ASCII - decimal 22) character. The DOUBLE-QUOTE (US-ASCII decimal 22) - character is used as a delimiter for parameter values that contain - restricted characters or URI text. For example: - - - - -Dawson & Stenerson Standards Track [Page 17] - -RFC 2445 iCalendar November 1998 - - - DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards - Conference - - Las Vegas, NV, USA - - Property parameter values that are not in quoted strings are case - insensitive. - - The general property parameters defined by this memo are defined by - the following notation: - - parameter = altrepparam ; Alternate text representation - / cnparam ; Common name - / cutypeparam ; Calendar user type - / delfromparam ; Delegator - / deltoparam ; Delegatee - / dirparam ; Directory entry - / encodingparam ; Inline encoding - / fmttypeparam ; Format type - / fbtypeparam ; Free/busy time type - / languageparam ; Language for text - / memberparam ; Group or list membership - / partstatparam ; Participation status - / rangeparam ; Recurrence identifier range - / trigrelparam ; Alarm trigger relationship - / reltypeparam ; Relationship type - / roleparam ; Participation role - / rsvpparam ; RSVP expectation - / sentbyparam ; Sent by - / tzidparam ; Reference to time zone object - / valuetypeparam ; Property value data type - / ianaparam - ; Some other IANA registered iCalendar parameter. - / xparam - ; A non-standard, experimental parameter. - - ianaparam = iana-token "=" param-value *("," param-value) - - xparam =x-name "=" param-value *("," param-value) - -4.2.1 Alternate Text Representation - - Parameter Name: ALTREP - - Purpose: To specify an alternate text representation for the property - value. - - Format Definition: The property parameter is defined by the following - notation: - - - - -Dawson & Stenerson Standards Track [Page 18] - -RFC 2445 iCalendar November 1998 - - - altrepparam = "ALTREP" "=" DQUOTE uri DQUOTE - - Description: The parameter specifies a URI that points to an - alternate representation for a textual property value. A property - specifying this parameter MUST also include a value that reflects the - default representation of the text value. The individual URI - parameter values MUST each be specified in a quoted-string. - - Example: - - DESCRIPTION;ALTREP="CID:":Project - XYZ Review Meeting will include the following agenda items: (a) - Market Overview, (b) Finances, (c) Project Management - - The "ALTREP" property parameter value might point to a "text/html" - content portion. - - Content-Type:text/html - Content-Id: - - -

Project XYZ Review Meeting will include the following - agenda items:

  1. Market - Overview
  2. Finances
  3. Project Management

- - -4.2.2 Common Name - - Parameter Name: CN - - Purpose: To specify the common name to be associated with the - calendar user specified by the property. - - Format Definition: The property parameter is defined by the following - notation: - - cnparam = "CN" "=" param-value - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter specifies the common name to be - associated with the calendar user specified by the property. The - parameter value is text. The parameter value can be used for display - text to be associated with the calendar address specified by the - property. - - - - - - - -Dawson & Stenerson Standards Track [Page 19] - -RFC 2445 iCalendar November 1998 - - - Example: - - ORGANIZER;CN="John Smith":MAILTO:jsmith@host.com - -4.2.3 Calendar User Type - - Parameter Name: CUTYPE - - Purpose: To specify the type of calendar user specified by the - property. - - Format Definition: The property parameter is defined by the following - notation: - - cutypeparam = "CUTYPE" "=" - ("INDIVIDUAL" ; An individual - / "GROUP" ; A group of individuals - / "RESOURCE" ; A physical resource - / "ROOM" ; A room resource - / "UNKNOWN" ; Otherwise not known - / x-name ; Experimental type - / iana-token) ; Other IANA registered - ; type - ; Default is INDIVIDUAL - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter identifies the type of calendar - user specified by the property. If not specified on a property that - allows this parameter, the default is INDIVIDUAL. - - Example: - - ATTENDEE;CUTYPE=GROUP:MAILTO:ietf-calsch@imc.org - -4.2.4 Delegators - - Parameter Name: DELEGATED-FROM - - Purpose: To specify the calendar users that have delegated their - participation to the calendar user specified by the property. - - Format Definition: The property parameter is defined by the following - notation: - - delfromparam = "DELEGATED-FROM" "=" DQUOTE cal-address DQUOTE - *("," DQUOTE cal-address DQUOTE) - - - - - -Dawson & Stenerson Standards Track [Page 20] - -RFC 2445 iCalendar November 1998 - - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. This parameter can be specified on a property - that has a value type of calendar address. This parameter specifies - those calendar uses that have delegated their participation in a - group scheduled event or to-do to the calendar user specified by the - property. The value MUST be a MAILTO URI as defined in [RFC 1738]. - The individual calendar address parameter values MUST each be - specified in a quoted-string. - - Example: - - ATTENDEE;DELEGATED-FROM="MAILTO:jsmith@host.com":MAILTO: - jdoe@host.com - -4.2.5 Delegatees - - Parameter Name: DELEGATED-TO - - Purpose: To specify the calendar users to whom the calendar user - specified by the property has delegated participation. - - Format Definition: The property parameter is defined by the following - notation: - - deltoparam = "DELEGATED-TO" "=" DQUOTE cal-address DQUOTE - *("," DQUOTE cal-address DQUOTE) - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. This parameter specifies those calendar users - whom have been delegated participation in a group scheduled event or - to-do by the calendar user specified by the property. The value MUST - be a MAILTO URI as defined in [RFC 1738]. The individual calendar - address parameter values MUST each be specified in a quoted-string. - - Example: - - ATTENDEE;DELEGATED-TO="MAILTO:jdoe@host.com","MAILTO:jqpublic@ - host.com":MAILTO:jsmith@host.com - -4.2.6 Directory Entry Reference - - Parameter Name: DIR - - Purpose: To specify reference to a directory entry associated with - the calendar user specified by the property. - - Format Definition: The property parameter is defined by the following - notation: - - - -Dawson & Stenerson Standards Track [Page 21] - -RFC 2445 iCalendar November 1998 - - - dirparam = "DIR" "=" DQUOTE uri DQUOTE - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter specifies a reference to the - directory entry associated with the calendar user specified by the - property. The parameter value is a URI. The individual URI parameter - values MUST each be specified in a quoted-string. - - Example: - - ORGANIZER;DIR="ldap://host.com:6666/o=eDABC%20Industries,c=3DUS?? - (cn=3DBJim%20Dolittle)":MAILTO:jimdo@host1.com - -4.2.7 Inline Encoding - - Parameter Name: ENCODING - - Purpose: To specify an alternate inline encoding for the property - value. - - Format Definition: The property parameter is defined by the following - notation: - - encodingparam = "ENCODING" "=" - ("8BIT" - ; "8bit" text encoding is defined in [RFC 2045] - / "BASE64" - ; "BASE64" binary encoding format is defined in [RFC 2045] - / iana-token - ; Some other IANA registered iCalendar encoding type - / x-name) - ; A non-standard, experimental encoding type - - Description: The property parameter identifies the inline encoding - used in a property value. The default encoding is "8BIT", - corresponding to a property value consisting of text. The "BASE64" - encoding type corresponds to a property value encoded using the - "BASE64" encoding defined in [RFC 2045]. - - If the value type parameter is ";VALUE=BINARY", then the inline - encoding parameter MUST be specified with the value - ";ENCODING=BASE64". - - - - - - - - - -Dawson & Stenerson Standards Track [Page 22] - -RFC 2445 iCalendar November 1998 - - - Example: - - ATTACH;FMTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC - CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA - qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw - <...remainder of "BASE64" encoded binary data...> - -4.2.8 Format Type - - Parameter Name: FMTTYPE - - Purpose: To specify the content type of a referenced object. - - Format Definition: The property parameter is defined by the following - notation: - - fmttypeparam = "FMTTYPE" "=" iana-token - ; A IANA registered content type - / x-name - ; A non-standard content type - - Description: This parameter can be specified on properties that are - used to reference an object. The parameter specifies the content type - of the referenced object. For example, on the "ATTACH" property, a - FTP type URI value does not, by itself, necessarily convey the type - of content associated with the resource. The parameter value MUST be - the TEXT for either an IANA registered content type or a non-standard - content type. - - Example: - - ATTACH;FMTTYPE=application/binary:ftp://domain.com/pub/docs/ - agenda.doc - -4.2.9 Free/Busy Time Type - - Parameter Name: FBTYPE - - Purpose: To specify the free or busy time type. - - Format Definition: The property parameter is defined by the following - notation: - - fbtypeparam = "FBTYPE" "=" ("FREE" / "BUSY" - / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE" - / x-name - ; Some experimental iCalendar data type. - / iana-token) - - - -Dawson & Stenerson Standards Track [Page 23] - -RFC 2445 iCalendar November 1998 - - - ; Some other IANA registered iCalendar data type. - - Description: The parameter specifies the free or busy time type. The - value FREE indicates that the time interval is free for scheduling. - The value BUSY indicates that the time interval is busy because one - or more events have been scheduled for that interval. The value - BUSY-UNAVAILABLE indicates that the time interval is busy and that - the interval can not be scheduled. The value BUSY-TENTATIVE indicates - that the time interval is busy because one or more events have been - tentatively scheduled for that interval. If not specified on a - property that allows this parameter, the default is BUSY. - - Example: The following is an example of this parameter on a FREEBUSY - property. - - FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z - -4.2.10 Language - - Parameter Name: LANGUAGE - - Purpose: To specify the language for text values in a property or - property parameter. - - Format Definition: The property parameter is defined by the following - notation: - - languageparam = "LANGUAGE" "=" language - - language = - - Description: This parameter can be specified on properties with a - text value type. The parameter identifies the language of the text in - the property or property parameter value. The value of the "language" - property parameter is that defined in [RFC 1766]. - - For transport in a MIME entity, the Content-Language header field can - be used to set the default language for the entire body part. - Otherwise, no default language is assumed. - - Example: - - SUMMARY;LANGUAGE=us-EN:Company Holiday Party - - LOCATION;LANGUAGE=en:Germany - LOCATION;LANGUAGE=no:Tyskland - - - - - -Dawson & Stenerson Standards Track [Page 24] - -RFC 2445 iCalendar November 1998 - - - The following example makes use of the Quoted-Printable encoding in - order to represent non-ASCII characters. - - LOCATION;LANGUAGE=da:K=F8benhavn - LOCATION;LANGUAGE=en:Copenhagen - -4.2.11 Group or List Membership - - Parameter Name: MEMBER - - Purpose: To specify the group or list membership of the calendar user - specified by the property. - - Format Definition: The property parameter is defined by the following - notation: - - memberparam = "MEMBER" "=" DQUOTE cal-address DQUOTE - *("," DQUOTE cal-address DQUOTE) - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter identifies the groups or list - membership for the calendar user specified by the property. The - parameter value either a single calendar address in a quoted-string - or a COMMA character (US-ASCII decimal 44) list of calendar - addresses, each in a quoted-string. The individual calendar address - parameter values MUST each be specified in a quoted-string. - - Example: - - ATTENDEE;MEMBER="MAILTO:ietf-calsch@imc.org":MAILTO:jsmith@host.com - - ATTENDEE;MEMBER="MAILTO:projectA@host.com","MAILTO:projectB@host. - com":MAILTO:janedoe@host.com - -4.2.12 Participation Status - - Parameter Name: PARTSTAT - - Purpose: To specify the participation status for the calendar user - specified by the property. - - Format Definition: The property parameter is defined by the following - notation: - - partstatparam = "PARTSTAT" "=" - ("NEEDS-ACTION" ; Event needs action - / "ACCEPTED" ; Event accepted - / "DECLINED" ; Event declined - - - -Dawson & Stenerson Standards Track [Page 25] - -RFC 2445 iCalendar November 1998 - - - / "TENTATIVE" ; Event tentatively - ; accepted - / "DELEGATED" ; Event delegated - / x-name ; Experimental status - / iana-token) ; Other IANA registered - ; status - ; These are the participation statuses for a "VEVENT". Default is - ; NEEDS-ACTION - partstatparam /= "PARTSTAT" "=" - ("NEEDS-ACTION" ; To-do needs action - / "ACCEPTED" ; To-do accepted - / "DECLINED" ; To-do declined - / "TENTATIVE" ; To-do tentatively - ; accepted - / "DELEGATED" ; To-do delegated - / "COMPLETED" ; To-do completed. - ; COMPLETED property has - ;date/time completed. - / "IN-PROCESS" ; To-do in process of - ; being completed - / x-name ; Experimental status - / iana-token) ; Other IANA registered - ; status - ; These are the participation statuses for a "VTODO". Default is - ; NEEDS-ACTION - - partstatparam /= "PARTSTAT" "=" - ("NEEDS-ACTION" ; Journal needs action - / "ACCEPTED" ; Journal accepted - / "DECLINED" ; Journal declined - / x-name ; Experimental status - / iana-token) ; Other IANA registered - ; status - ; These are the participation statuses for a "VJOURNAL". Default is - ; NEEDS-ACTION - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter identifies the participation - status for the calendar user specified by the property value. The - parameter values differ depending on whether they are associated with - a group scheduled "VEVENT", "VTODO" or "VJOURNAL". The values MUST - match one of the values allowed for the given calendar component. If - not specified on a property that allows this parameter, the default - value is NEEDS-ACTION. - - Example: - - ATTENDEE;PARTSTAT=DECLINED:MAILTO:jsmith@host.com - - - -Dawson & Stenerson Standards Track [Page 26] - -RFC 2445 iCalendar November 1998 - - -4.2.13 Recurrence Identifier Range - - Parameter Name: RANGE - - Purpose: To specify the effective range of recurrence instances from - the instance specified by the recurrence identifier specified by the - property. - - Format Definition: The property parameter is defined by the following - notation: - - rangeparam = "RANGE" "=" ("THISANDPRIOR" - ; To specify all instances prior to the recurrence identifier - / "THISANDFUTURE") - ; To specify the instance specified by the recurrence identifier - ; and all subsequent recurrence instances - - Description: The parameter can be specified on a property that - specifies a recurrence identifier. The parameter specifies the - effective range of recurrence instances that is specified by the - property. The effective range is from the recurrence identified - specified by the property. If this parameter is not specified an - allowed property, then the default range is the single instance - specified by the recurrence identifier value of the property. The - parameter value can be "THISANDPRIOR" to indicate a range defined by - the recurrence identified value of the property and all prior - instances. The parameter value can also be "THISANDFUTURE" to - indicate a range defined by the recurrence identifier and all - subsequent instances. - - Example: - - RECURRENCE-ID;RANGE=THISANDPRIOR:19980401T133000Z - -4.2.14 Alarm Trigger Relationship - - Parameter Name: RELATED - - Purpose: To specify the relationship of the alarm trigger with - respect to the start or end of the calendar component. - - Format Definition: The property parameter is defined by the following - notation: - - trigrelparam = "RELATED" "=" - ("START" ; Trigger off of start - / "END") ; Trigger off of end - - - - -Dawson & Stenerson Standards Track [Page 27] - -RFC 2445 iCalendar November 1998 - - - Description: The parameter can be specified on properties that - specify an alarm trigger with a DURATION value type. The parameter - specifies whether the alarm will trigger relative to the start or end - of the calendar component. The parameter value START will set the - alarm to trigger off the start of the calendar component; the - parameter value END will set the alarm to trigger off the end of the - calendar component. If the parameter is not specified on an allowable - property, then the default is START. - - Example: - - TRIGGER;RELATED=END:PT5M - -4.2.15 Relationship Type - - Parameter Name: RELTYPE - - Purpose: To specify the type of hierarchical relationship associated - with the calendar component specified by the property. - - Format Definition: The property parameter is defined by the following - notation: - - reltypeparam = "RELTYPE" "=" - ("PARENT" ; Parent relationship. Default. - / "CHILD" ; Child relationship - / "SIBLING ; Sibling relationship - / iana-token ; Some other IANA registered - ; iCalendar relationship type - / x-name) ; A non-standard, experimental - ; relationship type - - Description: This parameter can be specified on a property that - references another related calendar. The parameter specifies the - hierarchical relationship type of the calendar component referenced - by the property. The parameter value can be PARENT, to indicate that - the referenced calendar component is a superior of calendar - component; CHILD to indicate that the referenced calendar component - is a subordinate of the calendar component; SIBLING to indicate that - the referenced calendar component is a peer of the calendar - component. If this parameter is not specified on an allowable - property, the default relationship type is PARENT. - - Example: - - RELATED-TO;RELTYPE=SIBLING:<19960401-080045-4000F192713@host.com> - - - - - -Dawson & Stenerson Standards Track [Page 28] - -RFC 2445 iCalendar November 1998 - - -4.2.16 Participation Role - - Parameter Name: ROLE - - Purpose: To specify the participation role for the calendar user - specified by the property. - - Format Definition: The property parameter is defined by the following - notation: - - roleparam = "ROLE" "=" - ("CHAIR" ; Indicates chair of the - ; calendar entity - / "REQ-PARTICIPANT" ; Indicates a participant whose - ; participation is required - / "OPT-PARTICIPANT" ; Indicates a participant whose - ; participation is optional - / "NON-PARTICIPANT" ; Indicates a participant who is - ; copied for information - ; purposes only - / x-name ; Experimental role - / iana-token) ; Other IANA role - ; Default is REQ-PARTICIPANT - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter specifies the participation - role for the calendar user specified by the property in the group - schedule calendar component. If not specified on a property that - allows this parameter, the default value is REQ-PARTICIPANT. - - Example: - - ATTENDEE;ROLE=CHAIR:MAILTO:mrbig@host.com - -4.2.17 RSVP Expectation - - Parameter Name: RSVP - - Purpose: To specify whether there is an expectation of a favor of a - reply from the calendar user specified by the property value. - - Format Definition: The property parameter is defined by the following - notation: - - rsvpparam = "RSVP" "=" ("TRUE" / "FALSE") - ; Default is FALSE - - - - - -Dawson & Stenerson Standards Track [Page 29] - -RFC 2445 iCalendar November 1998 - - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter identifies the expectation of a - reply from the calendar user specified by the property value. This - parameter is used by the "Organizer" to request a participation - status reply from an "Attendee" of a group scheduled event or to-do. - If not specified on a property that allows this parameter, the - default value is FALSE. - - Example: - - ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host.com - -4.2.18 Sent By - - Parameter Name: SENT-BY - - Purpose: To specify the calendar user that is acting on behalf of the - calendar user specified by the property. - - Format Definition: The property parameter is defined by the following - notation: - - sentbyparam = "SENT-BY" "=" DQUOTE cal-address DQUOTE - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter specifies the calendar user - that is acting on behalf of the calendar user specified by the - property. The parameter value MUST be a MAILTO URI as defined in [RFC - 1738]. The individual calendar address parameter values MUST each be - specified in a quoted-string. - - Example: - - ORGANIZER;SENT-BY:"MAILTO:sray@host.com":MAILTO:jsmith@host.com - -4.2.19 Time Zone Identifier - - Parameter Name: TZID - - Purpose: To specify the identifier for the time zone definition for a - time component in the property value. - - Format Definition: This property parameter is defined by the - following notation: - - tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF - - tzidprefix = "/" - - - -Dawson & Stenerson Standards Track [Page 30] - -RFC 2445 iCalendar November 1998 - - - Description: The parameter MUST be specified on the "DTSTART", - "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE- - TIME or TIME value type is specified and when the value is not either - a UTC or a "floating" time. Refer to the DATE-TIME or TIME value type - definition for a description of UTC and "floating time" formats. This - property parameter specifies a text value which uniquely identifies - the "VTIMEZONE" calendar component to be used when evaluating the - time portion of the property. The value of the TZID property - parameter will be equal to the value of the TZID property for the - matching time zone definition. An individual "VTIMEZONE" calendar - component MUST be specified for each unique "TZID" parameter value - specified in the iCalendar object. - - The parameter MUST be specified on properties with a DATE-TIME value - if the DATE-TIME is not either a UTC or a "floating" time. - - The presence of the SOLIDUS character (US-ASCII decimal 47) as a - prefix, indicates that this TZID represents a unique ID in a globally - defined time zone registry (when such registry is defined). - - Note: This document does not define a naming convention for time - zone identifiers. Implementers may want to use the naming - conventions defined in existing time zone specifications such as - the public-domain Olson database [TZ]. The specification of - globally unique time zone identifiers is not addressed by this - document and is left for future study. - - The following are examples of this property parameter: - - DTSTART;TZID=US-Eastern:19980119T020000 - - DTEND;TZID=US-Eastern:19980119T030000 - - The TZID property parameter MUST NOT be applied to DATE-TIME or TIME - properties whose time values are specified in UTC. - - The use of local time in a DATE-TIME or TIME value without the TZID - property parameter is to be interpreted as a local time value, - regardless of the existence of "VTIMEZONE" calendar components in the - iCalendar object. - - For more information see the sections on the data types DATE-TIME and - TIME. - - - - - - - - -Dawson & Stenerson Standards Track [Page 31] - -RFC 2445 iCalendar November 1998 - - -4.2.20 Value Data Types - - Parameter Name: VALUE - - Purpose: To explicitly specify the data type format for a property - value. - - Format Definition: The "VALUE" property parameter is defined by the - following notation: - - valuetypeparam = "VALUE" "=" valuetype - - valuetype = ("BINARY" - / "BOOLEAN" - / "CAL-ADDRESS" - / "DATE" - / "DATE-TIME" - / "DURATION" - / "FLOAT" - / "INTEGER" - / "PERIOD" - / "RECUR" - / "TEXT" - / "TIME" - / "URI" - / "UTC-OFFSET" - / x-name - ; Some experimental iCalendar data type. - / iana-token) - ; Some other IANA registered iCalendar data type. - - Description: The parameter specifies the data type and format of the - property value. The property values MUST be of a single value type. - For example, a "RDATE" property cannot have a combination of DATE- - TIME and TIME value types. - - If the property's value is the default value type, then this - parameter need not be specified. However, if the property's default - value type is overridden by some other allowable value type, then - this parameter MUST be specified. - -4.3 Property Value Data Types - - The properties in an iCalendar object are strongly typed. The - definition of each property restricts the value to be one of the - value data types, or simply value types, defined in this section. The - value type for a property will either be specified implicitly as the - default value type or will be explicitly specified with the "VALUE" - - - -Dawson & Stenerson Standards Track [Page 32] - -RFC 2445 iCalendar November 1998 - - - parameter. If the value type of a property is one of the alternate - valid types, then it MUST be explicitly specified with the "VALUE" - parameter. - -4.3.1 Binary - - Value Name: BINARY - - Purpose: This value type is used to identify properties that contain - a character encoding of inline binary data. For example, an inline - attachment of an object code might be included in an iCalendar - object. - - Formal Definition: The value type is defined by the following - notation: - - binary = *(4b-char) [b-end] - ; A "BASE64" encoded character string, as defined by [RFC 2045]. - - b-end = (2b-char "==") / (3b-char "=") - - b-char = ALPHA / DIGIT / "+" / "/" - - Description: Property values with this value type MUST also include - the inline encoding parameter sequence of ";ENCODING=BASE64". That - is, all inline binary data MUST first be character encoded using the - "BASE64" encoding method defined in [RFC 2045]. No additional content - value encoding (i.e., BACKSLASH character encoding) is defined for - this value type. - - Example: The following is an abridged example of a "BASE64" encoded - binary value data. - - ATTACH;VALUE=BINARY;ENCODING=BASE64:MIICajCCAdOgAwIBAgICBEUwDQY - JKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlI - ENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZv - <...remainder of "BASE64" encoded binary data...> - -4.3.2 Boolean - - Value Name: BOOLEAN - - Purpose: This value type is used to identify properties that contain - either a "TRUE" or "FALSE" Boolean value. - - Formal Definition: The value type is defined by the following - notation: - - - - -Dawson & Stenerson Standards Track [Page 33] - -RFC 2445 iCalendar November 1998 - - - boolean = "TRUE" / "FALSE" - - Description: These values are case insensitive text. No additional - content value encoding (i.e., BACKSLASH character encoding) is - defined for this value type. - - Example: The following is an example of a hypothetical property that - has a BOOLEAN value type: - - GIBBERISH:TRUE - -4.3.3 Calendar User Address - - Value Name: CAL-ADDRESS - - Purpose: This value type is used to identify properties that contain - a calendar user address. - - Formal Definition: The value type is as defined by the following - notation: - - cal-address = uri - - Description: The value is a URI as defined by [RFC 1738] or any other - IANA registered form for a URI. When used to address an Internet - email transport address for a calendar user, the value MUST be a - MAILTO URI, as defined by [RFC 1738]. No additional content value - encoding (i.e., BACKSLASH character encoding) is defined for this - value type. - - Example: - - ATTENDEE:MAILTO:jane_doe@host.com - -4.3.4 Date - - Value Name: DATE - - Purpose: This value type is used to identify values that contain a - calendar date. - - Formal Definition: The value type is defined by the following - notation: - - date = date-value - - date-value = date-fullyear date-month date-mday - date-fullyear = 4DIGIT - - - -Dawson & Stenerson Standards Track [Page 34] - -RFC 2445 iCalendar November 1998 - - - date-month = 2DIGIT ;01-12 - date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31 - ;based on month/year - - Description: If the property permits, multiple "date" values are - specified as a COMMA character (US-ASCII decimal 44) separated list - of values. The format for the value type is expressed as the [ISO - 8601] complete representation, basic format for a calendar date. The - textual format specifies a four-digit year, two-digit month, and - two-digit day of the month. There are no separator characters between - the year, month and day component text. - - No additional content value encoding (i.e., BACKSLASH character - encoding) is defined for this value type. - - Example: The following represents July 14, 1997: - - 19970714 - -4.3.5 Date-Time - - Value Name: DATE-TIME - - Purpose: This value type is used to identify values that specify a - precise calendar date and time of day. - - Formal Definition: The value type is defined by the following - notation: - - date-time = date "T" time ;As specified in the date and time - ;value definitions - - Description: If the property permits, multiple "date-time" values are - specified as a COMMA character (US-ASCII decimal 44) separated list - of values. No additional content value encoding (i.e., BACKSLASH - character encoding) is defined for this value type. - - The "DATE-TIME" data type is used to identify values that contain a - precise calendar date and time of day. The format is based on the - [ISO 8601] complete representation, basic format for a calendar date - and time of day. The text format is a concatenation of the "date", - followed by the LATIN CAPITAL LETTER T character (US-ASCII decimal - 84) time designator, followed by the "time" format. - - The "DATE-TIME" data type expresses time values in three forms: - - The form of date and time with UTC offset MUST NOT be used. For - example, the following is not valid for a date-time value: - - - -Dawson & Stenerson Standards Track [Page 35] - -RFC 2445 iCalendar November 1998 - - - DTSTART:19980119T230000-0800 ;Invalid time format - - FORM #1: DATE WITH LOCAL TIME - - The date with local time form is simply a date-time value that does - not contain the UTC designator nor does it reference a time zone. For - example, the following represents Janurary 18, 1998, at 11 PM: - - DTSTART:19980118T230000 - - Date-time values of this type are said to be "floating" and are not - bound to any time zone in particular. They are used to represent the - same hour, minute, and second value regardless of which time zone is - currently being observed. For example, an event can be defined that - indicates that an individual will be busy from 11:00 AM to 1:00 PM - every day, no matter which time zone the person is in. In these - cases, a local time can be specified. The recipient of an iCalendar - object with a property value consisting of a local time, without any - relative time zone information, SHOULD interpret the value as being - fixed to whatever time zone the ATTENDEE is in at any given moment. - This means that two ATTENDEEs, in different time zones, receiving the - same event definition as a floating time, may be participating in the - event at different actual times. Floating time SHOULD only be used - where that is the reasonable behavior. - - In most cases, a fixed time is desired. To properly communicate a - fixed time in a property value, either UTC time or local time with - time zone reference MUST be specified. - - The use of local time in a DATE-TIME value without the TZID property - parameter is to be interpreted as floating time, regardless of the - existence of "VTIMEZONE" calendar components in the iCalendar object. - - FORM #2: DATE WITH UTC TIME - - The date with UTC time, or absolute time, is identified by a LATIN - CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC - designator, appended to the time value. For example, the following - represents January 19, 1998, at 0700 UTC: - - DTSTART:19980119T070000Z - - The TZID property parameter MUST NOT be applied to DATE-TIME - properties whose time values are specified in UTC. - - FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE - - - - - -Dawson & Stenerson Standards Track [Page 36] - -RFC 2445 iCalendar November 1998 - - - The date and local time with reference to time zone information is - identified by the use the TZID property parameter to reference the - appropriate time zone definition. TZID is discussed in detail in the - section on Time Zone. For example, the following represents 2 AM in - New York on Janurary 19, 1998: - - DTSTART;TZID=US-Eastern:19980119T020000 - - Example: The following represents July 14, 1997, at 1:30 PM in New - York City in each of the three time formats, using the "DTSTART" - property. - - DTSTART:19970714T133000 ;Local time - DTSTART:19970714T173000Z ;UTC time - DTSTART;TZID=US-Eastern:19970714T133000 ;Local time and time - ; zone reference - - A time value MUST ONLY specify 60 seconds when specifying the - periodic "leap second" in the time value. For example: - - COMPLETED:19970630T235960Z - -4.3.6 Duration - - Value Name: DURATION - - Purpose: This value type is used to identify properties that contain - a duration of time. - - Formal Definition: The value type is defined by the following - notation: - - dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) - - dur-date = dur-day [dur-time] - dur-time = "T" (dur-hour / dur-minute / dur-second) - dur-week = 1*DIGIT "W" - dur-hour = 1*DIGIT "H" [dur-minute] - dur-minute = 1*DIGIT "M" [dur-second] - dur-second = 1*DIGIT "S" - dur-day = 1*DIGIT "D" - - Description: If the property permits, multiple "duration" values are - specified by a COMMA character (US-ASCII decimal 44) separated list - of values. The format is expressed as the [ISO 8601] basic format for - the duration of time. The format can represent durations in terms of - weeks, days, hours, minutes, and seconds. - - - - -Dawson & Stenerson Standards Track [Page 37] - -RFC 2445 iCalendar November 1998 - - - No additional content value encoding (i.e., BACKSLASH character - encoding) are defined for this value type. - - Example: A duration of 15 days, 5 hours and 20 seconds would be: - - P15DT5H0M20S - - A duration of 7 weeks would be: - - P7W - -4.3.7 Float - - Value Name: FLOAT - - Purpose: This value type is used to identify properties that contain - a real number value. - - Formal Definition: The value type is defined by the following - notation: - - float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT] - - Description: If the property permits, multiple "float" values are - specified by a COMMA character (US-ASCII decimal 44) separated list - of values. - - No additional content value encoding (i.e., BACKSLASH character - encoding) is defined for this value type. - - Example: - - 1000000.0000001 - 1.333 - -3.14 - -4.3.8 Integer - - Value Name:INTEGER - - Purpose: This value type is used to identify properties that contain - a signed integer value. - - Formal Definition: The value type is defined by the following - notation: - - integer = (["+"] / "-") 1*DIGIT - - - - -Dawson & Stenerson Standards Track [Page 38] - -RFC 2445 iCalendar November 1998 - - - Description: If the property permits, multiple "integer" values are - specified by a COMMA character (US-ASCII decimal 44) separated list - of values. The valid range for "integer" is -2147483648 to - 2147483647. If the sign is not specified, then the value is assumed - to be positive. - - No additional content value encoding (i.e., BACKSLASH character - encoding) is defined for this value type. - - Example: - - 1234567890 - -1234567890 - +1234567890 - 432109876 - -4.3.9 Period of Time - - Value Name: PERIOD - - Purpose: This value type is used to identify values that contain a - precise period of time. - - Formal Definition: The data type is defined by the following - notation: - - period = period-explicit / period-start - - period-explicit = date-time "/" date-time - ; [ISO 8601] complete representation basic format for a period of - ; time consisting of a start and end. The start MUST be before the - ; end. - - period-start = date-time "/" dur-value - ; [ISO 8601] complete representation basic format for a period of - ; time consisting of a start and positive duration of time. - - Description: If the property permits, multiple "period" values are - specified by a COMMA character (US-ASCII decimal 44) separated list - of values. There are two forms of a period of time. First, a period - of time is identified by its start and its end. This format is - expressed as the [ISO 8601] complete representation, basic format for - "DATE-TIME" start of the period, followed by a SOLIDUS character - (US-ASCII decimal 47), followed by the "DATE-TIME" of the end of the - period. The start of the period MUST be before the end of the period. - Second, a period of time can also be defined by a start and a - positive duration of time. The format is expressed as the [ISO 8601] - complete representation, basic format for the "DATE-TIME" start of - - - -Dawson & Stenerson Standards Track [Page 39] - -RFC 2445 iCalendar November 1998 - - - the period, followed by a SOLIDUS character (US-ASCII decimal 47), - followed by the [ISO 8601] basic format for "DURATION" of the period. - - Example: The period starting at 18:00:00 UTC, on January 1, 1997 and - ending at 07:00:00 UTC on January 2, 1997 would be: - - 19970101T180000Z/19970102T070000Z - - The period start at 18:00:00 on January 1, 1997 and lasting 5 hours - and 30 minutes would be: - - 19970101T180000Z/PT5H30M - - No additional content value encoding (i.e., BACKSLASH character - encoding) is defined for this value type. - -4.3.10 Recurrence Rule - - Value Name: RECUR - - Purpose: This value type is used to identify properties that contain - a recurrence rule specification. - - Formal Definition: The value type is defined by the following - notation: - - recur = "FREQ"=freq *( - - ; either UNTIL or COUNT may appear in a 'recur', - ; but UNTIL and COUNT MUST NOT occur in the same 'recur' - - ( ";" "UNTIL" "=" enddate ) / - ( ";" "COUNT" "=" 1*DIGIT ) / - - ; the rest of these keywords are optional, - ; but MUST NOT occur more than once - - ( ";" "INTERVAL" "=" 1*DIGIT ) / - ( ";" "BYSECOND" "=" byseclist ) / - ( ";" "BYMINUTE" "=" byminlist ) / - ( ";" "BYHOUR" "=" byhrlist ) / - ( ";" "BYDAY" "=" bywdaylist ) / - ( ";" "BYMONTHDAY" "=" bymodaylist ) / - ( ";" "BYYEARDAY" "=" byyrdaylist ) / - ( ";" "BYWEEKNO" "=" bywknolist ) / - ( ";" "BYMONTH" "=" bymolist ) / - ( ";" "BYSETPOS" "=" bysplist ) / - ( ";" "WKST" "=" weekday ) / - - - -Dawson & Stenerson Standards Track [Page 40] - -RFC 2445 iCalendar November 1998 - - - ( ";" x-name "=" text ) - ) - - freq = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY" - / "WEEKLY" / "MONTHLY" / "YEARLY" - - enddate = date - enddate =/ date-time ;An UTC value - - byseclist = seconds / ( seconds *("," seconds) ) - - seconds = 1DIGIT / 2DIGIT ;0 to 59 - - byminlist = minutes / ( minutes *("," minutes) ) - - minutes = 1DIGIT / 2DIGIT ;0 to 59 - - byhrlist = hour / ( hour *("," hour) ) - - hour = 1DIGIT / 2DIGIT ;0 to 23 - - bywdaylist = weekdaynum / ( weekdaynum *("," weekdaynum) ) - - weekdaynum = [([plus] ordwk / minus ordwk)] weekday - - plus = "+" - - minus = "-" - - ordwk = 1DIGIT / 2DIGIT ;1 to 53 - - weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" - ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, - ;FRIDAY, SATURDAY and SUNDAY days of the week. - - bymodaylist = monthdaynum / ( monthdaynum *("," monthdaynum) ) - - monthdaynum = ([plus] ordmoday) / (minus ordmoday) - - ordmoday = 1DIGIT / 2DIGIT ;1 to 31 - - byyrdaylist = yeardaynum / ( yeardaynum *("," yeardaynum) ) - - yeardaynum = ([plus] ordyrday) / (minus ordyrday) - - ordyrday = 1DIGIT / 2DIGIT / 3DIGIT ;1 to 366 - - bywknolist = weeknum / ( weeknum *("," weeknum) ) - - - -Dawson & Stenerson Standards Track [Page 41] - -RFC 2445 iCalendar November 1998 - - - weeknum = ([plus] ordwk) / (minus ordwk) - - bymolist = monthnum / ( monthnum *("," monthnum) ) - - monthnum = 1DIGIT / 2DIGIT ;1 to 12 - - bysplist = setposday / ( setposday *("," setposday) ) - - setposday = yeardaynum - - Description: If the property permits, multiple "recur" values are - specified by a COMMA character (US-ASCII decimal 44) separated list - of values. The value type is a structured value consisting of a list - of one or more recurrence grammar parts. Each rule part is defined by - a NAME=VALUE pair. The rule parts are separated from each other by - the SEMICOLON character (US-ASCII decimal 59). The rule parts are not - ordered in any particular sequence. Individual rule parts MUST only - be specified once. - - The FREQ rule part identifies the type of recurrence rule. This rule - part MUST be specified in the recurrence rule. Valid values include - SECONDLY, to specify repeating events based on an interval of a - second or more; MINUTELY, to specify repeating events based on an - interval of a minute or more; HOURLY, to specify repeating events - based on an interval of an hour or more; DAILY, to specify repeating - events based on an interval of a day or more; WEEKLY, to specify - repeating events based on an interval of a week or more; MONTHLY, to - specify repeating events based on an interval of a month or more; and - YEARLY, to specify repeating events based on an interval of a year or - more. - - The INTERVAL rule part contains a positive integer representing how - often the recurrence rule repeats. The default value is "1", meaning - every second for a SECONDLY rule, or every minute for a MINUTELY - rule, every hour for an HOURLY rule, every day for a DAILY rule, - every week for a WEEKLY rule, every month for a MONTHLY rule and - every year for a YEARLY rule. - - The UNTIL rule part defines a date-time value which bounds the - recurrence rule in an inclusive manner. If the value specified by - UNTIL is synchronized with the specified recurrence, this date or - date-time becomes the last instance of the recurrence. If specified - as a date-time value, then it MUST be specified in an UTC time - format. If not present, and the COUNT rule part is also not present, - the RRULE is considered to repeat forever. - - The COUNT rule part defines the number of occurrences at which to - range-bound the recurrence. The "DTSTART" property value, if - - - -Dawson & Stenerson Standards Track [Page 42] - -RFC 2445 iCalendar November 1998 - - - specified, counts as the first occurrence. - - The BYSECOND rule part specifies a COMMA character (US-ASCII decimal - 44) separated list of seconds within a minute. Valid values are 0 to - 59. The BYMINUTE rule part specifies a COMMA character (US-ASCII - decimal 44) separated list of minutes within an hour. Valid values - are 0 to 59. The BYHOUR rule part specifies a COMMA character (US- - ASCII decimal 44) separated list of hours of the day. Valid values - are 0 to 23. - - The BYDAY rule part specifies a COMMA character (US-ASCII decimal 44) - separated list of days of the week; MO indicates Monday; TU indicates - Tuesday; WE indicates Wednesday; TH indicates Thursday; FR indicates - Friday; SA indicates Saturday; SU indicates Sunday. - - Each BYDAY value can also be preceded by a positive (+n) or negative - (-n) integer. If present, this indicates the nth occurrence of the - specific day within the MONTHLY or YEARLY RRULE. For example, within - a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday - within the month, whereas -1MO represents the last Monday of the - month. If an integer modifier is not present, it means all days of - this type within the specified frequency. For example, within a - MONTHLY rule, MO represents all Mondays within the month. - - The BYMONTHDAY rule part specifies a COMMA character (ASCII decimal - 44) separated list of days of the month. Valid values are 1 to 31 or - -31 to -1. For example, -10 represents the tenth to the last day of - the month. - - The BYYEARDAY rule part specifies a COMMA character (US-ASCII decimal - 44) separated list of days of the year. Valid values are 1 to 366 or - -366 to -1. For example, -1 represents the last day of the year - (December 31st) and -306 represents the 306th to the last day of the - year (March 1st). - - The BYWEEKNO rule part specifies a COMMA character (US-ASCII decimal - 44) separated list of ordinals specifying weeks of the year. Valid - values are 1 to 53 or -53 to -1. This corresponds to weeks according - to week numbering as defined in [ISO 8601]. A week is defined as a - seven day period, starting on the day of the week defined to be the - week start (see WKST). Week number one of the calendar year is the - first week which contains at least four (4) days in that calendar - year. This rule part is only valid for YEARLY rules. For example, 3 - represents the third week of the year. - - Note: Assuming a Monday week start, week 53 can only occur when - Thursday is January 1 or if it is a leap year and Wednesday is - January 1. - - - -Dawson & Stenerson Standards Track [Page 43] - -RFC 2445 iCalendar November 1998 - - - The BYMONTH rule part specifies a COMMA character (US-ASCII decimal - 44) separated list of months of the year. Valid values are 1 to 12. - - The WKST rule part specifies the day on which the workweek starts. - Valid values are MO, TU, WE, TH, FR, SA and SU. This is significant - when a WEEKLY RRULE has an interval greater than 1, and a BYDAY rule - part is specified. This is also significant when in a YEARLY RRULE - when a BYWEEKNO rule part is specified. The default value is MO. - - The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal - 44) separated list of values which corresponds to the nth occurrence - within the set of events specified by the rule. Valid values are 1 to - 366 or -366 to -1. It MUST only be used in conjunction with another - BYxxx rule part. For example "the last work day of the month" could - be represented as: - - RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 - - Each BYSETPOS value can include a positive (+n) or negative (-n) - integer. If present, this indicates the nth occurrence of the - specific occurrence within the set of events specified by the rule. - - If BYxxx rule part values are found which are beyond the available - scope (ie, BYMONTHDAY=30 in February), they are simply ignored. - - Information, not contained in the rule, necessary to determine the - various recurrence instance start time and dates are derived from the - Start Time (DTSTART) entry attribute. For example, - "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the - month or a time. This information would be the same as what is - specified for DTSTART. - - BYxxx rule parts modify the recurrence in some manner. BYxxx rule - parts for a period of time which is the same or greater than the - frequency generally reduce or limit the number of occurrences of the - recurrence generated. For example, "FREQ=DAILY;BYMONTH=1" reduces the - number of recurrence instances from all days (if BYMONTH tag is not - present) to all days in January. BYxxx rule parts for a period of - time less than the frequency generally increase or expand the number - of occurrences of the recurrence. For example, - "FREQ=YEARLY;BYMONTH=1,2" increases the number of days within the - yearly recurrence set from 1 (if BYMONTH tag is not present) to 2. - - If multiple BYxxx rule parts are specified, then after evaluating the - specified FREQ and INTERVAL rule parts, the BYxxx rule parts are - applied to the current set of evaluated occurrences in the following - order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR, - BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are evaluated. - - - -Dawson & Stenerson Standards Track [Page 44] - -RFC 2445 iCalendar November 1998 - - - Here is an example of evaluating multiple BYxxx rule parts. - - DTSTART;TZID=US-Eastern:19970105T083000 - RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9; - BYMINUTE=30 - - First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to arrive - at "every other year". Then, "BYMONTH=1" would be applied to arrive - at "every January, every other year". Then, "BYDAY=SU" would be - applied to arrive at "every Sunday in January, every other year". - Then, "BYHOUR=8,9" would be applied to arrive at "every Sunday in - January at 8 AM and 9 AM, every other year". Then, "BYMINUTE=30" - would be applied to arrive at "every Sunday in January at 8:30 AM and - 9:30 AM, every other year". Then, lacking information from RRULE, the - second is derived from DTSTART, to end up in "every Sunday in January - at 8:30:00 AM and 9:30:00 AM, every other year". Similarly, if the - BYMINUTE, BYHOUR, BYDAY, BYMONTHDAY or BYMONTH rule part were - missing, the appropriate minute, hour, day or month would have been - retrieved from the "DTSTART" property. - - No additional content value encoding (i.e., BACKSLASH character - encoding) is defined for this value type. - - Example: The following is a rule which specifies 10 meetings which - occur every other day: - - FREQ=DAILY;COUNT=10;INTERVAL=2 - - There are other examples specified in the "RRULE" specification. - -4.3.11 Text - - Value Name: TEXT - - Purpose This value type is used to identify values that contain human - readable text. - - Formal Definition: The character sets supported by this revision of - iCalendar are UTF-8 and US ASCII thereof. The applicability to other - character sets is for future work. The value type is defined by the - following notation. - - text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) - ; Folded according to description above - - ESCAPED-CHAR = "\\" / "\;" / "\," / "\N" / "\n") - ; \\ encodes \, \N or \n encodes newline - ; \; encodes ;, \, encodes , - - - -Dawson & Stenerson Standards Track [Page 45] - -RFC 2445 iCalendar November 1998 - - - TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B - %x5D-7E / NON-US-ASCII - ; Any character except CTLs not needed by the current - ; character set, DQUOTE, ";", ":", "\", "," - - Note: Certain other character sets may require modification of the - above definitions, but this is beyond the scope of this document. - - Description: If the property permits, multiple "text" values are - specified by a COMMA character (US-ASCII decimal 44) separated list - of values. - - The language in which the text is represented can be controlled by - the "LANGUAGE" property parameter. - - An intentional formatted text line break MUST only be included in a - "TEXT" property value by representing the line break with the - character sequence of BACKSLASH (US-ASCII decimal 92), followed by a - LATIN SMALL LETTER N (US-ASCII decimal 110) or a LATIN CAPITAL LETTER - N (US-ASCII decimal 78), that is "\n" or "\N". - - The "TEXT" property values may also contain special characters that - are used to signify delimiters, such as a COMMA character for lists - of values or a SEMICOLON character for structured values. In order to - support the inclusion of these special characters in "TEXT" property - values, they MUST be escaped with a BACKSLASH character. A BACKSLASH - character (US-ASCII decimal 92) in a "TEXT" property value MUST be - escaped with another BACKSLASH character. A COMMA character in a - "TEXT" property value MUST be escaped with a BACKSLASH character - (US-ASCII decimal 92). A SEMICOLON character in a "TEXT" property - value MUST be escaped with a BACKSLASH character (US-ASCII decimal - 92). However, a COLON character in a "TEXT" property value SHALL NOT - be escaped with a BACKSLASH character.Example: A multiple line value - of: - - Project XYZ Final Review - Conference Room - 3B - Come Prepared. - - would be represented as: - - Project XYZ Final Review\nConference Room - 3B\nCome Prepared. - - - - - - - - - -Dawson & Stenerson Standards Track [Page 46] - -RFC 2445 iCalendar November 1998 - - -4.3.12 Time - - Value Name: TIME - - Purpose: This value type is used to identify values that contain a - time of day. - - Formal Definition: The data type is defined by the following - notation: - - time = time-hour time-minute time-second [time-utc] - - time-hour = 2DIGIT ;00-23 - time-minute = 2DIGIT ;00-59 - time-second = 2DIGIT ;00-60 - ;The "60" value is used to account for "leap" seconds. - - time-utc = "Z" - - Description: If the property permits, multiple "time" values are - specified by a COMMA character (US-ASCII decimal 44) separated list - of values. No additional content value encoding (i.e., BACKSLASH - character encoding) is defined for this value type. - - The "TIME" data type is used to identify values that contain a time - of day. The format is based on the [ISO 8601] complete - representation, basic format for a time of day. The text format - consists of a two-digit 24-hour of the day (i.e., values 0-23), two- - digit minute in the hour (i.e., values 0-59), and two-digit seconds - in the minute (i.e., values 0-60). The seconds value of 60 MUST only - to be used to account for "leap" seconds. Fractions of a second are - not supported by this format. - - In parallel to the "DATE-TIME" definition above, the "TIME" data type - expresses time values in three forms: - - The form of time with UTC offset MUST NOT be used. For example, the - following is NOT VALID for a time value: - - 230000-0800 ;Invalid time format - - FORM #1 LOCAL TIME - - The local time form is simply a time value that does not contain the - UTC designator nor does it reference a time zone. For example, 11:00 - PM: - - 230000 - - - -Dawson & Stenerson Standards Track [Page 47] - -RFC 2445 iCalendar November 1998 - - - Time values of this type are said to be "floating" and are not bound - to any time zone in particular. They are used to represent the same - hour, minute, and second value regardless of which time zone is - currently being observed. For example, an event can be defined that - indicates that an individual will be busy from 11:00 AM to 1:00 PM - every day, no matter which time zone the person is in. In these - cases, a local time can be specified. The recipient of an iCalendar - object with a property value consisting of a local time, without any - relative time zone information, SHOULD interpret the value as being - fixed to whatever time zone the ATTENDEE is in at any given moment. - This means that two ATTENDEEs may participate in the same event at - different UTC times; floating time SHOULD only be used where that is - reasonable behavior. - - In most cases, a fixed time is desired. To properly communicate a - fixed time in a property value, either UTC time or local time with - time zone reference MUST be specified. - - The use of local time in a TIME value without the TZID property - parameter is to be interpreted as a local time value, regardless of - the existence of "VTIMEZONE" calendar components in the iCalendar - object. - - FORM #2: UTC TIME - - UTC time, or absolute time, is identified by a LATIN CAPITAL LETTER Z - suffix character (US-ASCII decimal 90), the UTC designator, appended - to the time value. For example, the following represents 07:00 AM - UTC: - - 070000Z - - The TZID property parameter MUST NOT be applied to TIME properties - whose time values are specified in UTC. - - FORM #3: LOCAL TIME AND TIME ZONE REFERENCE - - The local time with reference to time zone information form is - identified by the use the TZID property parameter to reference the - appropriate time zone definition. TZID is discussed in detail in the - section on Time Zone. - - Example: The following represents 8:30 AM in New York in Winter, five - hours behind UTC, in each of the three formats using the "X- - TIMEOFDAY" non-standard property: - - - - - - -Dawson & Stenerson Standards Track [Page 48] - -RFC 2445 iCalendar November 1998 - - - X-TIMEOFDAY:083000 - - X-TIMEOFDAY:133000Z - - X-TIMEOFDAY;TZID=US-Eastern:083000 - -4.3.13 URI - - Value Name: URI - - Purpose: This value type is used to identify values that contain a - uniform resource identifier (URI) type of reference to the property - value. - - Formal Definition: The data type is defined by the following - notation: - - uri = - - Description: This data type might be used to reference binary - information, for values that are large, or otherwise undesirable to - include directly in the iCalendar object. - - The URI value formats in RFC 1738, RFC 2111 and any other IETF - registered value format can be specified. - - Any IANA registered URI format can be used. These include, but are - not limited to, those defined in RFC 1738 and RFC 2111. - - When a property parameter value is a URI value type, the URI MUST be - specified as a quoted-string value. - - No additional content value encoding (i.e., BACKSLASH character - encoding) is defined for this value type. - - Example: The following is a URI for a network file: - - http://host1.com/my-report.txt - -4.3.14 UTC Offset - - Value Name: UTC-OFFSET - - Purpose: This value type is used to identify properties that contain - an offset from UTC to local time. - - Formal Definition: The data type is defined by the following - notation: - - - -Dawson & Stenerson Standards Track [Page 49] - -RFC 2445 iCalendar November 1998 - - - utc-offset = time-numzone ;As defined above in time data type - - time-numzone = ("+" / "-") time-hour time-minute [time- - second] - - Description: The PLUS SIGN character MUST be specified for positive - UTC offsets (i.e., ahead of UTC). The value of "-0000" and "-000000" - are not allowed. The time-second, if present, may not be 60; if - absent, it defaults to zero. - - No additional content value encoding (i.e., BACKSLASH character - encoding) is defined for this value type. - - Example: The following UTC offsets are given for standard time for - New York (five hours behind UTC) and Geneva (one hour ahead of UTC): - - -0500 - - +0100 - -4.4 iCalendar Object - - The Calendaring and Scheduling Core Object is a collection of - calendaring and scheduling information. Typically, this information - will consist of a single iCalendar object. However, multiple - iCalendar objects can be sequentially grouped together. The first - line and last line of the iCalendar object MUST contain a pair of - iCalendar object delimiter strings. The syntax for an iCalendar - object is as follows: - - icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF - icalbody - "END" ":" "VCALENDAR" CRLF) - - The following is a simple example of an iCalendar object: - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//hacksw/handcal//NONSGML v1.0//EN - BEGIN:VEVENT - DTSTART:19970714T170000Z - DTEND:19970715T035959Z - SUMMARY:Bastille Day Party - END:VEVENT - END:VCALENDAR - - - - - - -Dawson & Stenerson Standards Track [Page 50] - -RFC 2445 iCalendar November 1998 - - -4.5 Property - - A property is the definition of an individual attribute describing a - calendar or a calendar component. A property takes the form defined - by the "contentline" notation defined in section 4.1.1. - - The following is an example of a property: - - DTSTART:19960415T133000Z - - This memo imposes no ordering of properties within an iCalendar - object. - - Property names, parameter names and enumerated parameter values are - case insensitive. For example, the property name "DUE" is the same as - "due" and "Due", DTSTART;TZID=US-Eastern:19980714T120000 is the same - as DtStart;TzID=US-Eastern:19980714T120000. - -4.6 Calendar Components - - The body of the iCalendar object consists of a sequence of calendar - properties and one or more calendar components. The calendar - properties are attributes that apply to the calendar as a whole. The - calendar components are collections of properties that express a - particular calendar semantic. For example, the calendar component can - specify an event, a to-do, a journal entry, time zone information, or - free/busy time information, or an alarm. - - The body of the iCalendar object is defined by the following - notation: - - icalbody = calprops component - - calprops = 2*( - - ; 'prodid' and 'version' are both REQUIRED, - ; but MUST NOT occur more than once - - prodid /version / - - ; 'calscale' and 'method' are optional, - ; but MUST NOT occur more than once - - calscale / - method / - - x-prop - - - - -Dawson & Stenerson Standards Track [Page 51] - -RFC 2445 iCalendar November 1998 - - - ) - - component = 1*(eventc / todoc / journalc / freebusyc / - / timezonec / iana-comp / x-comp) - - iana-comp = "BEGIN" ":" iana-token CRLF - - 1*contentline - - "END" ":" iana-token CRLF - - x-comp = "BEGIN" ":" x-name CRLF - - 1*contentline - - "END" ":" x-name CRLF - - An iCalendar object MUST include the "PRODID" and "VERSION" calendar - properties. In addition, it MUST include at least one calendar - component. Special forms of iCalendar objects are possible to publish - just busy time (i.e., only a "VFREEBUSY" calendar component) or time - zone (i.e., only a "VTIMEZONE" calendar component) information. In - addition, a complex iCalendar object is possible that is used to - capture a complete snapshot of the contents of a calendar (e.g., - composite of many different calendar components). More commonly, an - iCalendar object will consist of just a single "VEVENT", "VTODO" or - "VJOURNAL" calendar component. - -4.6.1 Event Component - - Component Name: "VEVENT" - - Purpose: Provide a grouping of component properties that describe an - event. - - Format Definition: A "VEVENT" calendar component is defined by the - following notation: - - eventc = "BEGIN" ":" "VEVENT" CRLF - eventprop *alarmc - "END" ":" "VEVENT" CRLF - - eventprop = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - class / created / description / dtstart / geo / - - - -Dawson & Stenerson Standards Track [Page 52] - -RFC 2445 iCalendar November 1998 - - - last-mod / location / organizer / priority / - dtstamp / seq / status / summary / transp / - uid / url / recurid / - - ; either 'dtend' or 'duration' may appear in - ; a 'eventprop', but 'dtend' and 'duration' - ; MUST NOT occur in the same 'eventprop' - - dtend / duration / - - ; the following are optional, - ; and MAY occur more than once - - attach / attendee / categories / comment / - contact / exdate / exrule / rstatus / related / - resources / rdate / rrule / x-prop - - ) - - Description: A "VEVENT" calendar component is a grouping of component - properties, and possibly including "VALARM" calendar components, that - represents a scheduled amount of time on a calendar. For example, it - can be an activity; such as a one-hour long, department meeting from - 8:00 AM to 9:00 AM, tomorrow. Generally, an event will take up time - on an individual calendar. Hence, the event will appear as an opaque - interval in a search for busy time. Alternately, the event can have - its Time Transparency set to "TRANSPARENT" in order to prevent - blocking of the event in searches for busy time. - - The "VEVENT" is also the calendar component used to specify an - anniversary or daily reminder within a calendar. These events have a - DATE value type for the "DTSTART" property instead of the default - data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it - MUST be specified as a DATE value also. The anniversary type of - "VEVENT" can span more than one date (i.e, "DTEND" property value is - set to a calendar date after the "DTSTART" property value). - - The "DTSTART" property for a "VEVENT" specifies the inclusive start - of the event. For recurring events, it also specifies the very first - instance in the recurrence set. The "DTEND" property for a "VEVENT" - calendar component specifies the non-inclusive end of the event. For - cases where a "VEVENT" calendar component specifies a "DTSTART" - property with a DATE data type but no "DTEND" property, the events - non-inclusive end is the end of the calendar date specified by the - "DTSTART" property. For cases where a "VEVENT" calendar component - specifies a "DTSTART" property with a DATE-TIME data type but no - "DTEND" property, the event ends on the same calendar date and time - of day specified by the "DTSTART" property. - - - -Dawson & Stenerson Standards Track [Page 53] - -RFC 2445 iCalendar November 1998 - - - The "VEVENT" calendar component cannot be nested within another - calendar component. However, "VEVENT" calendar components can be - related to each other or to a "VTODO" or to a "VJOURNAL" calendar - component with the "RELATED-TO" property. - - Example: The following is an example of the "VEVENT" calendar - component used to represent a meeting that will also be opaque to - searches for busy time: - - BEGIN:VEVENT - UID:19970901T130000Z-123401@host.com - DTSTAMP:19970901T1300Z - DTSTART:19970903T163000Z - DTEND:19970903T190000Z - SUMMARY:Annual Employee Review - CLASS:PRIVATE - CATEGORIES:BUSINESS,HUMAN RESOURCES - END:VEVENT - - The following is an example of the "VEVENT" calendar component used - to represent a reminder that will not be opaque, but rather - transparent, to searches for busy time: - - BEGIN:VEVENT - UID:19970901T130000Z-123402@host.com - DTSTAMP:19970901T1300Z - DTSTART:19970401T163000Z - DTEND:19970402T010000Z - SUMMARY:Laurel is in sensitivity awareness class. - CLASS:PUBLIC - CATEGORIES:BUSINESS,HUMAN RESOURCES - TRANSP:TRANSPARENT - END:VEVENT - - The following is an example of the "VEVENT" calendar component used - to represent an anniversary that will occur annually. Since it takes - up no time, it will not appear as opaque in a search for busy time; - no matter what the value of the "TRANSP" property indicates: - - BEGIN:VEVENT - UID:19970901T130000Z-123403@host.com - DTSTAMP:19970901T1300Z - DTSTART:19971102 - SUMMARY:Our Blissful Anniversary - CLASS:CONFIDENTIAL - CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION - RRULE:FREQ=YEARLY - END:VEVENT - - - -Dawson & Stenerson Standards Track [Page 54] - -RFC 2445 iCalendar November 1998 - - -4.6.2 To-do Component - - Component Name: VTODO - - Purpose: Provide a grouping of calendar properties that describe a - to-do. - - Formal Definition: A "VTODO" calendar component is defined by the - following notation: - - todoc = "BEGIN" ":" "VTODO" CRLF - todoprop *alarmc - "END" ":" "VTODO" CRLF - - todoprop = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - class / completed / created / description / dtstamp / - dtstart / geo / last-mod / location / organizer / - percent / priority / recurid / seq / status / - summary / uid / url / - - ; either 'due' or 'duration' may appear in - ; a 'todoprop', but 'due' and 'duration' - ; MUST NOT occur in the same 'todoprop' - - due / duration / - - ; the following are optional, - ; and MAY occur more than once - attach / attendee / categories / comment / contact / - exdate / exrule / rstatus / related / resources / - rdate / rrule / x-prop - - ) - - Description: A "VTODO" calendar component is a grouping of component - properties and possibly "VALARM" calendar components that represent - an action-item or assignment. For example, it can be used to - represent an item of work assigned to an individual; such as "turn in - travel expense today". - - The "VTODO" calendar component cannot be nested within another - calendar component. However, "VTODO" calendar components can be - related to each other or to a "VTODO" or to a "VJOURNAL" calendar - component with the "RELATED-TO" property. - - - -Dawson & Stenerson Standards Track [Page 55] - -RFC 2445 iCalendar November 1998 - - - A "VTODO" calendar component without the "DTSTART" and "DUE" (or - "DURATION") properties specifies a to-do that will be associated with - each successive calendar date, until it is completed. - - Example: The following is an example of a "VTODO" calendar component: - - BEGIN:VTODO - UID:19970901T130000Z-123404@host.com - DTSTAMP:19970901T1300Z - DTSTART:19970415T133000Z - DUE:19970416T045959Z - SUMMARY:1996 Income Tax Preparation - CLASS:CONFIDENTIAL - CATEGORIES:FAMILY,FINANCE - PRIORITY:1 - STATUS:NEEDS-ACTION - END:VTODO - -4.6.3 Journal Component - - Component Name: VJOURNAL - - Purpose: Provide a grouping of component properties that describe a - journal entry. - - Formal Definition: A "VJOURNAL" calendar component is defined by the - following notation: - - journalc = "BEGIN" ":" "VJOURNAL" CRLF - jourprop - "END" ":" "VJOURNAL" CRLF - - jourprop = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - class / created / description / dtstart / dtstamp / - last-mod / organizer / recurid / seq / status / - summary / uid / url / - - ; the following are optional, - ; and MAY occur more than once - - attach / attendee / categories / comment / - contact / exdate / exrule / related / rdate / - rrule / rstatus / x-prop - - - - -Dawson & Stenerson Standards Track [Page 56] - -RFC 2445 iCalendar November 1998 - - - ) - - Description: A "VJOURNAL" calendar component is a grouping of - component properties that represent one or more descriptive text - notes associated with a particular calendar date. The "DTSTART" - property is used to specify the calendar date that the journal entry - is associated with. Generally, it will have a DATE value data type, - but it can also be used to specify a DATE-TIME value data type. - Examples of a journal entry include a daily record of a legislative - body or a journal entry of individual telephone contacts for the day - or an ordered list of accomplishments for the day. The "VJOURNAL" - calendar component can also be used to associate a document with a - calendar date. - - The "VJOURNAL" calendar component does not take up time on a - calendar. Hence, it does not play a role in free or busy time - searches - - it is as though it has a time transparency value of - TRANSPARENT. It is transparent to any such searches. - - The "VJOURNAL" calendar component cannot be nested within another - calendar component. However, "VJOURNAL" calendar components can be - related to each other or to a "VEVENT" or to a "VTODO" calendar - component, with the "RELATED-TO" property. - - Example: The following is an example of the "VJOURNAL" calendar - component: - - BEGIN:VJOURNAL - UID:19970901T130000Z-123405@host.com - DTSTAMP:19970901T1300Z - DTSTART;VALUE=DATE:19970317 - SUMMARY:Staff meeting minutes - DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa - and Bob. Aurora project plans were reviewed. There is currently - no budget reserves for this project. Lisa will escalate to - management. Next meeting on Tuesday.\n - 2. Telephone Conference: ABC Corp. sales representative called - to discuss new printer. Promised to get us a demo by Friday.\n - 3. Henry Miller (Handsoff Insurance): Car was totaled by tree. - Is looking into a loaner car. 654-2323 (tel). - END:VJOURNAL - - - - - - - - - - -Dawson & Stenerson Standards Track [Page 57] - -RFC 2445 iCalendar November 1998 - - -4.6.4 Free/Busy Component - - Component Name: VFREEBUSY - - Purpose: Provide a grouping of component properties that describe - either a request for free/busy time, describe a response to a request - for free/busy time or describe a published set of busy time. - - Formal Definition: A "VFREEBUSY" calendar component is defined by the - following notation: - - freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF - fbprop - "END" ":" "VFREEBUSY" CRLF - - fbprop = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - contact / dtstart / dtend / duration / dtstamp / - organizer / uid / url / - - ; the following are optional, - ; and MAY occur more than once - - attendee / comment / freebusy / rstatus / x-prop - - ) - - Description: A "VFREEBUSY" calendar component is a grouping of - component properties that represents either a request for, a reply to - a request for free or busy time information or a published set of - busy time information. - - When used to request free/busy time information, the "ATTENDEE" - property specifies the calendar users whose free/busy time is being - requested; the "ORGANIZER" property specifies the calendar user who - is requesting the free/busy time; the "DTSTART" and "DTEND" - properties specify the window of time for which the free/busy time is - being requested; the "UID" and "DTSTAMP" properties are specified to - assist in proper sequencing of multiple free/busy time requests. - - When used to reply to a request for free/busy time, the "ATTENDEE" - property specifies the calendar user responding to the free/busy time - request; the "ORGANIZER" property specifies the calendar user that - originally requested the free/busy time; the "FREEBUSY" property - specifies the free/busy time information (if it exists); and the - - - -Dawson & Stenerson Standards Track [Page 58] - -RFC 2445 iCalendar November 1998 - - - "UID" and "DTSTAMP" properties are specified to assist in proper - sequencing of multiple free/busy time replies. - - When used to publish busy time, the "ORGANIZER" property specifies - the calendar user associated with the published busy time; the - "DTSTART" and "DTEND" properties specify an inclusive time window - that surrounds the busy time information; the "FREEBUSY" property - specifies the published busy time information; and the "DTSTAMP" - property specifies the date/time that iCalendar object was created. - - The "VFREEBUSY" calendar component cannot be nested within another - calendar component. Multiple "VFREEBUSY" calendar components can be - specified within an iCalendar object. This permits the grouping of - Free/Busy information into logical collections, such as monthly - groups of busy time information. - - The "VFREEBUSY" calendar component is intended for use in iCalendar - object methods involving requests for free time, requests for busy - time, requests for both free and busy, and the associated replies. - - Free/Busy information is represented with the "FREEBUSY" property. - This property provides a terse representation of time periods. One or - more "FREEBUSY" properties can be specified in the "VFREEBUSY" - calendar component. - - When present in a "VFREEBUSY" calendar component, the "DTSTART" and - "DTEND" properties SHOULD be specified prior to any "FREEBUSY" - properties. In a free time request, these properties can be used in - combination with the "DURATION" property to represent a request for a - duration of free time within a specified window of time. - - The recurrence properties ("RRULE", "EXRULE", "RDATE", "EXDATE") are - not permitted within a "VFREEBUSY" calendar component. Any recurring - events are resolved into their individual busy time periods using the - "FREEBUSY" property. - - Example: The following is an example of a "VFREEBUSY" calendar - component used to request free or busy time information: - - BEGIN:VFREEBUSY - ORGANIZER:MAILTO:jane_doe@host1.com - ATTENDEE:MAILTO:john_public@host2.com - DTSTART:19971015T050000Z - DTEND:19971016T050000Z - DTSTAMP:19970901T083000Z - END:VFREEBUSY - - - - - -Dawson & Stenerson Standards Track [Page 59] - -RFC 2445 iCalendar November 1998 - - - The following is an example of a "VFREEBUSY" calendar component used - to reply to the request with busy time information: - - BEGIN:VFREEBUSY - ORGANIZER:MAILTO:jane_doe@host1.com - ATTENDEE:MAILTO:john_public@host2.com - DTSTAMP:19970901T100000Z - FREEBUSY;VALUE=PERIOD:19971015T050000Z/PT8H30M, - 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M - URL:http://host2.com/pub/busy/jpublic-01.ifb - COMMENT:This iCalendar file contains busy time information for - the next three months. - END:VFREEBUSY - - The following is an example of a "VFREEBUSY" calendar component used - to publish busy time information. - - BEGIN:VFREEBUSY - ORGANIZER:jsmith@host.com - DTSTART:19980313T141711Z - DTEND:19980410T141711Z - FREEBUSY:19980314T233000Z/19980315T003000Z - FREEBUSY:19980316T153000Z/19980316T163000Z - FREEBUSY:19980318T030000Z/19980318T040000Z - URL:http://www.host.com/calendar/busytime/jsmith.ifb - END:VFREEBUSY - -4.6.5 Time Zone Component - - Component Name: VTIMEZONE - - Purpose: Provide a grouping of component properties that defines a - time zone. - - Formal Definition: A "VTIMEZONE" calendar component is defined by the - following notation: - - timezonec = "BEGIN" ":" "VTIMEZONE" CRLF - - 2*( - - ; 'tzid' is required, but MUST NOT occur more - ; than once - - tzid / - - ; 'last-mod' and 'tzurl' are optional, - but MUST NOT occur more than once - - - -Dawson & Stenerson Standards Track [Page 60] - -RFC 2445 iCalendar November 1998 - - - last-mod / tzurl / - - ; one of 'standardc' or 'daylightc' MUST occur - ..; and each MAY occur more than once. - - standardc / daylightc / - - ; the following is optional, - ; and MAY occur more than once - - x-prop - - ) - - "END" ":" "VTIMEZONE" CRLF - - standardc = "BEGIN" ":" "STANDARD" CRLF - - tzprop - - "END" ":" "STANDARD" CRLF - - daylightc = "BEGIN" ":" "DAYLIGHT" CRLF - - tzprop - - "END" ":" "DAYLIGHT" CRLF - - tzprop = 3*( - - ; the following are each REQUIRED, - ; but MUST NOT occur more than once - - dtstart / tzoffsetto / tzoffsetfrom / - - ; the following are optional, - ; and MAY occur more than once - - comment / rdate / rrule / tzname / x-prop - - ) - - Description: A time zone is unambiguously defined by the set of time - measurement rules determined by the governing body for a given - geographic area. These rules describe at a minimum the base offset - from UTC for the time zone, often referred to as the Standard Time - offset. Many locations adjust their Standard Time forward or backward - by one hour, in order to accommodate seasonal changes in number of - - - -Dawson & Stenerson Standards Track [Page 61] - -RFC 2445 iCalendar November 1998 - - - daylight hours, often referred to as Daylight Saving Time. Some - locations adjust their time by a fraction of an hour. Standard Time - is also known as Winter Time. Daylight Saving Time is also known as - Advanced Time, Summer Time, or Legal Time in certain countries. The - following table shows the changes in time zone rules in effect for - New York City starting from 1967. Each line represents a description - or rule for a particular observance. - - Effective Observance Rule - - Date (Date/Time) Offset Abbreviation - - 1967-* last Sun in Oct, 02:00 -0500 EST - - 1967-1973 last Sun in Apr, 02:00 -0400 EDT - - 1974-1974 Jan 6, 02:00 -0400 EDT - - 1975-1975 Feb 23, 02:00 -0400 EDT - - 1976-1986 last Sun in Apr, 02:00 -0400 EDT - - 1987-* first Sun in Apr, 02:00 -0400 EDT - - Note: The specification of a global time zone registry is not - addressed by this document and is left for future study. - However, implementers may find the Olson time zone database [TZ] - a useful reference. It is an informal, public-domain collection - of time zone information, which is currently being maintained by - volunteer Internet participants, and is used in several - operating systems. This database contains current and historical - time zone information for a wide variety of locations around the - globe; it provides a time zone identifier for every unique time - zone rule set in actual use since 1970, with historical data - going back to the introduction of standard time. - - Interoperability between two calendaring and scheduling applications, - especially for recurring events, to-dos or journal entries, is - dependent on the ability to capture and convey date and time - information in an unambiguous format. The specification of current - time zone information is integral to this behavior. - - If present, the "VTIMEZONE" calendar component defines the set of - Standard Time and Daylight Saving Time observances (or rules) for a - particular time zone for a given interval of time. The "VTIMEZONE" - calendar component cannot be nested within other calendar components. - Multiple "VTIMEZONE" calendar components can exist in an iCalendar - object. In this situation, each "VTIMEZONE" MUST represent a unique - - - -Dawson & Stenerson Standards Track [Page 62] - -RFC 2445 iCalendar November 1998 - - - time zone definition. This is necessary for some classes of events, - such as airline flights, that start in one time zone and end in - another. - - The "VTIMEZONE" calendar component MUST be present if the iCalendar - object contains an RRULE that generates dates on both sides of a time - zone shift (e.g. both in Standard Time and Daylight Saving Time) - unless the iCalendar object intends to convey a floating time (See - the section "4.1.10.11 Time" for proper interpretation of floating - time). It can be present if the iCalendar object does not contain - such a RRULE. In addition, if a RRULE is present, there MUST be valid - time zone information for all recurrence instances. - - The "VTIMEZONE" calendar component MUST include the "TZID" property - and at least one definition of a standard or daylight component. The - standard or daylight component MUST include the "DTSTART", - "TZOFFSETFROM" and "TZOFFSETTO" properties. - - An individual "VTIMEZONE" calendar component MUST be specified for - each unique "TZID" parameter value specified in the iCalendar object. - - Each "VTIMEZONE" calendar component consists of a collection of one - or more sub-components that describe the rule for a particular - observance (either a Standard Time or a Daylight Saving Time - observance). The "STANDARD" sub-component consists of a collection of - properties that describe Standard Time. The "DAYLIGHT" sub-component - consists of a collection of properties that describe Daylight Saving - Time. In general this collection of properties consists of: - - - the first onset date-time for the observance - - - the last onset date-time for the observance, if a last onset - is known. - - - the offset to be applied for the observance - - - a rule that describes the day and time when the observance - takes effect - - - an optional name for the observance - - For a given time zone, there may be multiple unique definitions of - the observances over a period of time. Each observance is described - using either a "STANDARD" or "DAYLIGHT" sub-component. The collection - of these sub-components is used to describe the time zone for a given - period of time. The offset to apply at any given time is found by - locating the observance that has the last onset date and time before - the time in question, and using the offset value from that - - - -Dawson & Stenerson Standards Track [Page 63] - -RFC 2445 iCalendar November 1998 - - - observance. - - The top-level properties in a "VTIMEZONE" calendar component are: - - The mandatory "TZID" property is a text value that uniquely - identifies the VTIMZONE calendar component within the scope of an - iCalendar object. - - The optional "LAST-MODIFIED" property is a UTC value that specifies - the date and time that this time zone definition was last updated. - - The optional "TZURL" property is url value that points to a published - VTIMEZONE definition. TZURL SHOULD refer to a resource that is - accessible by anyone who might need to interpret the object. This - SHOULD NOT normally be a file: URL or other URL that is not widely- - accessible. - - The collection of properties that are used to define the STANDARD and - DAYLIGHT sub-components include: - - The mandatory "DTSTART" property gives the effective onset date and - local time for the time zone sub-component definition. "DTSTART" in - this usage MUST be specified as a local DATE-TIME value. - - The mandatory "TZOFFSETFROM" property gives the UTC offset which is - in use when the onset of this time zone observance begins. - "TZOFFSETFROM" is combined with "DTSTART" to define the effective - onset for the time zone sub-component definition. For example, the - following represents the time at which the observance of Standard - Time took effect in Fall 1967 for New York City: - - DTSTART:19671029T020000 - - TZOFFSETFROM:-0400 - - The mandatory "TZOFFSETTO " property gives the UTC offset for the - time zone sub-component (Standard Time or Daylight Saving Time) when - this observance is in use. - - The optional "TZNAME" property is the customary name for the time - zone. It may be specified multiple times, to allow for specifying - multiple language variants of the time zone names. This could be used - for displaying dates. - - If specified, the onset for the observance defined by the time zone - sub-component is defined by either the "RRULE" or "RDATE" property. - If neither is specified, only one sub-component can be specified in - the "VTIMEZONE" calendar component and it is assumed that the single - - - -Dawson & Stenerson Standards Track [Page 64] - -RFC 2445 iCalendar November 1998 - - - observance specified is always in effect. - - The "RRULE" property defines the recurrence rule for the onset of the - observance defined by this time zone sub-component. Some specific - requirements for the usage of RRULE for this purpose include: - - - If observance is known to have an effective end date, the - "UNTIL" recurrence rule parameter MUST be used to specify the - last valid onset of this observance (i.e., the UNTIL date-time - will be equal to the last instance generated by the recurrence - pattern). It MUST be specified in UTC time. - - - The "DTSTART" and the "TZOFFSETTO" properties MUST be used - when generating the onset date-time values (instances) from the - RRULE. - - Alternatively, the "RDATE" property can be used to define the onset - of the observance by giving the individual onset date and times. - "RDATE" in this usage MUST be specified as a local DATE-TIME value in - UTC time. - - The optional "COMMENT" property is also allowed for descriptive - explanatory text. - - Example: The following are examples of the "VTIMEZONE" calendar - component: - - This is an example showing time zone information for the Eastern - United States using "RDATE" property. Note that this is only suitable - for a recurring event that starts on or later than April 6, 1997 at - 03:00:00 EDT (i.e., the earliest effective transition date and time) - and ends no later than April 7, 1998 02:00:00 EST (i.e., latest valid - date and time for EST in this scenario). For example, this can be - used for a recurring event that occurs every Friday, 8am-9:00 AM, - starting June 1, 1997, ending December 31, 1997. - - BEGIN:VTIMEZONE - TZID:US-Eastern - LAST-MODIFIED:19870101T000000Z - BEGIN:STANDARD - DTSTART:19971026T020000 - RDATE:19971026T020000 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19971026T020000 - - - -Dawson & Stenerson Standards Track [Page 65] - -RFC 2445 iCalendar November 1998 - - - RDATE:19970406T020000 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - - This is a simple example showing the current time zone rules for the - Eastern United States using a RRULE recurrence pattern. Note that - there is no effective end date to either of the Standard Time or - Daylight Time rules. This information would be valid for a recurring - event starting today and continuing indefinitely. - - BEGIN:VTIMEZONE - TZID:US-Eastern - LAST-MODIFIED:19870101T000000Z - TZURL:http://zones.stds_r_us.net/tz/US-Eastern - BEGIN:STANDARD - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - - This is an example showing a fictitious set of rules for the Eastern - United States, where the Daylight Time rule has an effective end date - (i.e., after that date, Daylight Time is no longer observed). - - BEGIN:VTIMEZONE - TZID:US--Fictitious-Eastern - LAST-MODIFIED:19870101T000000Z - BEGIN:STANDARD - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - - - - -Dawson & Stenerson Standards Track [Page 66] - -RFC 2445 iCalendar November 1998 - - - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - - This is an example showing a fictitious set of rules for the Eastern - United States, where the first Daylight Time rule has an effective - end date. There is a second Daylight Time rule that picks up where - the other left off. - - BEGIN:VTIMEZONE - TZID:US--Fictitious-Eastern - LAST-MODIFIED:19870101T000000Z - BEGIN:STANDARD - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - BEGIN:DAYLIGHT - DTSTART:19990424T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - -4.6.6 Alarm Component - - Component Name: VALARM - - Purpose: Provide a grouping of component properties that define an - alarm. - - - - - -Dawson & Stenerson Standards Track [Page 67] - -RFC 2445 iCalendar November 1998 - - - Formal Definition: A "VALARM" calendar component is defined by the - following notation: - - alarmc = "BEGIN" ":" "VALARM" CRLF - (audioprop / dispprop / emailprop / procprop) - "END" ":" "VALARM" CRLF - - audioprop = 2*( - - ; 'action' and 'trigger' are both REQUIRED, - ; but MUST NOT occur more than once - - action / trigger / - - ; 'duration' and 'repeat' are both optional, - ; and MUST NOT occur more than once each, - ; but if one occurs, so MUST the other - - duration / repeat / - - ; the following is optional, - ; but MUST NOT occur more than once - - attach / - - ; the following is optional, - ; and MAY occur more than once - - x-prop - - ) - - - - dispprop = 3*( - - ; the following are all REQUIRED, - ; but MUST NOT occur more than once - - action / description / trigger / - - ; 'duration' and 'repeat' are both optional, - ; and MUST NOT occur more than once each, - ; but if one occurs, so MUST the other - - duration / repeat / - - ; the following is optional, - - - -Dawson & Stenerson Standards Track [Page 68] - -RFC 2445 iCalendar November 1998 - - - ; and MAY occur more than once - - *x-prop - - ) - - - - emailprop = 5*( - - ; the following are all REQUIRED, - ; but MUST NOT occur more than once - - action / description / trigger / summary - - ; the following is REQUIRED, - ; and MAY occur more than once - - attendee / - - ; 'duration' and 'repeat' are both optional, - ; and MUST NOT occur more than once each, - ; but if one occurs, so MUST the other - - duration / repeat / - - ; the following are optional, - ; and MAY occur more than once - - attach / x-prop - - ) - - - - procprop = 3*( - - ; the following are all REQUIRED, - ; but MUST NOT occur more than once - - action / attach / trigger / - - ; 'duration' and 'repeat' are both optional, - ; and MUST NOT occur more than once each, - ; but if one occurs, so MUST the other - - duration / repeat / - - - - -Dawson & Stenerson Standards Track [Page 69] - -RFC 2445 iCalendar November 1998 - - - ; 'description' is optional, - ; and MUST NOT occur more than once - - description / - - ; the following is optional, - ; and MAY occur more than once - - x-prop - - ) - - Description: A "VALARM" calendar component is a grouping of component - properties that is a reminder or alarm for an event or a to-do. For - example, it may be used to define a reminder for a pending event or - an overdue to-do. - - The "VALARM" calendar component MUST include the "ACTION" and - "TRIGGER" properties. The "ACTION" property further constrains the - "VALARM" calendar component in the following ways: - - When the action is "AUDIO", the alarm can also include one and only - one "ATTACH" property, which MUST point to a sound resource, which is - rendered when the alarm is triggered. - - When the action is "DISPLAY", the alarm MUST also include a - "DESCRIPTION" property, which contains the text to be displayed when - the alarm is triggered. - - When the action is "EMAIL", the alarm MUST include a "DESCRIPTION" - property, which contains the text to be used as the message body, a - "SUMMARY" property, which contains the text to be used as the message - subject, and one or more "ATTENDEE" properties, which contain the - email address of attendees to receive the message. It can also - include one or more "ATTACH" properties, which are intended to be - sent as message attachments. When the alarm is triggered, the email - message is sent. - - When the action is "PROCEDURE", the alarm MUST include one and only - one "ATTACH" property, which MUST point to a procedure resource, - which is invoked when the alarm is triggered. - - The "VALARM" calendar component MUST only appear within either a - "VEVENT" or "VTODO" calendar component. "VALARM" calendar components - cannot be nested. Multiple mutually independent "VALARM" calendar - components can be specified for a single "VEVENT" or "VTODO" calendar - component. - - - - -Dawson & Stenerson Standards Track [Page 70] - -RFC 2445 iCalendar November 1998 - - - The "TRIGGER" property specifies when the alarm will be triggered. - The "TRIGGER" property specifies a duration prior to the start of an - event or a to-do. The "TRIGGER" edge may be explicitly set to be - relative to the "START" or "END" of the event or to-do with the - "RELATED" parameter of the "TRIGGER" property. The "TRIGGER" property - value type can alternatively be set to an absolute calendar date and - time of day value. - - In an alarm set to trigger on the "START" of an event or to-do, the - "DTSTART" property MUST be present in the associated event or to-do. - In an alarm in a "VEVENT" calendar component set to trigger on the - "END" of the event, either the "DTEND" property MUST be present, or - the "DTSTART" and "DURATION" properties MUST both be present. In an - alarm in a "VTODO" calendar component set to trigger on the "END" of - the to-do, either the "DUE" property MUST be present, or the - "DTSTART" and "DURATION" properties MUST both be present. - - The alarm can be defined such that it triggers repeatedly. A - definition of an alarm with a repeating trigger MUST include both the - "DURATION" and "REPEAT" properties. The "DURATION" property specifies - the delay period, after which the alarm will repeat. The "REPEAT" - property specifies the number of additional repetitions that the - alarm will triggered. This repitition count is in addition to the - initial triggering of the alarm. Both of these properties MUST be - present in order to specify a repeating alarm. If one of these two - properties is absent, then the alarm will not repeat beyond the - initial trigger. - - The "ACTION" property is used within the "VALARM" calendar component - to specify the type of action invoked when the alarm is triggered. - The "VALARM" properties provide enough information for a specific - action to be invoked. It is typically the responsibility of a - "Calendar User Agent" (CUA) to deliver the alarm in the specified - fashion. An "ACTION" property value of AUDIO specifies an alarm that - causes a sound to be played to alert the user; DISPLAY specifies an - alarm that causes a text message to be displayed to the user; EMAIL - specifies an alarm that causes an electronic email message to be - delivered to one or more email addresses; and PROCEDURE specifies an - alarm that causes a procedure to be executed. The "ACTION" property - MUST specify one and only one of these values. - - In an AUDIO alarm, if the optional "ATTACH" property is included, it - MUST specify an audio sound resource. The intention is that the sound - will be played as the alarm effect. If an "ATTACH" property is - specified that does not refer to a sound resource, or if the - specified sound resource cannot be rendered (because its format is - unsupported, or because it cannot be retrieved), then the CUA or - other entity responsible for playing the sound may choose a fallback - - - -Dawson & Stenerson Standards Track [Page 71] - -RFC 2445 iCalendar November 1998 - - - action, such as playing a built-in default sound, or playing no sound - at all. - - In a DISPLAY alarm, the intended alarm effect is for the text value - of the "DESCRIPTION" property to be displayed to the user. - - In an EMAIL alarm, the intended alarm effect is for an email message - to be composed and delivered to all the addresses specified by the - "ATTENDEE" properties in the "VALARM" calendar component. The - "DESCRIPTION" property of the "VALARM" calendar component MUST be - used as the body text of the message, and the "SUMMARY" property MUST - be used as the subject text. Any "ATTACH" properties in the "VALARM" - calendar component SHOULD be sent as attachments to the message. - - In a PROCEDURE alarm, the "ATTACH" property in the "VALARM" calendar - component MUST specify a procedure or program that is intended to be - invoked as the alarm effect. If the procedure or program is in a - format that cannot be rendered, then no procedure alarm will be - invoked. If the "DESCRIPTION" property is present, its value - specifies the argument string to be passed to the procedure or - program. "Calendar User Agents" that receive an iCalendar object with - this category of alarm, can disable or allow the "Calendar User" to - disable, or otherwise ignore this type of alarm. While a very useful - alarm capability, the PROCEDURE type of alarm SHOULD be treated by - the "Calendar User Agent" as a potential security risk. - - Example: The following example is for a "VALARM" calendar component - that specifies an audio alarm that will sound at a precise time and - repeat 4 more times at 15 minute intervals: - - BEGIN:VALARM - TRIGGER;VALUE=DATE-TIME:19970317T133000Z - REPEAT:4 - DURATION:PT15M - ACTION:AUDIO - ATTACH;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell-01.aud - END:VALARM - - The following example is for a "VALARM" calendar component that - specifies a display alarm that will trigger 30 minutes before the - scheduled start of the event or the due date/time of the to-do it is - associated with and will repeat 2 more times at 15 minute intervals: - - BEGIN:VALARM - TRIGGER:-PT30M - REPEAT:2 - DURATION:PT15M - ACTION:DISPLAY - - - -Dawson & Stenerson Standards Track [Page 72] - -RFC 2445 iCalendar November 1998 - - - DESCRIPTION:Breakfast meeting with executive\n - team at 8:30 AM EST. - END:VALARM - - The following example is for a "VALARM" calendar component that - specifies an email alarm that will trigger 2 days before the - scheduled due date/time of a to-do it is associated with. It does not - repeat. The email has a subject, body and attachment link. - - BEGIN:VALARM - TRIGGER:-P2D - ACTION:EMAIL - ATTENDEE:MAILTO:john_doe@host.com - SUMMARY:*** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING *** - DESCRIPTION:A draft agenda needs to be sent out to the attendees - to the weekly managers meeting (MGR-LIST). Attached is a - pointer the document template for the agenda file. - ATTACH;FMTTYPE=application/binary:http://host.com/templates/agen - da.doc - END:VALARM - - The following example is for a "VALARM" calendar component that - specifies a procedural alarm that will trigger at a precise date/time - and will repeat 23 more times at one hour intervals. The alarm will - invoke a procedure file. - - BEGIN:VALARM - TRIGGER;VALUE=DATE-TIME:19980101T050000Z - REPEAT:23 - DURATION:PT1H - ACTION:PROCEDURE - ATTACH;FMTTYPE=application/binary:ftp://host.com/novo- - procs/felizano.exe - END:VALARM - -4.7 Calendar Properties - - The Calendar Properties are attributes that apply to the iCalendar - object, as a whole. These properties do not appear within a calendar - component. They SHOULD be specified after the "BEGIN:VCALENDAR" - property and prior to any calendar component. - -4.7.1 Calendar Scale - - Property Name: CALSCALE - - Purpose: This property defines the calendar scale used for the - calendar information specified in the iCalendar object. - - - -Dawson & Stenerson Standards Track [Page 73] - -RFC 2445 iCalendar November 1998 - - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: Property can be specified in an iCalendar object. The - default value is "GREGORIAN". - - Description: This memo is based on the Gregorian calendar scale. The - Gregorian calendar scale is assumed if this property is not specified - in the iCalendar object. It is expected that other calendar scales - will be defined in other specifications or by future versions of this - memo. - - Format Definition: The property is defined by the following notation: - - calscale = "CALSCALE" calparam ":" calvalue CRLF - - calparam = *(";" xparam) - - calvalue = "GREGORIAN" / iana-token - - Example: The following is an example of this property: - - CALSCALE:GREGORIAN - -4.7.2 Method - - Property Name: METHOD - - Purpose: This property defines the iCalendar object method associated - with the calendar object. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in an iCalendar object. - - Description: When used in a MIME message entity, the value of this - property MUST be the same as the Content-Type "method" parameter - value. This property can only appear once within the iCalendar - object. If either the "METHOD" property or the Content-Type "method" - parameter is specified, then the other MUST also be specified. - - No methods are defined by this specification. This is the subject of - other specifications, such as the iCalendar Transport-independent - - - -Dawson & Stenerson Standards Track [Page 74] - -RFC 2445 iCalendar November 1998 - - - Interoperability Protocol (iTIP) defined by [ITIP]. - - If this property is not present in the iCalendar object, then a - scheduling transaction MUST NOT be assumed. In such cases, the - iCalendar object is merely being used to transport a snapshot of some - calendar information; without the intention of conveying a scheduling - semantic. - - Format Definition: The property is defined by the following notation: - - method = "METHOD" metparam ":" metvalue CRLF - - metparam = *(";" xparam) - - metvalue = iana-token - - Example: The following is a hypothetical example of this property to - convey that the iCalendar object is a request for a meeting: - - METHOD:REQUEST - -4.7.3 Product Identifier - - Property Name: PRODID - - Purpose: This property specifies the identifier for the product that - created the iCalendar object. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property MUST be specified once in an iCalendar - object. - - Description: The vendor of the implementation SHOULD assure that this - is a globally unique identifier; using some technique such as an FPI - value, as defined in [ISO 9070]. - - This property SHOULD not be used to alter the interpretation of an - iCalendar object beyond the semantics specified in this memo. For - example, it is not to be used to further the understanding of non- - standard properties. - - Format Definition: The property is defined by the following notation: - - prodid = "PRODID" pidparam ":" pidvalue CRLF - - - -Dawson & Stenerson Standards Track [Page 75] - -RFC 2445 iCalendar November 1998 - - - pidparam = *(";" xparam) - - pidvalue = text - ;Any text that describes the product and version - ;and that is generally assured of being unique. - - Example: The following is an example of this property. It does not - imply that English is the default language. - - PRODID:-//ABC Corporation//NONSGML My Product//EN - -4.7.4 Version - - Property Name: VERSION - - Purpose: This property specifies the identifier corresponding to the - highest version number or the minimum and maximum range of the - iCalendar specification that is required in order to interpret the - iCalendar object. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property MUST be specified by an iCalendar object, - but MUST only be specified once. - - Description: A value of "2.0" corresponds to this memo. - - Format Definition: The property is defined by the following notation: - - version = "VERSION" verparam ":" vervalue CRLF - - verparam = *(";" xparam) - - vervalue = "2.0" ;This memo - / maxver - / (minver ";" maxver) - - minver = - ;Minimum iCalendar version needed to parse the iCalendar object - - maxver = - ;Maximum iCalendar version needed to parse the iCalendar object - - Example: The following is an example of this property: - - - - -Dawson & Stenerson Standards Track [Page 76] - -RFC 2445 iCalendar November 1998 - - - VERSION:2.0 - -4.8 Component Properties - - The following properties can appear within calendar components, as - specified by each component property definition. - -4.8.1 Descriptive Component Properties - - The following properties specify descriptive information about - calendar components. - -4.8.1.1 Attachment - - Property Name: ATTACH - - Purpose: The property provides the capability to associate a document - object with a calendar component. - - Value Type: The default value type for this property is URI. The - value type can also be set to BINARY to indicate inline binary - encoded content information. - - Property Parameters: Non-standard, inline encoding, format type and - value data type property parameters can be specified on this - property. - - Conformance: The property can be specified in a "VEVENT", "VTODO", - "VJOURNAL" or "VALARM" calendar components. - - Description: The property can be specified within "VEVENT", "VTODO", - "VJOURNAL", or "VALARM" calendar components. This property can be - specified multiple times within an iCalendar object. - - Format Definition: The property is defined by the following notation: - - attach = "ATTACH" attparam ":" uri CRLF - - attach =/ "ATTACH" attparam ";" "ENCODING" "=" "BASE64" - ";" "VALUE" "=" "BINARY" ":" binary - - attparam = *( - - ; the following is optional, - ; but MUST NOT occur more than once - - (";" fmttypeparam) / - - - - -Dawson & Stenerson Standards Track [Page 77] - -RFC 2445 iCalendar November 1998 - - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following are examples of this property: - - ATTACH:CID:jsmith.part3.960817T083000.xyzMail@host1.com - - ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/ - reports/r-960812.ps - -4.8.1.2 Categories - - Property Name: CATEGORIES - - Purpose: This property defines the categories for a calendar - component. - - Value Type: TEXT - - Property Parameters: Non-standard and language property parameters - can be specified on this property. - - Conformance: The property can be specified within "VEVENT", "VTODO" - or "VJOURNAL" calendar components. - - Description: This property is used to specify categories or subtypes - of the calendar component. The categories are useful in searching for - a calendar component of a particular type and category. Within the - "VEVENT", "VTODO" or "VJOURNAL" calendar components, more than one - category can be specified as a list of categories separated by the - COMMA character (US-ASCII decimal 44). - - Format Definition: The property is defined by the following notation: - - categories = "CATEGORIES" catparam ":" text *("," text) - CRLF - - catparam = *( - - ; the following is optional, - ; but MUST NOT occur more than once - - (";" languageparam ) / - - - - -Dawson & Stenerson Standards Track [Page 78] - -RFC 2445 iCalendar November 1998 - - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following are examples of this property: - - CATEGORIES:APPOINTMENT,EDUCATION - - CATEGORIES:MEETING - -4.8.1.3 Classification - - Property Name: CLASS - - Purpose: This property defines the access classification for a - calendar component. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified once in a "VEVENT", - "VTODO" or "VJOURNAL" calendar components. - - Description: An access classification is only one component of the - general security system within a calendar application. It provides a - method of capturing the scope of the access the calendar owner - intends for information within an individual calendar entry. The - access classification of an individual iCalendar component is useful - when measured along with the other security components of a calendar - system (e.g., calendar user authentication, authorization, access - rights, access role, etc.). Hence, the semantics of the individual - access classifications cannot be completely defined by this memo - alone. Additionally, due to the "blind" nature of most exchange - processes using this memo, these access classifications cannot serve - as an enforcement statement for a system receiving an iCalendar - object. Rather, they provide a method for capturing the intention of - the calendar owner for the access to the calendar component. - - Format Definition: The property is defined by the following notation: - - class = "CLASS" classparam ":" classvalue CRLF - - classparam = *(";" xparam) - - - -Dawson & Stenerson Standards Track [Page 79] - -RFC 2445 iCalendar November 1998 - - - classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token - / x-name - ;Default is PUBLIC - - Example: The following is an example of this property: - - CLASS:PUBLIC - -4.8.1.4 Comment - - Property Name: COMMENT - - Purpose: This property specifies non-processing information intended - to provide a comment to the calendar user. - - Value Type: TEXT - - Property Parameters: Non-standard, alternate text representation and - language property parameters can be specified on this property. - - Conformance: This property can be specified in "VEVENT", "VTODO", - "VJOURNAL", "VTIMEZONE" or "VFREEBUSY" calendar components. - - Description: The property can be specified multiple times. - - Format Definition: The property is defined by the following notation: - - comment = "COMMENT" commparam ":" text CRLF - - commparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" altrepparam) / (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following is an example of this property: - - COMMENT:The meeting really needs to include both ourselves - and the customer. We can't hold this meeting without them. - As a matter of fact\, the venue for the meeting ought to be at - - - -Dawson & Stenerson Standards Track [Page 80] - -RFC 2445 iCalendar November 1998 - - - their site. - - John - - The data type for this property is TEXT. - -4.8.1.5 Description - - Property Name: DESCRIPTION - - Purpose: This property provides a more complete description of the - calendar component, than that provided by the "SUMMARY" property. - - Value Type: TEXT - - Property Parameters: Non-standard, alternate text representation and - language property parameters can be specified on this property. - - Conformance: The property can be specified in the "VEVENT", "VTODO", - "VJOURNAL" or "VALARM" calendar components. The property can be - specified multiple times only within a "VJOURNAL" calendar component. - - Description: This property is used in the "VEVENT" and "VTODO" to - capture lengthy textual decriptions associated with the activity. - - This property is used in the "VJOURNAL" calendar component to capture - one more textual journal entries. - - This property is used in the "VALARM" calendar component to capture - the display text for a DISPLAY category of alarm, to capture the body - text for an EMAIL category of alarm and to capture the argument - string for a PROCEDURE category of alarm. - - Format Definition: The property is defined by the following notation: - - description = "DESCRIPTION" descparam ":" text CRLF - - descparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" altrepparam) / (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - - -Dawson & Stenerson Standards Track [Page 81] - -RFC 2445 iCalendar November 1998 - - - Example: The following is an example of the property with formatted - line breaks in the property value: - - DESCRIPTION:Meeting to provide technical review for "Phoenix" - design.\n Happy Face Conference Room. Phoenix design team - MUST attend this meeting.\n RSVP to team leader. - - The following is an example of the property with folding of long - lines: - - DESCRIPTION:Last draft of the new novel is to be completed - for the editor's proof today. - -4.8.1.6 Geographic Position - - Property Name: GEO - - Purpose: This property specifies information related to the global - position for the activity specified by a calendar component. - - Value Type: FLOAT. The value MUST be two SEMICOLON separated FLOAT - values. - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in "VEVENT" or "VTODO" - calendar components. - - Description: The property value specifies latitude and longitude, in - that order (i.e., "LAT LON" ordering). The longitude represents the - location east or west of the prime meridian as a positive or negative - real number, respectively. The longitude and latitude values MAY be - specified up to six decimal places, which will allow for accuracy to - within one meter of geographical position. Receiving applications - MUST accept values of this precision and MAY truncate values of - greater precision. - - Values for latitude and longitude shall be expressed as decimal - fractions of degrees. Whole degrees of latitude shall be represented - by a two-digit decimal number ranging from 0 through 90. Whole - degrees of longitude shall be represented by a decimal number ranging - from 0 through 180. When a decimal fraction of a degree is specified, - it shall be separated from the whole number of degrees by a decimal - point. - - - - - - -Dawson & Stenerson Standards Track [Page 82] - -RFC 2445 iCalendar November 1998 - - - Latitudes north of the equator shall be specified by a plus sign (+), - or by the absence of a minus sign (-), preceding the digits - designating degrees. Latitudes south of the Equator shall be - designated by a minus sign (-) preceding the digits designating - degrees. A point on the Equator shall be assigned to the Northern - Hemisphere. - - Longitudes east of the prime meridian shall be specified by a plus - sign (+), or by the absence of a minus sign (-), preceding the digits - designating degrees. Longitudes west of the meridian shall be - designated by minus sign (-) preceding the digits designating - degrees. A point on the prime meridian shall be assigned to the - Eastern Hemisphere. A point on the 180th meridian shall be assigned - to the Western Hemisphere. One exception to this last convention is - permitted. For the special condition of describing a band of latitude - around the earth, the East Bounding Coordinate data element shall be - assigned the value +180 (180) degrees. - - Any spatial address with a latitude of +90 (90) or -90 degrees will - specify the position at the North or South Pole, respectively. The - component for longitude may have any legal value. - - With the exception of the special condition described above, this - form is specified in Department of Commerce, 1986, Representation of - geographic point locations for information interchange (Federal - Information Processing Standard 70-1): Washington, Department of - Commerce, National Institute of Standards and Technology. - - The simple formula for converting degrees-minutes-seconds into - decimal degrees is: - - decimal = degrees + minutes/60 + seconds/3600. - - Format Definition: The property is defined by the following notation: - - geo = "GEO" geoparam ":" geovalue CRLF - - geoparam = *(";" xparam) - - geovalue = float ";" float - ;Latitude and Longitude components - - Example: The following is an example of this property: - - GEO:37.386013;-122.082932 - - - - - - -Dawson & Stenerson Standards Track [Page 83] - -RFC 2445 iCalendar November 1998 - - -4.8.1.7 Location - - Property Name: LOCATION - - Purpose: The property defines the intended venue for the activity - defined by a calendar component. - - Value Type: TEXT - - Property Parameters: Non-standard, alternate text representation and - language property parameters can be specified on this property. - - Conformance: This property can be specified in "VEVENT" or "VTODO" - calendar component. - - Description: Specific venues such as conference or meeting rooms may - be explicitly specified using this property. An alternate - representation may be specified that is a URI that points to - directory information with more structured specification of the - location. For example, the alternate representation may specify - either an LDAP URI pointing to an LDAP server entry or a CID URI - pointing to a MIME body part containing a vCard [RFC 2426] for the - location. - - Format Definition: The property is defined by the following notation: - - location = "LOCATION locparam ":" text CRLF - - locparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" altrepparam) / (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following are some examples of this property: - - LOCATION:Conference Room - F123, Bldg. 002 - - LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf": - Conference Room - F123, Bldg. 002 - - - -Dawson & Stenerson Standards Track [Page 84] - -RFC 2445 iCalendar November 1998 - - -4.8.1.8 Percent Complete - - Property Name: PERCENT-COMPLETE - - Purpose: This property is used by an assignee or delegatee of a to-do - to convey the percent completion of a to-do to the Organizer. - - Value Type: INTEGER - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in a "VTODO" calendar - component. - - Description: The property value is a positive integer between zero - and one hundred. A value of "0" indicates the to-do has not yet been - started. A value of "100" indicates that the to-do has been - completed. Integer values in between indicate the percent partially - complete. - - When a to-do is assigned to multiple individuals, the property value - indicates the percent complete for that portion of the to-do assigned - to the assignee or delegatee. For example, if a to-do is assigned to - both individuals "A" and "B". A reply from "A" with a percent - complete of "70" indicates that "A" has completed 70% of the to-do - assigned to them. A reply from "B" with a percent complete of "50" - indicates "B" has completed 50% of the to-do assigned to them. - - Format Definition: The property is defined by the following notation: - - percent = "PERCENT-COMPLETE" pctparam ":" integer CRLF - - pctparam = *(";" xparam) - - Example: The following is an example of this property to show 39% - completion: - - PERCENT-COMPLETE:39 - -4.8.1.9 Priority - - Property Name: PRIORITY - - Purpose: The property defines the relative priority for a calendar - component. - - Value Type: INTEGER - - - -Dawson & Stenerson Standards Track [Page 85] - -RFC 2445 iCalendar November 1998 - - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in a "VEVENT" or "VTODO" - calendar component. - - Description: The priority is specified as an integer in the range - zero to nine. A value of zero (US-ASCII decimal 48) specifies an - undefined priority. A value of one (US-ASCII decimal 49) is the - highest priority. A value of two (US-ASCII decimal 50) is the second - highest priority. Subsequent numbers specify a decreasing ordinal - priority. A value of nine (US-ASCII decimal 58) is the lowest - priority. - - A CUA with a three-level priority scheme of "HIGH", "MEDIUM" and - "LOW" is mapped into this property such that a property value in the - range of one (US-ASCII decimal 49) to four (US-ASCII decimal 52) - specifies "HIGH" priority. A value of five (US-ASCII decimal 53) is - the normal or "MEDIUM" priority. A value in the range of six (US- - ASCII decimal 54) to nine (US-ASCII decimal 58) is "LOW" priority. - - A CUA with a priority schema of "A1", "A2", "A3", "B1", "B2", ..., - "C3" is mapped into this property such that a property value of one - (US-ASCII decimal 49) specifies "A1", a property value of two (US- - ASCII decimal 50) specifies "A2", a property value of three (US-ASCII - decimal 51) specifies "A3", and so forth up to a property value of 9 - (US-ASCII decimal 58) specifies "C3". - - Other integer values are reserved for future use. - - Within a "VEVENT" calendar component, this property specifies a - priority for the event. This property may be useful when more than - one event is scheduled for a given time period. - - Within a "VTODO" calendar component, this property specified a - priority for the to-do. This property is useful in prioritizing - multiple action items for a given time period. - - Format Definition: The property is specified by the following - notation: - - priority = "PRIORITY" prioparam ":" privalue CRLF - ;Default is zero - - prioparam = *(";" xparam) - - privalue = integer ;Must be in the range [0..9] - ; All other values are reserved for future use - - - -Dawson & Stenerson Standards Track [Page 86] - -RFC 2445 iCalendar November 1998 - - - The following is an example of a property with the highest priority: - - PRIORITY:1 - - The following is an example of a property with a next highest - priority: - - PRIORITY:2 - - Example: The following is an example of a property with no priority. - This is equivalent to not specifying the "PRIORITY" property: - - PRIORITY:0 - -4.8.1.10 Resources - - Property Name: RESOURCES - - Purpose: This property defines the equipment or resources anticipated - for an activity specified by a calendar entity.. - - Value Type: TEXT - - Property Parameters: Non-standard, alternate text representation and - language property parameters can be specified on this property. - - Conformance: This property can be specified in "VEVENT" or "VTODO" - calendar component. - - Description: The property value is an arbitrary text. More than one - resource can be specified as a list of resources separated by the - COMMA character (US-ASCII decimal 44). - - Format Definition: The property is defined by the following notation: - - resources = "RESOURCES" resrcparam ":" text *("," text) CRLF - - resrcparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" altrepparam) / (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - - - - -Dawson & Stenerson Standards Track [Page 87] - -RFC 2445 iCalendar November 1998 - - - (";" xparam) - - ) - - Example: The following is an example of this property: - - RESOURCES:EASEL,PROJECTOR,VCR - - RESOURCES;LANGUAGE=fr:1 raton-laveur - -4.8.1.11 Status - - Property Name: STATUS - - Purpose: This property defines the overall status or confirmation for - the calendar component. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in "VEVENT", "VTODO" or - "VJOURNAL" calendar components. - - Description: In a group scheduled calendar component, the property is - used by the "Organizer" to provide a confirmation of the event to the - "Attendees". For example in a "VEVENT" calendar component, the - "Organizer" can indicate that a meeting is tentative, confirmed or - cancelled. In a "VTODO" calendar component, the "Organizer" can - indicate that an action item needs action, is completed, is in - process or being worked on, or has been cancelled. In a "VJOURNAL" - calendar component, the "Organizer" can indicate that a journal entry - is draft, final or has been cancelled or removed. - - Format Definition: The property is defined by the following notation: - - status = "STATUS" statparam] ":" statvalue CRLF - - statparam = *(";" xparam) - - statvalue = "TENTATIVE" ;Indicates event is - ;tentative. - / "CONFIRMED" ;Indicates event is - ;definite. - / "CANCELLED" ;Indicates event was - ;cancelled. - ;Status values for a "VEVENT" - - - -Dawson & Stenerson Standards Track [Page 88] - -RFC 2445 iCalendar November 1998 - - - statvalue =/ "NEEDS-ACTION" ;Indicates to-do needs action. - / "COMPLETED" ;Indicates to-do completed. - / "IN-PROCESS" ;Indicates to-do in process of - / "CANCELLED" ;Indicates to-do was cancelled. - ;Status values for "VTODO". - - statvalue =/ "DRAFT" ;Indicates journal is draft. - / "FINAL" ;Indicates journal is final. - / "CANCELLED" ;Indicates journal is removed. - ;Status values for "VJOURNAL". - - Example: The following is an example of this property for a "VEVENT" - calendar component: - - STATUS:TENTATIVE - - The following is an example of this property for a "VTODO" calendar - component: - - STATUS:NEEDS-ACTION - - The following is an example of this property for a "VJOURNAL" - calendar component: - - STATUS:DRAFT - -4.8.1.12 Summary - - Property Name: SUMMARY - - Purpose: This property defines a short summary or subject for the - calendar component. - - Value Type: TEXT - - Property Parameters: Non-standard, alternate text representation and - language property parameters can be specified on this property. - - Conformance: The property can be specified in "VEVENT", "VTODO", - "VJOURNAL" or "VALARM" calendar components. - - Description: This property is used in the "VEVENT", "VTODO" and - "VJOURNAL" calendar components to capture a short, one line summary - about the activity or journal entry. - - This property is used in the "VALARM" calendar component to capture - the subject of an EMAIL category of alarm. - - - - -Dawson & Stenerson Standards Track [Page 89] - -RFC 2445 iCalendar November 1998 - - - Format Definition: The property is defined by the following notation: - - summary = "SUMMARY" summparam ":" text CRLF - - summparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" altrepparam) / (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following is an example of this property: - - SUMMARY:Department Party - -4.8.2 Date and Time Component Properties - - The following properties specify date and time related information in - calendar components. - -4.8.2.1 Date/Time Completed - - Property Name: COMPLETED - - Purpose: This property defines the date and time that a to-do was - actually completed. - - Value Type: DATE-TIME - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in a "VTODO" calendar - component. - - Description: The date and time MUST be in a UTC format. - - Format Definition: The property is defined by the following notation: - - completed = "COMPLETED" compparam ":" date-time CRLF - - - - -Dawson & Stenerson Standards Track [Page 90] - -RFC 2445 iCalendar November 1998 - - - compparam = *(";" xparam) - - Example: The following is an example of this property: - - COMPLETED:19960401T235959Z - -4.8.2.2 Date/Time End - - Property Name: DTEND - - Purpose: This property specifies the date and time that a calendar - component ends. - - Value Type: The default value type is DATE-TIME. The value type can - be set to a DATE value type. - - Property Parameters: Non-standard, value data type, time zone - identifier property parameters can be specified on this property. - - Conformance: This property can be specified in "VEVENT" or - "VFREEBUSY" calendar components. - - Description: Within the "VEVENT" calendar component, this property - defines the date and time by which the event ends. The value MUST be - later in time than the value of the "DTSTART" property. - - Within the "VFREEBUSY" calendar component, this property defines the - end date and time for the free or busy time information. The time - MUST be specified in the UTC time format. The value MUST be later in - time than the value of the "DTSTART" property. - - Format Definition: The property is defined by the following notation: - - dtend = "DTEND" dtendparam":" dtendval CRLF - - dtendparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - (";" tzidparam) / - - ; the following is optional, - ; and MAY occur more than once - - - - - - -Dawson & Stenerson Standards Track [Page 91] - -RFC 2445 iCalendar November 1998 - - - (";" xparam) - - ) - - - - dtendval = date-time / date - ;Value MUST match value type - - Example: The following is an example of this property: - - DTEND:19960401T235959Z - - DTEND;VALUE=DATE:19980704 - -4.8.2.3 Date/Time Due - - Property Name: DUE - - Purpose: This property defines the date and time that a to-do is - expected to be completed. - - Value Type: The default value type is DATE-TIME. The value type can - be set to a DATE value type. - - Property Parameters: Non-standard, value data type, time zone - identifier property parameters can be specified on this property. - - Conformance: The property can be specified once in a "VTODO" calendar - component. - - Description: The value MUST be a date/time equal to or after the - DTSTART value, if specified. - - Format Definition: The property is defined by the following notation: - - due = "DUE" dueparam":" dueval CRLF - - dueparam = *( - ; the following are optional, - ; but MUST NOT occur more than once - - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - (";" tzidparam) / - - ; the following is optional, - ; and MAY occur more than once - - - - -Dawson & Stenerson Standards Track [Page 92] - -RFC 2445 iCalendar November 1998 - - - *(";" xparam) - - ) - - - - dueval = date-time / date - ;Value MUST match value type - - Example: The following is an example of this property: - - DUE:19980430T235959Z - -4.8.2.4 Date/Time Start - - Property Name: DTSTART - - Purpose: This property specifies when the calendar component begins. - - Value Type: The default value type is DATE-TIME. The time value MUST - be one of the forms defined for the DATE-TIME value type. The value - type can be set to a DATE value type. - - Property Parameters: Non-standard, value data type, time zone - identifier property parameters can be specified on this property. - - Conformance: This property can be specified in the "VEVENT", "VTODO", - "VFREEBUSY", or "VTIMEZONE" calendar components. - - Description: Within the "VEVENT" calendar component, this property - defines the start date and time for the event. The property is - REQUIRED in "VEVENT" calendar components. Events can have a start - date/time but no end date/time. In that case, the event does not take - up any time. - - Within the "VFREEBUSY" calendar component, this property defines the - start date and time for the free or busy time information. The time - MUST be specified in UTC time. - - Within the "VTIMEZONE" calendar component, this property defines the - effective start date and time for a time zone specification. This - property is REQUIRED within each STANDARD and DAYLIGHT part included - in "VTIMEZONE" calendar components and MUST be specified as a local - DATE-TIME without the "TZID" property parameter. - - Format Definition: The property is defined by the following notation: - - dtstart = "DTSTART" dtstparam ":" dtstval CRLF - - - -Dawson & Stenerson Standards Track [Page 93] - -RFC 2445 iCalendar November 1998 - - - dtstparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - (";" tzidparam) / - - ; the following is optional, - ; and MAY occur more than once - - *(";" xparam) - - ) - - - - dtstval = date-time / date - ;Value MUST match value type - - Example: The following is an example of this property: - - DTSTART:19980118T073000Z - -4.8.2.5 Duration - - Property Name: DURATION - - Purpose: The property specifies a positive duration of time. - - Value Type: DURATION - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in "VEVENT", "VTODO", - "VFREEBUSY" or "VALARM" calendar components. - - Description: In a "VEVENT" calendar component the property may be - used to specify a duration of the event, instead of an explicit end - date/time. In a "VTODO" calendar component the property may be used - to specify a duration for the to-do, instead of an explicit due - date/time. In a "VFREEBUSY" calendar component the property may be - used to specify the interval of free time being requested. In a - "VALARM" calendar component the property may be used to specify the - delay period prior to repeating an alarm. - - Format Definition: The property is defined by the following notation: - - - -Dawson & Stenerson Standards Track [Page 94] - -RFC 2445 iCalendar November 1998 - - - duration = "DURATION" durparam ":" dur-value CRLF - ;consisting of a positive duration of time. - - durparam = *(";" xparam) - - Example: The following is an example of this property that specifies - an interval of time of 1 hour and zero minutes and zero seconds: - - DURATION:PT1H0M0S - - The following is an example of this property that specifies an - interval of time of 15 minutes. - - DURATION:PT15M - -4.8.2.6 Free/Busy Time - - Property Name: FREEBUSY - - Purpose: The property defines one or more free or busy time - intervals. - - Value Type: PERIOD. The date and time values MUST be in an UTC time - format. - - Property Parameters: Non-standard or free/busy time type property - parameters can be specified on this property. - - Conformance: The property can be specified in a "VFREEBUSY" calendar - component. - - Property Parameter: "FBTYPE" and non-standard parameters can be - specified on this property. - - Description: These time periods can be specified as either a start - and end date-time or a start date-time and duration. The date and - time MUST be a UTC time format. - - "FREEBUSY" properties within the "VFREEBUSY" calendar component - SHOULD be sorted in ascending order, based on start time and then end - time, with the earliest periods first. - - The "FREEBUSY" property can specify more than one value, separated by - the COMMA character (US-ASCII decimal 44). In such cases, the - "FREEBUSY" property values SHOULD all be of the same "FBTYPE" - property parameter type (e.g., all values of a particular "FBTYPE" - listed together in a single property). - - - - -Dawson & Stenerson Standards Track [Page 95] - -RFC 2445 iCalendar November 1998 - - - Format Definition: The property is defined by the following notation: - - freebusy = "FREEBUSY" fbparam ":" fbvalue - CRLF - - fbparam = *( - ; the following is optional, - ; but MUST NOT occur more than once - - (";" fbtypeparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - fbvalue = period *["," period] - ;Time value MUST be in the UTC time format. - - Example: The following are some examples of this property: - - FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:19970308T160000Z/PT8H30M - - FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H - - FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H, - 19970308T230000Z/19970309T000000Z - -4.8.2.7 Time Transparency - - Property Name: TRANSP - - Purpose: This property defines whether an event is transparent or not - to busy time searches. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified once in a "VEVENT" - calendar component. - - Description: Time Transparency is the characteristic of an event that - determines whether it appears to consume time on a calendar. Events - that consume actual time for the individual or resource associated - - - -Dawson & Stenerson Standards Track [Page 96] - -RFC 2445 iCalendar November 1998 - - - with the calendar SHOULD be recorded as OPAQUE, allowing them to be - detected by free-busy time searches. Other events, which do not take - up the individual's (or resource's) time SHOULD be recorded as - TRANSPARENT, making them invisible to free-busy time searches. - - Format Definition: The property is specified by the following - notation: - - transp = "TRANSP" tranparam ":" transvalue CRLF - - tranparam = *(";" xparam) - - transvalue = "OPAQUE" ;Blocks or opaque on busy time searches. - / "TRANSPARENT" ;Transparent on busy time searches. - ;Default value is OPAQUE - - Example: The following is an example of this property for an event - that is transparent or does not block on free/busy time searches: - - TRANSP:TRANSPARENT - - The following is an example of this property for an event that is - opaque or blocks on free/busy time searches: - - TRANSP:OPAQUE - -4.8.3 Time Zone Component Properties - - The following properties specify time zone information in calendar - components. - -4.8.3.1 Time Zone Identifier - - Property Name: TZID - - Purpose: This property specifies the text value that uniquely - identifies the "VTIMEZONE" calendar component. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property MUST be specified in a "VTIMEZONE" - calendar component. - - - - - - -Dawson & Stenerson Standards Track [Page 97] - -RFC 2445 iCalendar November 1998 - - - Description: This is the label by which a time zone calendar - component is referenced by any iCalendar properties whose data type - is either DATE-TIME or TIME and not intended to specify a UTC or a - "floating" time. The presence of the SOLIDUS character (US-ASCII - decimal 47) as a prefix, indicates that this TZID represents an - unique ID in a globally defined time zone registry (when such - registry is defined). - - Note: This document does not define a naming convention for time - zone identifiers. Implementers may want to use the naming - conventions defined in existing time zone specifications such as - the public-domain Olson database [TZ]. The specification of - globally unique time zone identifiers is not addressed by this - document and is left for future study. - - Format Definition: This property is defined by the following - notation: - - tzid = "TZID" tzidpropparam ":" [tzidprefix] text CRLF - - tzidpropparam = *(";" xparam) - - ;tzidprefix = "/" - ; Defined previously. Just listed here for reader convenience. - - Example: The following are examples of non-globally unique time zone - identifiers: - - TZID:US-Eastern - - TZID:California-Los_Angeles - - The following is an example of a fictitious globally unique time zone - identifier: - - TZID:/US-New_York-New_York - -4.8.3.2 Time Zone Name - - Property Name: TZNAME - - Purpose: This property specifies the customary designation for a time - zone description. - - Value Type: TEXT - - Property Parameters: Non-standard and language property parameters - can be specified on this property. - - - -Dawson & Stenerson Standards Track [Page 98] - -RFC 2445 iCalendar November 1998 - - - Conformance: This property can be specified in a "VTIMEZONE" calendar - component. - - Description: This property may be specified in multiple languages; in - order to provide for different language requirements. - - Format Definition: This property is defined by the following - notation: - - tzname = "TZNAME" tznparam ":" text CRLF - - tznparam = *( - - ; the following is optional, - ; but MUST NOT occur more than once - - (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following are example of this property: - - TZNAME:EST - - The following is an example of this property when two different - languages for the time zone name are specified: - - TZNAME;LANGUAGE=en:EST - TZNAME;LANGUAGE=fr-CA:HNE - -4.8.3.3 Time Zone Offset From - - Property Name: TZOFFSETFROM - - Purpose: This property specifies the offset which is in use prior to - this time zone observance. - - Value Type: UTC-OFFSET - - Property Parameters: Non-standard property parameters can be - specified on this property. - - - - - -Dawson & Stenerson Standards Track [Page 99] - -RFC 2445 iCalendar November 1998 - - - Conformance: This property MUST be specified in a "VTIMEZONE" - calendar component. - - Description: This property specifies the offset which is in use prior - to this time observance. It is used to calculate the absolute time at - which the transition to a given observance takes place. This property - MUST only be specified in a "VTIMEZONE" calendar component. A - "VTIMEZONE" calendar component MUST include this property. The - property value is a signed numeric indicating the number of hours and - possibly minutes from UTC. Positive numbers represent time zones east - of the prime meridian, or ahead of UTC. Negative numbers represent - time zones west of the prime meridian, or behind UTC. - - Format Definition: The property is defined by the following notation: - - tzoffsetfrom = "TZOFFSETFROM" frmparam ":" utc-offset - CRLF - - frmparam = *(";" xparam) - - Example: The following are examples of this property: - - TZOFFSETFROM:-0500 - - TZOFFSETFROM:+1345 - -4.8.3.4 Time Zone Offset To - - Property Name: TZOFFSETTO - - Purpose: This property specifies the offset which is in use in this - time zone observance. - - Value Type: UTC-OFFSET - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property MUST be specified in a "VTIMEZONE" - calendar component. - - Description: This property specifies the offset which is in use in - this time zone observance. It is used to calculate the absolute time - for the new observance. The property value is a signed numeric - indicating the number of hours and possibly minutes from UTC. - Positive numbers represent time zones east of the prime meridian, or - ahead of UTC. Negative numbers represent time zones west of the prime - meridian, or behind UTC. - - - -Dawson & Stenerson Standards Track [Page 100] - -RFC 2445 iCalendar November 1998 - - - Format Definition: The property is defined by the following notation: - - tzoffsetto = "TZOFFSETTO" toparam ":" utc-offset CRLF - - toparam = *(";" xparam) - - Example: The following are examples of this property: - - TZOFFSETTO:-0400 - - TZOFFSETTO:+1245 - -4.8.3.5 Time Zone URL - - Property Name: TZURL - - Purpose: The TZURL provides a means for a VTIMEZONE component to - point to a network location that can be used to retrieve an up-to- - date version of itself. - - Value Type: URI - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in a "VTIMEZONE" calendar - component. - - Description: The TZURL provides a means for a VTIMEZONE component to - point to a network location that can be used to retrieve an up-to- - date version of itself. This provides a hook to handle changes - government bodies impose upon time zone definitions. Retrieval of - this resource results in an iCalendar object containing a single - VTIMEZONE component and a METHOD property set to PUBLISH. - - Format Definition: The property is defined by the following notation: - - tzurl = "TZURL" tzurlparam ":" uri CRLF - - tzurlparam = *(";" xparam) - - Example: The following is an example of this property: - - TZURL:http://timezones.r.us.net/tz/US-California-Los_Angeles - - - - - - - -Dawson & Stenerson Standards Track [Page 101] - -RFC 2445 iCalendar November 1998 - - -4.8.4 Relationship Component Properties - - The following properties specify relationship information in calendar - components. - -4.8.4.1 Attendee - - Property Name: ATTENDEE - - Purpose: The property defines an "Attendee" within a calendar - component. - - Value Type: CAL-ADDRESS - - Property Parameters: Non-standard, language, calendar user type, - group or list membership, participation role, participation status, - RSVP expectation, delegatee, delegator, sent by, common name or - directory entry reference property parameters can be specified on - this property. - - Conformance: This property MUST be specified in an iCalendar object - that specifies a group scheduled calendar entity. This property MUST - NOT be specified in an iCalendar object when publishing the calendar - information (e.g., NOT in an iCalendar object that specifies the - publication of a calendar user's busy time, event, to-do or journal). - This property is not specified in an iCalendar object that specifies - only a time zone definition or that defines calendar entities that - are not group scheduled entities, but are entities only on a single - user's calendar. - - Description: The property MUST only be specified within calendar - components to specify participants, non-participants and the chair of - a group scheduled calendar entity. The property is specified within - an "EMAIL" category of the "VALARM" calendar component to specify an - email address that is to receive the email type of iCalendar alarm. - - The property parameter CN is for the common or displayable name - associated with the calendar address; ROLE, for the intended role - that the attendee will have in the calendar component; PARTSTAT, for - the status of the attendee's participation; RSVP, for indicating - whether the favor of a reply is requested; CUTYPE, to indicate the - type of calendar user; MEMBER, to indicate the groups that the - attendee belongs to; DELEGATED-TO, to indicate the calendar users - that the original request was delegated to; and DELEGATED-FROM, to - indicate whom the request was delegated from; SENT-BY, to indicate - whom is acting on behalf of the ATTENDEE; and DIR, to indicate the - URI that points to the directory information corresponding to the - attendee. These property parameters can be specified on an "ATTENDEE" - - - -Dawson & Stenerson Standards Track [Page 102] - -RFC 2445 iCalendar November 1998 - - - property in either a "VEVENT", "VTODO" or "VJOURNAL" calendar - component. They MUST not be specified in an "ATTENDEE" property in a - "VFREEBUSY" or "VALARM" calendar component. If the LANGUAGE property - parameter is specified, the identified language applies to the CN - parameter. - - A recipient delegated a request MUST inherit the RSVP and ROLE values - from the attendee that delegated the request to them. - - Multiple attendees can be specified by including multiple "ATTENDEE" - properties within the calendar component. - - Format Definition: The property is defined by the following notation: - - attendee = "ATTENDEE" attparam ":" cal-address CRLF - - attparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" cutypeparam) / (";"memberparam) / - (";" roleparam) / (";" partstatparam) / - (";" rsvpparam) / (";" deltoparam) / - (";" delfromparam) / (";" sentbyparam) / - (";"cnparam) / (";" dirparam) / - (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following are examples of this property's use for a to- - do: - - ORGANIZER:MAILTO:jsmith@host1.com - ATTENDEE;MEMBER="MAILTO:DEV-GROUP@host2.com": - MAILTO:joecool@host2.com - ATTENDEE;DELEGATED-FROM="MAILTO:immud@host3.com": - MAILTO:ildoit@host1.com - - The following is an example of this property used for specifying - multiple attendees to an event: - - - - - -Dawson & Stenerson Standards Track [Page 103] - -RFC 2445 iCalendar November 1998 - - - ORGANIZER:MAILTO:jsmith@host1.com - ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry Cabot - :MAILTO:hcabot@host2.com - ATTENDEE;ROLE=REQ-PARTICIPANT;DELEGATED-FROM="MAILTO:bob@host.com" - ;PARTSTAT=ACCEPTED;CN=Jane Doe:MAILTO:jdoe@host1.com - - The following is an example of this property with a URI to the - directory information associated with the attendee: - - ATTENDEE;CN=John Smith;DIR="ldap://host.com:6666/o=eDABC% - 20Industries,c=3DUS??(cn=3DBJim%20Dolittle)":MAILTO:jimdo@ - host1.com - - The following is an example of this property with "delegatee" and - "delegator" information for an event: - - ORGANIZER;CN=John Smith:MAILTO:jsmith@host.com - ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;DELEGATED-FROM= - "MAILTO:iamboss@host2.com";CN=Henry Cabot:MAILTO:hcabot@ - host2.com - ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO= - "MAILTO:hcabot@host2.com";CN=The Big Cheese:MAILTO:iamboss - @host2.com - ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe - :MAILTO:jdoe@host1.com - - Example: The following is an example of this property's use when - another calendar user is acting on behalf of the "Attendee": - - ATTENDEE;SENT-BY=MAILTO:jan_doe@host1.com;CN=John Smith:MAILTO: - jsmith@host1.com - -4.8.4.2 Contact - - Property Name: CONTACT - - Purpose: The property is used to represent contact information or - alternately a reference to contact information associated with the - calendar component. - - Value Type: TEXT - - Property Parameters: Non-standard, alternate text representation and - language property parameters can be specified on this property. - - Conformance: The property can be specified in a "VEVENT", "VTODO", - "VJOURNAL" or "VFREEBUSY" calendar component. - - - - -Dawson & Stenerson Standards Track [Page 104] - -RFC 2445 iCalendar November 1998 - - - Description: The property value consists of textual contact - information. An alternative representation for the property value can - also be specified that refers to a URI pointing to an alternate form, - such as a vCard [RFC 2426], for the contact information. - - Format Definition: The property is defined by the following notation: - - contact = "CONTACT" contparam ":" text CRLF - - contparam = *( - ; the following are optional, - ; but MUST NOT occur more than once - - (";" altrepparam) / (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following is an example of this property referencing - textual contact information: - - CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234 - - The following is an example of this property with an alternate - representation of a LDAP URI to a directory entry containing the - contact information: - - CONTACT;ALTREP="ldap://host.com:6666/o=3DABC%20Industries\, - c=3DUS??(cn=3DBJim%20Dolittle)":Jim Dolittle\, ABC Industries\, - +1-919-555-1234 - - The following is an example of this property with an alternate - representation of a MIME body part containing the contact - information, such as a vCard [RFC 2426] embedded in a [MIME-DIR] - content-type: - - CONTACT;ALTREP="CID=":Jim - Dolittle\, ABC Industries\, +1-919-555-1234 - - The following is an example of this property referencing a network - resource, such as a vCard [RFC 2426] object containing the contact - information: - - - - - -Dawson & Stenerson Standards Track [Page 105] - -RFC 2445 iCalendar November 1998 - - - CONTACT;ALTREP="http://host.com/pdi/jdoe.vcf":Jim - Dolittle\, ABC Industries\, +1-919-555-1234 - -4.8.4.3 Organizer - - Property Name: ORGANIZER - - Purpose: The property defines the organizer for a calendar component. - - Value Type: CAL-ADDRESS - - Property Parameters: Non-standard, language, common name, directory - entry reference, sent by property parameters can be specified on this - property. - - Conformance: This property MUST be specified in an iCalendar object - that specifies a group scheduled calendar entity. This property MUST - be specified in an iCalendar object that specifies the publication of - a calendar user's busy time. This property MUST NOT be specified in - an iCalendar object that specifies only a time zone definition or - that defines calendar entities that are not group scheduled entities, - but are entities only on a single user's calendar. - - Description: The property is specified within the "VEVENT", "VTODO", - "VJOURNAL calendar components to specify the organizer of a group - scheduled calendar entity. The property is specified within the - "VFREEBUSY" calendar component to specify the calendar user - requesting the free or busy time. When publishing a "VFREEBUSY" - calendar component, the property is used to specify the calendar that - the published busy time came from. - - The property has the property parameters CN, for specifying the - common or display name associated with the "Organizer", DIR, for - specifying a pointer to the directory information associated with the - "Organizer", SENT-BY, for specifying another calendar user that is - acting on behalf of the "Organizer". The non-standard parameters may - also be specified on this property. If the LANGUAGE property - parameter is specified, the identified language applies to the CN - parameter value. - - Format Definition: The property is defined by the following notation: - - organizer = "ORGANIZER" orgparam ":" - cal-address CRLF - - orgparam = *( - - ; the following are optional, - - - -Dawson & Stenerson Standards Track [Page 106] - -RFC 2445 iCalendar November 1998 - - - ; but MUST NOT occur more than once - - (";" cnparam) / (";" dirparam) / (";" sentbyparam) / - (";" languageparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - Example: The following is an example of this property: - - ORGANIZER;CN=John Smith:MAILTO:jsmith@host1.com - - The following is an example of this property with a pointer to the - directory information associated with the organizer: - - ORGANIZER;CN=JohnSmith;DIR="ldap://host.com:6666/o=3DDC%20Associ - ates,c=3DUS??(cn=3DJohn%20Smith)":MAILTO:jsmith@host1.com - - The following is an example of this property used by another calendar - user who is acting on behalf of the organizer, with responses - intended to be sent back to the organizer, not the other calendar - user: - - ORGANIZER;SENT-BY="MAILTO:jane_doe@host.com": - MAILTO:jsmith@host1.com - -4.8.4.4 Recurrence ID - - Property Name: RECURRENCE-ID - - Purpose: This property is used in conjunction with the "UID" and - "SEQUENCE" property to identify a specific instance of a recurring - "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property - value is the effective value of the "DTSTART" property of the - recurrence instance. - - Value Type: The default value type for this property is DATE-TIME. - The time format can be any of the valid forms defined for a DATE-TIME - value type. See DATE-TIME value type definition for specific - interpretations of the various forms. The value type can be set to - DATE. - - - - - - -Dawson & Stenerson Standards Track [Page 107] - -RFC 2445 iCalendar November 1998 - - - Property Parameters: Non-standard property, value data type, time - zone identifier and recurrence identifier range parameters can be - specified on this property. - - Conformance: This property can be specified in an iCalendar object - containing a recurring calendar component. - - Description: The full range of calendar components specified by a - recurrence set is referenced by referring to just the "UID" property - value corresponding to the calendar component. The "RECURRENCE-ID" - property allows the reference to an individual instance within the - recurrence set. - - If the value of the "DTSTART" property is a DATE type value, then the - value MUST be the calendar date for the recurrence instance. - - The date/time value is set to the time when the original recurrence - instance would occur; meaning that if the intent is to change a - Friday meeting to Thursday, the date/time is still set to the - original Friday meeting. - - The "RECURRENCE-ID" property is used in conjunction with the "UID" - and "SEQUENCE" property to identify a particular instance of a - recurring event, to-do or journal. For a given pair of "UID" and - "SEQUENCE" property values, the "RECURRENCE-ID" value for a - recurrence instance is fixed. When the definition of the recurrence - set for a calendar component changes, and hence the "SEQUENCE" - property value changes, the "RECURRENCE-ID" for a given recurrence - instance might also change.The "RANGE" parameter is used to specify - the effective range of recurrence instances from the instance - specified by the "RECURRENCE-ID" property value. The default value - for the range parameter is the single recurrence instance only. The - value can also be "THISANDPRIOR" to indicate a range defined by the - given recurrence instance and all prior instances or the value can be - "THISANDFUTURE" to indicate a range defined by the given recurrence - instance and all subsequent instances. - - Format Definition: The property is defined by the following notation: - - recurid = "RECURRENCE-ID" ridparam ":" ridval CRLF - - ridparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" "VALUE" "=" ("DATE-TIME" / "DATE)) / - (";" tzidparam) / (";" rangeparam) / - - - -Dawson & Stenerson Standards Track [Page 108] - -RFC 2445 iCalendar November 1998 - - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - ridval = date-time / date - ;Value MUST match value type - - Example: The following are examples of this property: - - RECURRENCE-ID;VALUE=DATE:19960401 - - RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z - -4.8.4.5 Related To - - Property Name: RELATED-TO - - Purpose: The property is used to represent a relationship or - reference between one calendar component and another. - - Value Type: TEXT - - Property Parameters: Non-standard and relationship type property - parameters can be specified on this property. - - Conformance: The property can be specified one or more times in the - "VEVENT", "VTODO" or "VJOURNAL" calendar components. - - Description: The property value consists of the persistent, globally - unique identifier of another calendar component. This value would be - represented in a calendar component by the "UID" property. - - By default, the property value points to another calendar component - that has a PARENT relationship to the referencing object. The - "RELTYPE" property parameter is used to either explicitly state the - default PARENT relationship type to the referenced calendar component - or to override the default PARENT relationship type and specify - either a CHILD or SIBLING relationship. The PARENT relationship - indicates that the calendar component is a subordinate of the - referenced calendar component. The CHILD relationship indicates that - the calendar component is a superior of the referenced calendar - component. The SIBLING relationship indicates that the calendar - component is a peer of the referenced calendar component. - - - - - -Dawson & Stenerson Standards Track [Page 109] - -RFC 2445 iCalendar November 1998 - - - Changes to a calendar component referenced by this property can have - an implicit impact on the related calendar component. For example, if - a group event changes its start or end date or time, then the - related, dependent events will need to have their start and end dates - changed in a corresponding way. Similarly, if a PARENT calendar - component is canceled or deleted, then there is an implied impact to - the related CHILD calendar components. This property is intended only - to provide information on the relationship of calendar components. It - is up to the target calendar system to maintain any property - implications of this relationship. - - Format Definition: The property is defined by the following notation: - - related = "RELATED-TO" [relparam] ":" text CRLF - - relparam = *( - - ; the following is optional, - ; but MUST NOT occur more than once - - (";" reltypeparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparm) - - ) - - The following is an example of this property: - - RELATED-TO: - - RELATED-TO:<19960401-080045-4000F192713-0052@host1.com> - -4.8.4.6 Uniform Resource Locator - - Property Name: URL - - Purpose: This property defines a Uniform Resource Locator (URL) - associated with the iCalendar object. - - Value Type: URI - - Property Parameters: Non-standard property parameters can be - specified on this property. - - - - - -Dawson & Stenerson Standards Track [Page 110] - -RFC 2445 iCalendar November 1998 - - - Conformance: This property can be specified once in the "VEVENT", - "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. - - Description: This property may be used in a calendar component to - convey a location where a more dynamic rendition of the calendar - information associated with the calendar component can be found. This - memo does not attempt to standardize the form of the URI, nor the - format of the resource pointed to by the property value. If the URL - property and Content-Location MIME header are both specified, they - MUST point to the same resource. - - Format Definition: The property is defined by the following notation: - - url = "URL" urlparam ":" uri CRLF - - urlparam = *(";" xparam) - - Example: The following is an example of this property: - - URL:http://abc.com/pub/calendars/jsmith/mytime.ics - -4.8.4.7 Unique Identifier - - Property Name: UID - - Purpose: This property defines the persistent, globally unique - identifier for the calendar component. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property MUST be specified in the "VEVENT", "VTODO", - "VJOURNAL" or "VFREEBUSY" calendar components. - - Description: The UID itself MUST be a globally unique identifier. The - generator of the identifier MUST guarantee that the identifier is - unique. There are several algorithms that can be used to accomplish - this. The identifier is RECOMMENDED to be the identical syntax to the - [RFC 822] addr-spec. A good method to assure uniqueness is to put the - domain name or a domain literal IP address of the host on which the - identifier was created on the right hand side of the "@", and on the - left hand side, put a combination of the current calendar date and - time of day (i.e., formatted in as a DATE-TIME value) along with some - other currently unique (perhaps sequential) identifier available on - the system (for example, a process id number). Using a date/time - value on the left hand side and a domain name or domain literal on - - - -Dawson & Stenerson Standards Track [Page 111] - -RFC 2445 iCalendar November 1998 - - - the right hand side makes it possible to guarantee uniqueness since - no two hosts should be using the same domain name or IP address at - the same time. Though other algorithms will work, it is RECOMMENDED - that the right hand side contain some domain identifier (either of - the host itself or otherwise) such that the generator of the message - identifier can guarantee the uniqueness of the left hand side within - the scope of that domain. - - This is the method for correlating scheduling messages with the - referenced "VEVENT", "VTODO", or "VJOURNAL" calendar component. - - The full range of calendar components specified by a recurrence set - is referenced by referring to just the "UID" property value - corresponding to the calendar component. The "RECURRENCE-ID" property - allows the reference to an individual instance within the recurrence - set. - - This property is an important method for group scheduling - applications to match requests with later replies, modifications or - deletion requests. Calendaring and scheduling applications MUST - generate this property in "VEVENT", "VTODO" and "VJOURNAL" calendar - components to assure interoperability with other group scheduling - applications. This identifier is created by the calendar system that - generates an iCalendar object. - - Implementations MUST be able to receive and persist values of at - least 255 characters for this property. - - Format Definition: The property is defined by the following notation: - - uid = "UID" uidparam ":" text CRLF - - uidparam = *(";" xparam) - - Example: The following is an example of this property: - - UID:19960401T080045Z-4000F192713-0052@host1.com - -4.8.5 Recurrence Component Properties - - The following properties specify recurrence information in calendar - components. - -4.8.5.1 Exception Date/Times - - Property Name: EXDATE - - - - - -Dawson & Stenerson Standards Track [Page 112] - -RFC 2445 iCalendar November 1998 - - - Purpose: This property defines the list of date/time exceptions for a - recurring calendar component. - - Value Type: The default value type for this property is DATE-TIME. - The value type can be set to DATE. - - Property Parameters: Non-standard, value data type and time zone - identifier property parameters can be specified on this property. - - Conformance: This property can be specified in an iCalendar object - that includes a recurring calendar component. - - Description: The exception dates, if specified, are used in computing - the recurrence set. The recurrence set is the complete set of - recurrence instances for a calendar component. The recurrence set is - generated by considering the initial "DTSTART" property along with - the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained - within the iCalendar object. The "DTSTART" property defines the first - instance in the recurrence set. Multiple instances of the "RRULE" and - "EXRULE" properties can also be specified to define more - sophisticated recurrence sets. The final recurrence set is generated - by gathering all of the start date-times generated by any of the - specified "RRULE" and "RDATE" properties, and then excluding any - start date and times which fall within the union of start date and - times generated by any specified "EXRULE" and "EXDATE" properties. - This implies that start date and times within exclusion related - properties (i.e., "EXDATE" and "EXRULE") take precedence over those - specified by inclusion properties (i.e., "RDATE" and "RRULE"). Where - duplicate instances are generated by the "RRULE" and "RDATE" - properties, only one recurrence is considered. Duplicate instances - are ignored. - - The "EXDATE" property can be used to exclude the value specified in - "DTSTART". However, in such cases the original "DTSTART" date MUST - still be maintained by the calendaring and scheduling system because - the original "DTSTART" value has inherent usage dependencies by other - properties such as the "RECURRENCE-ID". - - Format Definition: The property is defined by the following notation: - - exdate = "EXDATE" exdtparam ":" exdtval *("," exdtval) CRLF - - exdtparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - - - -Dawson & Stenerson Standards Track [Page 113] - -RFC 2445 iCalendar November 1998 - - - (";" tzidparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - exdtval = date-time / date - ;Value MUST match value type - - Example: The following is an example of this property: - - EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z - -4.8.5.2 Exception Rule - - Property Name: EXRULE - - Purpose: This property defines a rule or repeating pattern for an - exception to a recurrence set. - - Value Type: RECUR - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in "VEVENT", "VTODO" or - "VJOURNAL" calendar components. - - Description: The exception rule, if specified, is used in computing - the recurrence set. The recurrence set is the complete set of - recurrence instances for a calendar component. The recurrence set is - generated by considering the initial "DTSTART" property along with - the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained - within the iCalendar object. The "DTSTART" defines the first instance - in the recurrence set. Multiple instances of the "RRULE" and "EXRULE" - properties can also be specified to define more sophisticated - recurrence sets. The final recurrence set is generated by gathering - all of the start date-times generated by any of the specified "RRULE" - and "RDATE" properties, and excluding any start date and times which - fall within the union of start date and times generated by any - specified "EXRULE" and "EXDATE" properties. This implies that start - date and times within exclusion related properties (i.e., "EXDATE" - and "EXRULE") take precedence over those specified by inclusion - - - - - -Dawson & Stenerson Standards Track [Page 114] - -RFC 2445 iCalendar November 1998 - - - properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are - generated by the "RRULE" and "RDATE" properties, only one recurrence - is considered. Duplicate instances are ignored. - - The "EXRULE" property can be used to exclude the value specified in - "DTSTART". However, in such cases the original "DTSTART" date MUST - still be maintained by the calendaring and scheduling system because - the original "DTSTART" value has inherent usage dependencies by other - properties such as the "RECURRENCE-ID". - - Format Definition: The property is defined by the following notation: - - exrule = "EXRULE" exrparam ":" recur CRLF - - exrparam = *(";" xparam) - - Example: The following are examples of this property. Except every - other week, on Tuesday and Thursday for 4 occurrences: - - EXRULE:FREQ=WEEKLY;COUNT=4;INTERVAL=2;BYDAY=TU,TH - - Except daily for 10 occurrences: - - EXRULE:FREQ=DAILY;COUNT=10 - - Except yearly in June and July for 8 occurrences: - - EXRULE:FREQ=YEARLY;COUNT=8;BYMONTH=6,7 - -4.8.5.3 Recurrence Date/Times - - Property Name: RDATE - - Purpose: This property defines the list of date/times for a - recurrence set. - - Value Type: The default value type for this property is DATE-TIME. - The value type can be set to DATE or PERIOD. - - Property Parameters: Non-standard, value data type and time zone - identifier property parameters can be specified on this property. - - Conformance: The property can be specified in "VEVENT", "VTODO", - "VJOURNAL" or "VTIMEZONE" calendar components. - - - - - - - -Dawson & Stenerson Standards Track [Page 115] - -RFC 2445 iCalendar November 1998 - - - Description: This property can appear along with the "RRULE" property - to define an aggregate set of repeating occurrences. When they both - appear in an iCalendar object, the recurring events are defined by - the union of occurrences defined by both the "RDATE" and "RRULE". - - The recurrence dates, if specified, are used in computing the - recurrence set. The recurrence set is the complete set of recurrence - instances for a calendar component. The recurrence set is generated - by considering the initial "DTSTART" property along with the "RRULE", - "RDATE", "EXDATE" and "EXRULE" properties contained within the - iCalendar object. The "DTSTART" property defines the first instance - in the recurrence set. Multiple instances of the "RRULE" and "EXRULE" - properties can also be specified to define more sophisticated - recurrence sets. The final recurrence set is generated by gathering - all of the start date/times generated by any of the specified "RRULE" - and "RDATE" properties, and excluding any start date/times which fall - within the union of start date/times generated by any specified - "EXRULE" and "EXDATE" properties. This implies that start date/times - within exclusion related properties (i.e., "EXDATE" and "EXRULE") - take precedence over those specified by inclusion properties (i.e., - "RDATE" and "RRULE"). Where duplicate instances are generated by the - "RRULE" and "RDATE" properties, only one recurrence is considered. - Duplicate instances are ignored. - - Format Definition: The property is defined by the following notation: - - rdate = "RDATE" rdtparam ":" rdtval *("," rdtval) CRLF - - rdtparam = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" "VALUE" "=" ("DATE-TIME" / "DATE" / "PERIOD")) / - (";" tzidparam) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - rdtval = date-time / date / period - ;Value MUST match value type - - Example: The following are examples of this property: - - - - -Dawson & Stenerson Standards Track [Page 116] - -RFC 2445 iCalendar November 1998 - - - RDATE:19970714T123000Z - - RDATE;TZID=US-EASTERN:19970714T083000 - - RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z, - 19960404T010000Z/PT3H - - RDATE;VALUE=DATE:19970101,19970120,19970217,19970421 - 19970526,19970704,19970901,19971014,19971128,19971129,19971225 - -4.8.5.4 Recurrence Rule - - Property Name: RRULE - - Purpose: This property defines a rule or repeating pattern for - recurring events, to-dos, or time zone definitions. - - Value Type: RECUR - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified one or more times in - recurring "VEVENT", "VTODO" and "VJOURNAL" calendar components. It - can also be specified once in each STANDARD or DAYLIGHT sub-component - of the "VTIMEZONE" calendar component. - - Description: The recurrence rule, if specified, is used in computing - the recurrence set. The recurrence set is the complete set of - recurrence instances for a calendar component. The recurrence set is - generated by considering the initial "DTSTART" property along with - the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained - within the iCalendar object. The "DTSTART" property defines the first - instance in the recurrence set. Multiple instances of the "RRULE" and - "EXRULE" properties can also be specified to define more - sophisticated recurrence sets. The final recurrence set is generated - by gathering all of the start date/times generated by any of the - specified "RRULE" and "RDATE" properties, and excluding any start - date/times which fall within the union of start date/times generated - by any specified "EXRULE" and "EXDATE" properties. This implies that - start date/times within exclusion related properties (i.e., "EXDATE" - and "EXRULE") take precedence over those specified by inclusion - properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are - generated by the "RRULE" and "RDATE" properties, only one recurrence - is considered. Duplicate instances are ignored. - - - - - - -Dawson & Stenerson Standards Track [Page 117] - -RFC 2445 iCalendar November 1998 - - - The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION" - property pair, specified within the iCalendar object defines the - first instance of the recurrence. When used with a recurrence rule, - the "DTSTART" and "DTEND" properties MUST be specified in local time - and the appropriate set of "VTIMEZONE" calendar components MUST be - included. For detail on the usage of the "VTIMEZONE" calendar - component, see the "VTIMEZONE" calendar component definition. - - Any duration associated with the iCalendar object applies to all - members of the generated recurrence set. Any modified duration for - specific recurrences MUST be explicitly specified using the "RDATE" - property. - - Format Definition: This property is defined by the following - notation: - - rrule = "RRULE" rrulparam ":" recur CRLF - - rrulparam = *(";" xparam) - - Example: All examples assume the Eastern United States time zone. - - Daily for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=DAILY;COUNT=10 - - ==> (1997 9:00 AM EDT)September 2-11 - - Daily until December 24, 1997: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=DAILY;UNTIL=19971224T000000Z - - ==> (1997 9:00 AM EDT)September 2-30;October 1-25 - (1997 9:00 AM EST)October 26-31;November 1-30;December 1-23 - - Every other day - forever: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=DAILY;INTERVAL=2 - ==> (1997 9:00 AM EDT)September2,4,6,8...24,26,28,30; - October 2,4,6...20,22,24 - (1997 9:00 AM EST)October 26,28,30;November 1,3,5,7...25,27,29; - Dec 1,3,... - - Every 10 days, 5 occurrences: - - - - -Dawson & Stenerson Standards Track [Page 118] - -RFC 2445 iCalendar November 1998 - - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5 - - ==> (1997 9:00 AM EDT)September 2,12,22;October 2,12 - - Everyday in January, for 3 years: - - DTSTART;TZID=US-Eastern:19980101T090000 - RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z; - BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA - or - RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1 - - ==> (1998 9:00 AM EDT)January 1-31 - (1999 9:00 AM EDT)January 1-31 - (2000 9:00 AM EDT)January 1-31 - - Weekly for 10 occurrences - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;COUNT=10 - - ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21 - (1997 9:00 AM EST)October 28;November 4 - - Weekly until December 24, 1997 - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z - - ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21 - (1997 9:00 AM EST)October 28;November 4,11,18,25; - December 2,9,16,23 - Every other week - forever: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU - - ==> (1997 9:00 AM EDT)September 2,16,30;October 14 - (1997 9:00 AM EST)October 28;November 11,25;December 9,23 - (1998 9:00 AM EST)January 6,20;February - ... - - Weekly on Tuesday and Thursday for 5 weeks: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH - or - - - -Dawson & Stenerson Standards Track [Page 119] - -RFC 2445 iCalendar November 1998 - - - RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH - - ==> (1997 9:00 AM EDT)September 2,4,9,11,16,18,23,25,30;October 2 - - Every other week on Monday, Wednesday and Friday until December 24, - 1997, but starting on Tuesday, September 2, 1997: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU; - BYDAY=MO,WE,FR - ==> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October - 1,3,13,15,17 - (1997 9:00 AM EST)October 27,29,31;November 10,12,14,24,26,28; - December 8,10,12,22 - - Every other week on Tuesday and Thursday, for 8 occurrences: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH - - ==> (1997 9:00 AM EDT)September 2,4,16,18,30;October 2,14,16 - - Monthly on the 1st Friday for ten occurrences: - - DTSTART;TZID=US-Eastern:19970905T090000 - RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR - - ==> (1997 9:00 AM EDT)September 5;October 3 - (1997 9:00 AM EST)November 7;Dec 5 - (1998 9:00 AM EST)January 2;February 6;March 6;April 3 - (1998 9:00 AM EDT)May 1;June 5 - - Monthly on the 1st Friday until December 24, 1997: - - DTSTART;TZID=US-Eastern:19970905T090000 - RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR - - ==> (1997 9:00 AM EDT)September 5;October 3 - (1997 9:00 AM EST)November 7;December 5 - - Every other month on the 1st and last Sunday of the month for 10 - occurrences: - - DTSTART;TZID=US-Eastern:19970907T090000 - RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU - - ==> (1997 9:00 AM EDT)September 7,28 - (1997 9:00 AM EST)November 2,30 - - - -Dawson & Stenerson Standards Track [Page 120] - -RFC 2445 iCalendar November 1998 - - - (1998 9:00 AM EST)January 4,25;March 1,29 - (1998 9:00 AM EDT)May 3,31 - - Monthly on the second to last Monday of the month for 6 months: - - DTSTART;TZID=US-Eastern:19970922T090000 - RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO - - ==> (1997 9:00 AM EDT)September 22;October 20 - (1997 9:00 AM EST)November 17;December 22 - (1998 9:00 AM EST)January 19;February 16 - - Monthly on the third to the last day of the month, forever: - - DTSTART;TZID=US-Eastern:19970928T090000 - RRULE:FREQ=MONTHLY;BYMONTHDAY=-3 - - ==> (1997 9:00 AM EDT)September 28 - (1997 9:00 AM EST)October 29;November 28;December 29 - (1998 9:00 AM EST)January 29;February 26 - ... - - Monthly on the 2nd and 15th of the month for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15 - - ==> (1997 9:00 AM EDT)September 2,15;October 2,15 - (1997 9:00 AM EST)November 2,15;December 2,15 - (1998 9:00 AM EST)January 2,15 - - Monthly on the first and last day of the month for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970930T090000 - RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1 - - ==> (1997 9:00 AM EDT)September 30;October 1 - (1997 9:00 AM EST)October 31;November 1,30;December 1,31 - (1998 9:00 AM EST)January 1,31;February 1 - - Every 18 months on the 10th thru 15th of the month for 10 - occurrences: - - DTSTART;TZID=US-Eastern:19970910T090000 - RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14, - 15 - - ==> (1997 9:00 AM EDT)September 10,11,12,13,14,15 - - - -Dawson & Stenerson Standards Track [Page 121] - -RFC 2445 iCalendar November 1998 - - - (1999 9:00 AM EST)March 10,11,12,13 - - Every Tuesday, every other month: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU - - ==> (1997 9:00 AM EDT)September 2,9,16,23,30 - (1997 9:00 AM EST)November 4,11,18,25 - (1998 9:00 AM EST)January 6,13,20,27;March 3,10,17,24,31 - ... - - Yearly in June and July for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970610T090000 - RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7 - ==> (1997 9:00 AM EDT)June 10;July 10 - (1998 9:00 AM EDT)June 10;July 10 - (1999 9:00 AM EDT)June 10;July 10 - (2000 9:00 AM EDT)June 10;July 10 - (2001 9:00 AM EDT)June 10;July 10 - Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY components - are specified, the day is gotten from DTSTART - - Every other year on January, February, and March for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970310T090000 - RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3 - - ==> (1997 9:00 AM EST)March 10 - (1999 9:00 AM EST)January 10;February 10;March 10 - (2001 9:00 AM EST)January 10;February 10;March 10 - (2003 9:00 AM EST)January 10;February 10;March 10 - - Every 3rd year on the 1st, 100th and 200th day for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970101T090000 - RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200 - - ==> (1997 9:00 AM EST)January 1 - (1997 9:00 AM EDT)April 10;July 19 - (2000 9:00 AM EST)January 1 - (2000 9:00 AM EDT)April 9;July 18 - (2003 9:00 AM EST)January 1 - (2003 9:00 AM EDT)April 10;July 19 - (2006 9:00 AM EST)January 1 - - Every 20th Monday of the year, forever: - - - -Dawson & Stenerson Standards Track [Page 122] - -RFC 2445 iCalendar November 1998 - - - DTSTART;TZID=US-Eastern:19970519T090000 - RRULE:FREQ=YEARLY;BYDAY=20MO - - ==> (1997 9:00 AM EDT)May 19 - (1998 9:00 AM EDT)May 18 - (1999 9:00 AM EDT)May 17 - ... - - Monday of week number 20 (where the default start of the week is - Monday), forever: - - DTSTART;TZID=US-Eastern:19970512T090000 - RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO - - ==> (1997 9:00 AM EDT)May 12 - (1998 9:00 AM EDT)May 11 - (1999 9:00 AM EDT)May 17 - ... - - Every Thursday in March, forever: - - DTSTART;TZID=US-Eastern:19970313T090000 - RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH - - ==> (1997 9:00 AM EST)March 13,20,27 - (1998 9:00 AM EST)March 5,12,19,26 - (1999 9:00 AM EST)March 4,11,18,25 - ... - - Every Thursday, but only during June, July, and August, forever: - - DTSTART;TZID=US-Eastern:19970605T090000 - RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8 - - ==> (1997 9:00 AM EDT)June 5,12,19,26;July 3,10,17,24,31; - August 7,14,21,28 - (1998 9:00 AM EDT)June 4,11,18,25;July 2,9,16,23,30; - August 6,13,20,27 - (1999 9:00 AM EDT)June 3,10,17,24;July 1,8,15,22,29; - August 5,12,19,26 - ... - - Every Friday the 13th, forever: - - DTSTART;TZID=US-Eastern:19970902T090000 - EXDATE;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13 - - - - -Dawson & Stenerson Standards Track [Page 123] - -RFC 2445 iCalendar November 1998 - - - ==> (1998 9:00 AM EST)February 13;March 13;November 13 - (1999 9:00 AM EDT)August 13 - (2000 9:00 AM EDT)October 13 - ... - - The first Saturday that follows the first Sunday of the month, - forever: - - DTSTART;TZID=US-Eastern:19970913T090000 - RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13 - - ==> (1997 9:00 AM EDT)September 13;October 11 - (1997 9:00 AM EST)November 8;December 13 - (1998 9:00 AM EST)January 10;February 7;March 7 - (1998 9:00 AM EDT)April 11;May 9;June 13... - ... - - Every four years, the first Tuesday after a Monday in November, - forever (U.S. Presidential Election day): - - DTSTART;TZID=US-Eastern:19961105T090000 - RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4, - 5,6,7,8 - - ==> (1996 9:00 AM EST)November 5 - (2000 9:00 AM EST)November 7 - (2004 9:00 AM EST)November 2 - ... - - The 3rd instance into the month of one of Tuesday, Wednesday or - Thursday, for the next 3 months: - - DTSTART;TZID=US-Eastern:19970904T090000 - RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3 - - ==> (1997 9:00 AM EDT)September 4;October 7 - (1997 9:00 AM EST)November 6 - - The 2nd to last weekday of the month: - - DTSTART;TZID=US-Eastern:19970929T090000 - RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2 - - ==> (1997 9:00 AM EDT)September 29 - (1997 9:00 AM EST)October 30;November 27;December 30 - (1998 9:00 AM EST)January 29;February 26;March 30 - ... - - - - -Dawson & Stenerson Standards Track [Page 124] - -RFC 2445 iCalendar November 1998 - - - Every 3 hours from 9:00 AM to 5:00 PM on a specific day: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z - - ==> (September 2, 1997 EDT)09:00,12:00,15:00 - - Every 15 minutes for 6 occurrences: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6 - - ==> (September 2, 1997 EDT)09:00,09:15,09:30,09:45,10:00,10:15 - - Every hour and a half for 4 occurrences: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4 - - ==> (September 2, 1997 EDT)09:00,10:30;12:00;13:30 - - Every 20 minutes from 9:00 AM to 4:40 PM every day: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 - or - RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16 - - ==> (September 2, 1997 EDT)9:00,9:20,9:40,10:00,10:20, - ... 16:00,16:20,16:40 - (September 3, 1997 EDT)9:00,9:20,9:40,10:00,10:20, - ...16:00,16:20,16:40 - ... - - An example where the days generated makes a difference because of - WKST: - - DTSTART;TZID=US-Eastern:19970805T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO - - ==> (1997 EDT)Aug 5,10,19,24 - - changing only WKST from MO to SU, yields different results... - - DTSTART;TZID=US-Eastern:19970805T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU - ==> (1997 EDT)August 5,17,19,31 - - - - -Dawson & Stenerson Standards Track [Page 125] - -RFC 2445 iCalendar November 1998 - - -4.8.6 Alarm Component Properties - - The following properties specify alarm information in calendar - components. - -4.8.6.1 Action - - Property Name: ACTION - - Purpose: This property defines the action to be invoked when an alarm - is triggered. - - Value Type: TEXT - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property MUST be specified once in a "VALARM" - calendar component. - - Description: Each "VALARM" calendar component has a particular type - of action associated with it. This property specifies the type of - action - - Format Definition: The property is defined by the following notation: - - action = "ACTION" actionparam ":" actionvalue CRLF - - actionparam = *(";" xparam) - - actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE" - / iana-token / x-name - - Example: The following are examples of this property in a "VALARM" - calendar component: - - ACTION:AUDIO - - ACTION:DISPLAY - - ACTION:PROCEDURE - -4.8.6.2 Repeat Count - - Property Name: REPEAT - - Purpose: This property defines the number of time the alarm should be - repeated, after the initial trigger. - - - -Dawson & Stenerson Standards Track [Page 126] - -RFC 2445 iCalendar November 1998 - - - Value Type: INTEGER - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in a "VALARM" calendar - component. - - Description: If the alarm triggers more than once, then this property - MUST be specified along with the "DURATION" property. - - Format Definition: The property is defined by the following notation: - - repeatcnt = "REPEAT" repparam ":" integer CRLF - ;Default is "0", zero. - - repparam = *(";" xparam) - - Example: The following is an example of this property for an alarm - that repeats 4 additional times with a 5 minute delay after the - initial triggering of the alarm: - - REPEAT:4 - DURATION:PT5M - -4.8.6.3 Trigger - - Property Name: TRIGGER - - Purpose: This property specifies when an alarm will trigger. - - Value Type: The default value type is DURATION. The value type can be - set to a DATE-TIME value type, in which case the value MUST specify a - UTC formatted DATE-TIME value. - - Property Parameters: Non-standard, value data type, time zone - identifier or trigger relationship property parameters can be - specified on this property. The trigger relationship property - parameter MUST only be specified when the value type is DURATION. - - Conformance: This property MUST be specified in the "VALARM" calendar - component. - - Description: Within the "VALARM" calendar component, this property - defines when the alarm will trigger. The default value type is - DURATION, specifying a relative time for the trigger of the alarm. - The default duration is relative to the start of an event or to-do - that the alarm is associated with. The duration can be explicitly set - - - -Dawson & Stenerson Standards Track [Page 127] - -RFC 2445 iCalendar November 1998 - - - to trigger from either the end or the start of the associated event - or to-do with the "RELATED" parameter. A value of START will set the - alarm to trigger off the start of the associated event or to-do. A - value of END will set the alarm to trigger off the end of the - associated event or to-do. - - Either a positive or negative duration may be specified for the - "TRIGGER" property. An alarm with a positive duration is triggered - after the associated start or end of the event or to-do. An alarm - with a negative duration is triggered before the associated start or - end of the event or to-do. - - The "RELATED" property parameter is not valid if the value type of - the property is set to DATE-TIME (i.e., for an absolute date and time - alarm trigger). If a value type of DATE-TIME is specified, then the - property value MUST be specified in the UTC time format. If an - absolute trigger is specified on an alarm for a recurring event or - to-do, then the alarm will only trigger for the specified absolute - date/time, along with any specified repeating instances. - - If the trigger is set relative to START, then the "DTSTART" property - MUST be present in the associated "VEVENT" or "VTODO" calendar - component. If an alarm is specified for an event with the trigger set - relative to the END, then the "DTEND" property or the "DSTART" and - "DURATION' properties MUST be present in the associated "VEVENT" - calendar component. If the alarm is specified for a to-do with a - trigger set relative to the END, then either the "DUE" property or - the "DSTART" and "DURATION' properties MUST be present in the - associated "VTODO" calendar component. - - Alarms specified in an event or to-do which is defined in terms of a - DATE value type will be triggered relative to 00:00:00 UTC on the - specified date. For example, if "DTSTART:19980205, then the duration - trigger will be relative to19980205T000000Z. - - Format Definition: The property is defined by the following notation: - - trigger = "TRIGGER" (trigrel / trigabs) - - trigrel = *( - - ; the following are optional, - ; but MUST NOT occur more than once - - (";" "VALUE" "=" "DURATION") / - (";" trigrelparam) / - - ; the following is optional, - - - -Dawson & Stenerson Standards Track [Page 128] - -RFC 2445 iCalendar November 1998 - - - ; and MAY occur more than once - - (";" xparam) - ) ":" dur-value - - trigabs = 1*( - - ; the following is REQUIRED, - ; but MUST NOT occur more than once - - (";" "VALUE" "=" "DATE-TIME") / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) ":" date-time - - Example: A trigger set 15 minutes prior to the start of the event or - to-do. - - TRIGGER:-P15M - - A trigger set 5 minutes after the end of the event or to-do. - - TRIGGER;RELATED=END:P5M - - A trigger set to an absolute date/time. - - TRIGGER;VALUE=DATE-TIME:19980101T050000Z - -4.8.7 Change Management Component Properties - - The following properties specify change management information in - calendar components. - -4.8.7.1 Date/Time Created - - Property Name: CREATED - - Purpose: This property specifies the date and time that the calendar - information was created by the calendar user agent in the calendar - store. - - Note: This is analogous to the creation date and time for a file - in the file system. - - - - -Dawson & Stenerson Standards Track [Page 129] - -RFC 2445 iCalendar November 1998 - - - Value Type: DATE-TIME - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified once in "VEVENT", "VTODO" - or "VJOURNAL" calendar components. - - Description: The date and time is a UTC value. - - Format Definition: The property is defined by the following notation: - - created = "CREATED" creaparam ":" date-time CRLF - - creaparam = *(";" xparam) - - Example: The following is an example of this property: - - CREATED:19960329T133000Z - -4.8.7.2 Date/Time Stamp - - Property Name: DTSTAMP - - Purpose: The property indicates the date/time that the instance of - the iCalendar object was created. - - Value Type: DATE-TIME - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property MUST be included in the "VEVENT", "VTODO", - "VJOURNAL" or "VFREEBUSY" calendar components. - - Description: The value MUST be specified in the UTC time format. - - This property is also useful to protocols such as [IMIP] that have - inherent latency issues with the delivery of content. This property - will assist in the proper sequencing of messages containing iCalendar - objects. - - This property is different than the "CREATED" and "LAST-MODIFIED" - properties. These two properties are used to specify when the - particular calendar data in the calendar store was created and last - modified. This is different than when the iCalendar object - representation of the calendar service information was created or - last modified. - - - -Dawson & Stenerson Standards Track [Page 130] - -RFC 2445 iCalendar November 1998 - - - Format Definition: The property is defined by the following notation: - - dtstamp = "DTSTAMP" stmparam ":" date-time CRLF - - stmparam = *(";" xparam) - - Example: - - DTSTAMP:19971210T080000Z - -4.8.7.3 Last Modified - - Property Name: LAST-MODIFIED - - Purpose: The property specifies the date and time that the - information associated with the calendar component was last revised - in the calendar store. - - Note: This is analogous to the modification date and time for a - file in the file system. - - Value Type: DATE-TIME - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified in the "EVENT", "VTODO", - "VJOURNAL" or "VTIMEZONE" calendar components. - - Description: The property value MUST be specified in the UTC time - format. - - Format Definition: The property is defined by the following notation: - - last-mod = "LAST-MODIFIED" lstparam ":" date-time CRLF - - lstparam = *(";" xparam) - - Example: The following is are examples of this property: - - LAST-MODIFIED:19960817T133000Z - -4.8.7.4 Sequence Number - - Property Name: SEQUENCE - - Purpose: This property defines the revision sequence number of the - calendar component within a sequence of revisions. - - - -Dawson & Stenerson Standards Track [Page 131] - -RFC 2445 iCalendar November 1998 - - - Value Type: integer - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: The property can be specified in "VEVENT", "VTODO" or - "VJOURNAL" calendar component. - - Description: When a calendar component is created, its sequence - number is zero (US-ASCII decimal 48). It is monotonically incremented - by the "Organizer's" CUA each time the "Organizer" makes a - significant revision to the calendar component. When the "Organizer" - makes changes to one of the following properties, the sequence number - MUST be incremented: - - . "DTSTART" - - . "DTEND" - - . "DUE" - - . "RDATE" - - . "RRULE" - - . "EXDATE" - - . "EXRULE" - - . "STATUS" - - In addition, changes made by the "Organizer" to other properties can - also force the sequence number to be incremented. The "Organizer" CUA - MUST increment the sequence number when ever it makes changes to - properties in the calendar component that the "Organizer" deems will - jeopardize the validity of the participation status of the - "Attendees". For example, changing the location of a meeting from one - locale to another distant locale could effectively impact the - participation status of the "Attendees". - - The "Organizer" includes this property in an iCalendar object that it - sends to an "Attendee" to specify the current version of the calendar - component. - - The "Attendee" includes this property in an iCalendar object that it - sends to the "Organizer" to specify the version of the calendar - component that the "Attendee" is referring to. - - - - -Dawson & Stenerson Standards Track [Page 132] - -RFC 2445 iCalendar November 1998 - - - A change to the sequence number is not the mechanism that an - "Organizer" uses to request a response from the "Attendees". The - "RSVP" parameter on the "ATTENDEE" property is used by the - "Organizer" to indicate that a response from the "Attendees" is - requested. - - Format Definition: This property is defined by the following - notation: - - seq = "SEQUENCE" seqparam ":" integer CRLF - ; Default is "0" - - seqparam = *(";" xparam) - - Example: The following is an example of this property for a calendar - component that was just created by the "Organizer". - - SEQUENCE:0 - - The following is an example of this property for a calendar component - that has been revised two different times by the "Organizer". - - SEQUENCE:2 - -4.8.8 Miscellaneous Component Properties - - The following properties specify information about a number of - miscellaneous features of calendar components. - -4.8.8.1 Non-standard Properties - - Property Name: Any property name with a "X-" prefix - - Purpose: This class of property provides a framework for defining - non-standard properties. - - Value Type: TEXT - - Property Parameters: Non-standard and language property parameters - can be specified on this property. - - Conformance: This property can be specified in any calendar - component. - - Description: The MIME Calendaring and Scheduling Content Type - provides a "standard mechanism for doing non-standard things". This - extension support is provided for implementers to "push the envelope" - on the existing version of the memo. Extension properties are - - - -Dawson & Stenerson Standards Track [Page 133] - -RFC 2445 iCalendar November 1998 - - - specified by property and/or property parameter names that have the - prefix text of "X-" (the two character sequence: LATIN CAPITAL LETTER - X character followed by the HYPEN-MINUS character). It is recommended - that vendors concatenate onto this sentinel another short prefix text - to identify the vendor. This will facilitate readability of the - extensions and minimize possible collision of names between different - vendors. User agents that support this content type are expected to - be able to parse the extension properties and property parameters but - can ignore them. - - At present, there is no registration authority for names of extension - properties and property parameters. The data type for this property - is TEXT. Optionally, the data type can be any of the other valid data - types. - - Format Definition: The property is defined by the following notation: - - x-prop = x-name *(";" xparam) [";" languageparam] ":" text CRLF - ; Lines longer than 75 octets should be folded - - Example: The following might be the ABC vendor's extension for an - audio-clip form of subject property: - - X-ABC-MMSUBJ;X-ABC-MMSUBJTYPE=wave:http://load.noise.org/mysubj.wav - -4.8.8.2 Request Status - - Property Name: REQUEST-STATUS - - Purpose: This property defines the status code returned for a - scheduling request. - - Value Type: TEXT - - Property Parameters: Non-standard and language property parameters - can be specified on this property. - - Conformance: The property can be specified in "VEVENT", "VTODO", - "VJOURNAL" or "VFREEBUSY" calendar component. - - Description: This property is used to return status code information - related to the processing of an associated iCalendar object. The data - type for this property is TEXT. - - The value consists of a short return status component, a longer - return status description component, and optionally a status-specific - data component. The components of the value are separated by the - SEMICOLON character (US-ASCII decimal 59). - - - -Dawson & Stenerson Standards Track [Page 134] - -RFC 2445 iCalendar November 1998 - - - The short return status is a PERIOD character (US-ASCII decimal 46) - separated 3-tuple of integers. For example, "3.1.1". The successive - levels of integers provide for a successive level of status code - granularity. - - The following are initial classes for the return status code. - Individual iCalendar object methods will define specific return - status codes for these classes. In addition, other classes for the - return status code may be defined using the registration process - defined later in this memo. - - |==============+===============================================| - | Short Return | Longer Return Status Description | - | Status Code | | - |==============+===============================================| - | 1.xx | Preliminary success. This class of status | - | | of status code indicates that the request has | - | | request has been initially processed but that | - | | completion is pending. | - |==============+===============================================| - | 2.xx | Successful. This class of status code | - | | indicates that the request was completed | - | | successfuly. However, the exact status code | - | | can indicate that a fallback has been taken. | - |==============+===============================================| - | 3.xx | Client Error. This class of status code | - | | indicates that the request was not successful.| - | | The error is the result of either a syntax or | - | | a semantic error in the client formatted | - | | request. Request should not be retried until | - | | the condition in the request is corrected. | - |==============+===============================================| - | 4.xx | Scheduling Error. This class of status code | - | | indicates that the request was not successful.| - | | Some sort of error occurred within the | - | | calendaring and scheduling service, not | - | | directly related to the request itself. | - |==============+===============================================| - - Format Definition: The property is defined by the following notation: - - rstatus = "REQUEST-STATUS" rstatparam ":" - statcode ";" statdesc [";" extdata] - - rstatparam = *( - - ; the following is optional, - ; but MUST NOT occur more than once - - - -Dawson & Stenerson Standards Track [Page 135] - -RFC 2445 iCalendar November 1998 - - - (";" languageparm) / - - ; the following is optional, - ; and MAY occur more than once - - (";" xparam) - - ) - - statcode = 1*DIGIT *("." 1*DIGIT) - ;Hierarchical, numeric return status code - - statdesc = text - ;Textual status description - - extdata = text - ;Textual exception data. For example, the offending property - ;name and value or complete property line. - - Example: The following are some possible examples of this property. - The COMMA and SEMICOLON separator characters in the property value - are BACKSLASH character escaped because they appear in a text value. - - REQUEST-STATUS:2.0;Success - - REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 - - REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled - as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2 - - REQUEST-STATUS:4.1;Event conflict. Date/time is busy. - - REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: - MAILTO:jsmith@host.com - -5 iCalendar Object Examples - - The following examples are provided as an informational source of - illustrative iCalendar objects consistent with this content type. - - The following example specifies a three-day conference that begins at - 8:00 AM EDT, September 18, 1996 and end at 6:00 PM EDT, September 20, - 1996. - - BEGIN:VCALENDAR PRODID:-//xyz Corp//NONSGML PDA Calendar Verson - 1.0//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:19960704T120000Z - UID:uid1@host.com ORGANIZER:MAILTO:jsmith@host.com - DTSTART:19960918T143000Z DTEND:19960920T220000Z STATUS:CONFIRMED - - - -Dawson & Stenerson Standards Track [Page 136] - -RFC 2445 iCalendar November 1998 - - - CATEGORIES:CONFERENCE SUMMARY:Networld+Interop Conference - DESCRIPTION:Networld+Interop Conference - and Exhibit\nAtlanta World Congress Center\n - Atlanta, Georgia END:VEVENT END:VCALENDAR - - The following example specifies a group scheduled meeting that begin - at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12, - 1998. The "Organizer" has scheduled the meeting with one or more - calendar users in a group. A time zone specification for Eastern - United States has been specified. - - BEGIN:VCALENDAR - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VTIMEZONE - TZID:US-Eastern - BEGIN:STANDARD - DTSTART:19981025T020000 - RDATE:19981025T020000 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19990404T020000 - RDATE:19990404T020000 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - BEGIN:VEVENT - DTSTAMP:19980309T231000Z - UID:guid-1.host1.com - ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com - ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP: - MAILTO:employee-A@host.com - DESCRIPTION:Project XYZ Review Meeting - CATEGORIES:MEETING - CLASS:PUBLIC - CREATED:19980309T130000Z - SUMMARY:XYZ Project Review - DTSTART;TZID=US-Eastern:19980312T083000 - DTEND;TZID=US-Eastern:19980312T093000 - LOCATION:1CP Conference Room 4350 - END:VEVENT - END:VCALENDAR - - - - -Dawson & Stenerson Standards Track [Page 137] - -RFC 2445 iCalendar November 1998 - - - The following is an example of an iCalendar object passed in a MIME - message with a single body part consisting of a "text/calendar" - Content Type. - - TO:jsmith@host1.com - FROM:jdoe@host1.com - MIME-VERSION:1.0 - MESSAGE-ID: - CONTENT-TYPE:text/calendar - - BEGIN:VCALENDAR - METHOD:xyz - VERSION:2.0 - PRODID:-//ABC Corporation//NONSGML My Product//EN - BEGIN:VEVENT - DTSTAMP:19970324T1200Z - SEQUENCE:0 - UID:uid3@host1.com - ORGANIZER:MAILTO:jdoe@host1.com - ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host1.com - DTSTART:19970324T123000Z - DTEND:19970324T210000Z - CATEGORIES:MEETING,PROJECT - CLASS:PUBLIC - SUMMARY:Calendaring Interoperability Planning Meeting - DESCRIPTION:Discuss how we can test c&s interoperability\n - using iCalendar and other IETF standards. - LOCATION:LDB Lobby - ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/ - conf/bkgrnd.ps - END:VEVENT - END:VCALENDAR - - The following is an example of a to-do due on April 15, 1998. An - audio alarm has been specified to remind the calendar user at noon, - the day before the to-do is expected to be completed and repeat - hourly, four additional times. The to-do definition has been modified - twice since it was initially created. - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//ABC Corporation//NONSGML My Product//EN - BEGIN:VTODO - DTSTAMP:19980130T134500Z - SEQUENCE:2 - UID:uid4@host1.com - ORGANIZER:MAILTO:unclesam@us.gov - ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@host.com - - - -Dawson & Stenerson Standards Track [Page 138] - -RFC 2445 iCalendar November 1998 - - - DUE:19980415T235959 - STATUS:NEEDS-ACTION - SUMMARY:Submit Income Taxes - BEGIN:VALARM - ACTION:AUDIO - TRIGGER:19980403T120000 - ATTACH;FMTTYPE=audio/basic:http://host.com/pub/audio- - files/ssbanner.aud - REPEAT:4 - DURATION:PT1H - END:VALARM - END:VTODO - END:VCALENDAR - - The following is an example of a journal entry. - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//ABC Corporation//NONSGML My Product//EN - BEGIN:VJOURNAL - DTSTAMP:19970324T120000Z - UID:uid5@host1.com - ORGANIZER:MAILTO:jsmith@host.com - STATUS:DRAFT - CLASS:PUBLIC - CATEGORY:Project Report, XYZ, Weekly Meeting - DESCRIPTION:Project xyz Review Meeting Minutes\n - Agenda\n1. Review of project version 1.0 requirements.\n2. - Definition - of project processes.\n3. Review of project schedule.\n - Participants: John Smith, Jane Doe, Jim Dandy\n-It was - decided that the requirements need to be signed off by - product marketing.\n-Project processes were accepted.\n - -Project schedule needs to account for scheduled holidays - and employee vacation time. Check with HR for specific - dates.\n-New schedule will be distributed by Friday.\n- - Next weeks meeting is cancelled. No meeting until 3/23. - END:VJOURNAL - END:VCALENDAR - - The following is an example of published busy time information. The - iCalendar object might be placed in the network resource - www.host.com/calendar/busytime/jsmith.ifb. - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//RDU Software//NONSGML HandCal//EN - BEGIN:VFREEBUSY - - - -Dawson & Stenerson Standards Track [Page 139] - -RFC 2445 iCalendar November 1998 - - - ORGANIZER:MAILTO:jsmith@host.com - DTSTART:19980313T141711Z - DTEND:19980410T141711Z - FREEBUSY:19980314T233000Z/19980315T003000Z - FREEBUSY:19980316T153000Z/19980316T163000Z - FREEBUSY:19980318T030000Z/19980318T040000Z - URL:http://www.host.com/calendar/busytime/jsmith.ifb - END:VFREEBUSY - END:VCALENDAR - -6 Recommended Practices - - These recommended practices should be followed in order to assure - consistent handling of the following cases for an iCalendar object. - - 1. Content lines longer than 75 octets SHOULD be folded. - - 2. A calendar entry with a "DTSTART" property but no "DTEND" - property does not take up any time. It is intended to represent - an event that is associated with a given calendar date and time - of day, such as an anniversary. Since the event does not take up - any time, it MUST NOT be used to record busy time no matter what - the value for the "TRANSP" property. - - 3. When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and - "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for - "VTODO" calendar components, have the same value data type (e.g., - DATE-TIME), they SHOULD specify values in the same time format - (e.g., UTC time format). - - 4. When the combination of the "RRULE" and "RDATE" properties on an - iCalendar object produces multiple instances having the same - start date/time, they should be collapsed to, and considered as, - a single instance. - - 5. When a calendar user receives multiple requests for the same - calendar component (e.g., REQUEST for a "VEVENT" calendar - component) as a result of being on multiple mailing lists - specified by "ATTENDEE" properties in the request, they SHOULD - respond to only one of the requests. The calendar user SHOULD - also specify (using the "MEMBER" parameter of the "ATTENDEE" - property) which mailing list they are a member of. - - 6. An implementation can truncate a "SUMMARY" property value to 255 - characters. - - - - - - -Dawson & Stenerson Standards Track [Page 140] - -RFC 2445 iCalendar November 1998 - - - 7. If seconds of the minute are not supported by an implementation, - then a value of "00" SHOULD be specified for the seconds - component in a time value. - - 8. If the value type parameter (VALUE=) contains an unknown value - type, it SHOULD be treated as TEXT. - - 9. TZURL values SHOULD NOT be specified as a FILE URI type. This URI - form can be useful within an organization, but is problematic in - the Internet. - - 10. Some possible English values for CATEGORIES property include - "ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION", - "HOLIDAY", "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT - IN OFFICE", "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL - OCCASION", "TRAVEL", "VACATION". Categories can be specified in - any registered language. - - 11. Some possible English values for RESOURCES property include - "CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", "OVERHEAD - PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", "VIDEO - PHONE", "VEHICLE". Resources can be specified in any registered - language. - -7 Registration of Content Type Elements - - This section provides the process for registration of MIME - Calendaring and Scheduling Content Type iCalendar object methods and - new or modified properties. - -7.1 Registration of New and Modified iCalendar Object Methods - - New MIME Calendaring and Scheduling Content Type iCalendar object - methods are registered by the publication of an IETF Request for - Comments (RFC). Changes to an iCalendar object method are registered - by the publication of a revision of the RFC defining the method. - -7.2 Registration of New Properties - - This section defines procedures by which new properties or enumerated - property values for the MIME Calendaring and Scheduling Content Type - can be registered with the IANA. Non-IANA properties can be used by - bilateral agreement, provided the associated properties names follow - the "X-" convention. - - The procedures defined here are designed to allow public comment and - review of new properties, while posing only a small impediment to the - definition of new properties. - - - -Dawson & Stenerson Standards Track [Page 141] - -RFC 2445 iCalendar November 1998 - - - Registration of a new property is accomplished by the following - steps. - -7.2.1 Define the property - - A property is defined by completing the following template. - - To: ietf-calendar@imc.org - - Subject: Registration of text/calendar MIME property XXX - - Property name: - - Property purpose: - - Property value type(s): - - Property parameter (s): - - Conformance: - - Description: - - Format definition: - - Examples: - - The meaning of each field in the template is as follows. - - Property name: The name of the property, as it will appear in the - body of an text/calendar MIME Content-Type "property: value" line to - the left of the colon ":". - - Property purpose: The purpose of the property (e.g., to indicate a - delegate for the event or to-do, etc.). Give a short but clear - description. - - Property value type (s): Any of the valid value types for the - property value needs to be specified. The default value type also - needs to be specified. If a new value type is specified, it needs to - be declared in this section. - - Property parameter (s): Any of the valid property parameters for the - property needs to be specified. - - Conformance: The calendar components that the property can appear in - needs to be specified. - - - - -Dawson & Stenerson Standards Track [Page 142] - -RFC 2445 iCalendar November 1998 - - - Description: Any special notes about the property, how it is to be - used, etc. - - Format definition: The ABNF for the property definition needs to be - specified. - - Examples: One or more examples of instances of the property needs to - be specified. - -7.2.2 Post the Property definition - - The property description MUST be posted to the new property - discussion list, ietf-calendar@imc.org. - -7.2.3 Allow a comment period - - Discussion on the new property MUST be allowed to take place on the - list for a minimum of two weeks. Consensus MUST be reached on the - property before proceeding to the next step. - -7.2.4 Submit the property for approval - - Once the two-week comment period has elapsed, and the proposer is - convinced consensus has been reached on the property, the - registration application should be submitted to the Method Reviewer - for approval. The Method Reviewer is appointed to the Application - Area Directors and can either accept or reject the property - registration. An accepted registration should be passed on by the - Method Reviewer to the IANA for inclusion in the official IANA method - registry. The registration can be rejected for any of the following - reasons. 1) Insufficient comment period; 2) Consensus not reached; 3) - Technical deficiencies raised on the list or elsewhere have not been - addressed. The Method Reviewer's decision to reject a property can be - appealed by the proposer to the IESG, or the objections raised can be - addressed by the proposer and the property resubmitted. - -7.3 Property Change Control - - Existing properties can be changed using the same process by which - they were registered. - - 1. Define the change - - 2. Post the change - - 3. Allow a comment period - - 4. Submit the property for approval - - - -Dawson & Stenerson Standards Track [Page 143] - -RFC 2445 iCalendar November 1998 - - - Note that the original author or any other interested party can - propose a change to an existing property, but that such changes - should only be proposed when there are serious omissions or errors in - the published memo. The Method Reviewer can object to a change if it - is not backward compatible, but is not required to do so. - - Property definitions can never be deleted from the IANA registry, but - properties which are no longer believed to be useful can be declared - OBSOLETE by a change to their "intended use" field. - -8 References - - [IMIP] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar - Message-based Interoperability Protocol (IMIP)", RFC 2447, - November 1998. - - [ITIP] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson, - "iCalendar Transport-Independent Interoperability Protocol - (iTIP) : Scheduling Events, Busy Time, To-dos and Journal - Entries", RFC 2446, November 1998. - - [ISO 8601] ISO 8601, "Data elements and interchange formats- - Information interchange--Representation of dates and - times", International Organization for Standardization, - June, 1988. - - [ISO 9070] ISO/IEC 9070, "Information Technology_SGML Support - Facilities--Registration Procedures for Public Text Owner - Identifiers", Second Edition, International Organization - for Standardization, April 1991. - - [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet - Text Messages", STD 11, RFC 822, August 1982. - - [RFC 1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform - Resource Locators (URL)", RFC 1738, December 1994. - - [RFC 1766] Alvestrand, H., "Tags for the Identification of - Languages", RFC 1766, March 1995. - - [RFC 2045] Freed, N. and N. Borenstein, " Multipurpose Internet Mail - Extensions (MIME) - Part One: Format of Internet Message - Bodies", RFC 2045, November 1996. - - [RFC 2046] Freed, N. and N. Borenstein, " Multipurpose Internet Mail - Extensions (MIME) - Part Two: Media Types", RFC 2046, - November 1996. - - - - -Dawson & Stenerson Standards Track [Page 144] - -RFC 2445 iCalendar November 1998 - - - [RFC 2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose - Internet Mail Extensions (MIME) - Part Four: Registration - Procedures", RFC 2048, January 1997. - - [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC 2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", RFC 2279, January 1998. - - [RFC 2425] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type - for Directory Information", RFC 2425, September 1998. - - [RFC 2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", - RFC 2426, September 1998. - - [TZ] Olson, A.D., et al, Time zone code and data, - ftp://elsie.nci.nih.gov/pub/, updated periodically. - - [VCAL] Internet Mail Consortium, "vCalendar - The Electronic - Calendaring and Scheduling Exchange Format", - http://www.imc.org/pdi/vcal-10.txt, September 18, 1996. - -9 Acknowledgments - - A hearty thanks to the IETF Calendaring and Scheduling Working Group - and also the following individuals who have participated in the - drafting, review and discussion of this memo: - - Roland Alden, Harald T. Alvestrand, Eric Berman, Denis Bigorgne, John - Binici, Bill Bliss, Philippe Boucher, Steve Carter, Andre - Courtemanche, Dave Crocker, David Curley, Alec Dun, John Evans, Ross - Finlayson, Randell Flint, Ned Freed, Patrik Faltstrom, Chuck - Grandgent, Mark Handley, Steve Hanna, Paul B. Hill, Paul Hoffman, - Ross Hopson, Mark Horton, Daryl Huff, Bruce Kahn, C. Harald Koch, - Ryan Jansen, Don Lavange, Antoine Leca, Theodore Lorek, Steve - Mansour, Skip Montanaro, Keith Moore, Cecil Murray, Chris Newman, - John Noerenberg, Ralph Patterson, Pete Resnick, Keith Rhodes, Robert - Ripberger, John Rose, Doug Royer, Andras Salamar, Ted Schuh, Vinod - Seraphin, Derrick Shadel, Ken Shan, Andrew Shuman, Steve Silverberg, - William P. Spencer, John Sun, Mark Towfiq, Yvonne Tso, Robert Visnov, - James L. Weiner, Mike Weston, William Wyatt. - - - - - - -Dawson & Stenerson Standards Track [Page 145] - -RFC 2445 iCalendar November 1998 - - -10 Authors' and Chairs' Addresses - - The following address information is provided in a MIME-VCARD, - Electronic Business Card, format. - - The authors of this memo are: - - BEGIN:VCARD - VERSION:3.0 - N:Dawson;Frank - FN:Frank Dawson - ORG:Lotus Development Corporation - ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive; - Raleigh;NC;27613-3502;USA - TEL;TYPE=WORK,MSG:+1-919-676-9515 - TEL;TYPE=WORK,FAX:+1-919-676-9564 - EMAIL;TYPE=PREF,INTERNET:Frank_Dawson@Lotus.com - EMAIL;TYPE=INTERNET:fdawson@earthlink.net - URL:http://home.earthlink.net/~fdawson - END:VCARD - - BEGIN:VCARD - VERSION:3.0 - N:Stenerson;Derik - FN:Derik Stenerson - ORG:Microsoft Corporation - ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way; - Redmond;WA;98052-6399;USA - TEL;TYPE=WORK,MSG:+1-425-936-5522 - TEL;TYPE=WORK,FAX:+1-425-936-7329 - EMAIL;TYPE=INTERNET:deriks@Microsoft.com - END:VCARD - - The iCalendar object is a result of the work of the Internet - Engineering Task Force Calendaring and Scheduling Working Group. The - chairmen of that working group are: - - BEGIN:VCARD - VERSION:3.0 - N:Ganguly;Anik - FN:Anik Ganguly - ORG: Open Text Inc. - ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road; - Livonia;MI;48152;USA - TEL;TYPE=WORK,MSG:+1-734-542-5955 - EMAIL;TYPE=INTERNET:ganguly@acm.org - END:VCARD - - - - -Dawson & Stenerson Standards Track [Page 146] - -RFC 2445 iCalendar November 1998 - - - The co-chairman of that working group is: - - BEGIN:VCARD - VERSION:3.0 - N:Moskowitz;Robert - FN:Robert Moskowitz - EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com - END:VCARD - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Dawson & Stenerson Standards Track [Page 147] - -RFC 2445 iCalendar November 1998 - - -11. Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Dawson & Stenerson Standards Track [Page 148] - diff --git a/etc/rfc2446.pdf b/etc/rfc2446.pdf deleted file mode 100644 index 0dad4f8..0000000 Binary files a/etc/rfc2446.pdf and /dev/null differ diff --git a/etc/rfc2446.txt b/etc/rfc2446.txt deleted file mode 100644 index 8e038a2..0000000 --- a/etc/rfc2446.txt +++ /dev/null @@ -1,6107 +0,0 @@ - - - - - - -Network Working Group S. Silverberg -Request for Comments: 2446 Microsoft -Category: Standards Track S. Mansour - Netscape - F. Dawson - Lotus - R. Hopson - ON Technologies - November 1998 - - - iCalendar Transport-Independent Interoperability Protocol - (iTIP) - Scheduling Events, BusyTime, To-dos and Journal Entries - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - This document specifies how calendaring systems use iCalendar objects - to interoperate with other calendar systems. It does so in a general - way so as to allow multiple methods of communication between systems. - Subsequent documents specify interoperable methods of communications - between systems that use this protocol. - - The document outlines a model for calendar exchange that defines both - static and dynamic event, to-do, journal and free/busy objects. - Static objects are used to transmit information from one entity to - another without the expectation of continuity or referential - integrity with the original item. Dynamic objects are a superset of - static objects and will gracefully degrade to their static - counterparts for clients that only support static objects. - - This document specifies an Internet protocol based on the iCalendar - object specification that provides scheduling interoperability - between different calendar systems. The Internet protocol is called - the "iCalendar Transport-Independent Interoperability Protocol - (iTIP)". - - - -Silverberg, et. al. Standards Track [Page 1] - -RFC 2446 iTIP November 1998 - - - iTIP complements the iCalendar object specification by adding - semantics for group scheduling methods commonly available in current - calendar systems. These scheduling methods permit two or more - calendar systems to perform transactions such as publish, schedule, - reschedule, respond to scheduling requests, negotiation of changes or - cancel iCalendar-based calendar components. - - iTIP is defined independent of the particular transport used to - transmit the scheduling information. Companion memos to iTIP provide - bindings of the interoperability protocol to a number of Internet - protocols. - -Table of Contents - - 1 INTRODUCTION...................................................5 - 1.1 FORMATTING CONVENTIONS .....................................5 - 1.2 RELATED DOCUMENTS ..........................................6 - 1.3 ITIP ROLES AND TRANSACTIONS ................................6 - 2 INTEROPERABILITY MODELS........................................8 - 2.1 APPLICATION PROTOCOL .......................................9 - 2.1.1 Calendar Entry State ...................................9 - 2.1.2 Delegation .............................................9 - 2.1.3 Acting on Behalf of other Calendar Users ..............10 - 2.1.4 Component Revisions ...................................10 - 2.1.5 Message Sequencing ....................................11 - 3 APPLICATION PROTOCOL ELEMENTS.................................12 - 3.1 COMMON COMPONENT RESTRICTION TABLES .......................13 - 3.2 METHODS FOR VEVENT CALENDAR COMPONENTS ....................14 - 3.2.1 PUBLISH ...............................................15 - 3.2.2 REQUEST ...............................................17 - 3.2.2.1 Rescheduling an Event..............................19 - 3.2.2.2 Updating or Reconfirmation of an Event.............19 - 3.2.2.3 Delegating an Event to another CU..................19 - 3.2.2.4 Changing the Organizer.............................20 - 3.2.2.5 Sending on Behalf of the Organizer.................20 - 3.2.2.6 Forwarding to An Uninvited CU......................20 - 3.2.2.7 Updating Attendee Status...........................21 - 3.2.3 REPLY .................................................21 - 3.2.4 ADD ...................................................23 - 3.2.5 CANCEL ................................................25 - 3.2.6 REFRESH ...............................................26 - 3.2.7 COUNTER ...............................................28 - 3.2.8 DECLINECOUNTER ........................................29 - 3.3 METHODS FOR VFREEBUSY COMPONENTS ..........................31 - 3.3.1 PUBLISH ...............................................32 - 3.3.2 REQUEST ...............................................33 - 3.3.3 REPLY .................................................34 - 3.4 METHODS FOR VTODO COMPONENTS ..............................35 - - - -Silverberg, et. al. Standards Track [Page 2] - -RFC 2446 iTIP November 1998 - - - 3.4.1 PUBLISH ...............................................35 - 3.4.2 REQUEST ...............................................37 - 3.4.2.1 REQUEST for Rescheduling a VTODO...................39 - 3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO....39 - 3.4.2.3 REQUEST for Delegating a VTODO.....................40 - 3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User....40 - 3.4.2.5 REQUEST Updated Attendee Status....................41 - 3.4.3 REPLY .................................................41 - 3.4.4 ADD ...................................................43 - 3.4.5 CANCEL ................................................44 - 3.4.6 REFRESH ...............................................46 - 3.4.7 COUNTER ...............................................48 - 3.4.8 DECLINECOUNTER ........................................49 - 3.5 METHODS FOR VJOURNAL COMPONENTS ...........................50 - 3.5.1 PUBLISH ...............................................51 - 3.5.2 ADD ...................................................52 - 3.5.3 CANCEL ................................................53 - 3.6 STATUS REPLIES ............................................55 - 3.7 IMPLEMENTATION CONSIDERATIONS .............................57 - 3.7.1 Working With Recurrence Instances .....................57 - 3.7.2 Attendee Property Considerations ......................58 - 3.7.3 X-Tokens ..............................................59 - 4 EXAMPLES......................................................59 - 4.1 PUBLISHED EVENT EXAMPLES ..................................59 - 4.1.1 A Minimal Published Event .............................60 - 4.1.2 Changing A Published Event ............................60 - 4.1.3 Canceling A Published Event ...........................61 - 4.1.4 A Rich Published Event ................................62 - 4.1.5 Anniversaries or Events attached to entire days .......63 - 4.2 GROUP EVENT EXAMPLES ......................................63 - 4.2.1 A Group Event Request .................................64 - 4.2.2 Reply To A Group Event Request ........................65 - 4.2.3 Update An Event .......................................65 - 4.2.4 Countering an Event Proposal ..........................66 - 4.2.5 Delegating an Event ...................................68 - 4.2.6 Delegate Accepts the Meeting ..........................70 - 4.2.7 Delegate Declines the Meeting .........................71 - 4.2.8 Forwarding an Event Request ...........................72 - 4.2.9 Cancel A Group Event ..................................72 - 4.2.10 Removing Attendees ...................................74 - 4.2.11 Replacing the Organizer ..............................75 - 4.3 BUSY TIME EXAMPLES ........................................76 - 4.3.1 Request Busy Time .....................................77 - 4.3.2 Reply To A Busy Time Request ..........................77 - 4.4 RECURRING EVENT AND TIME ZONE EXAMPLES ....................78 - 4.4.1 A Recurring Event Spanning Time Zones .................78 - 4.4.2 Modify A Recurring Instance ...........................79 - 4.4.3 Cancel an Instance ....................................81 - - - -Silverberg, et. al. Standards Track [Page 3] - -RFC 2446 iTIP November 1998 - - - 4.4.4 Cancel Recurring Event ................................81 - 4.4.5 Change All Future Instances ...........................82 - 4.4.6 Add A New Instance To A Recurring Event ...............82 - 4.4.7 Add A New Series of Instances To A Recurring Event ....83 - 4.4.8 Counter An Instance Of A Recurring Event ..............87 - 4.4.9 Error Reply To A Request ..............................88 - 4.5 GROUP TO-DO EXAMPLES ......................................89 - 4.5.1 A VTODO Request .......................................90 - 4.5.2 A VTODO Reply .........................................90 - 4.5.3 A VTODO Request for Updated Status ....................91 - 4.5.4 A Reply: Percent-Complete .............................91 - 4.5.5 A Reply: Completed ....................................92 - 4.5.6 An Updated VTODO Request ..............................92 - 4.5.7 Recurring VTODOs ......................................92 - 4.5.7.1 Request for a Recurring VTODO......................93 - 4.5.7.2 Calculating due dates in recurring VTODOs..........93 - 4.5.7.3 Replying to an instance of a recurring VTODO.......93 - 4.6 JOURNAL EXAMPLES ..........................................94 - 4.7 OTHER EXAMPLES ............................................94 - 4.7.1 Event Refresh .........................................94 - 4.7.2 Bad RECURRENCE-ID .....................................95 - 5 APPLICATION PROTOCOL FALLBACKS................................97 - 5.1 PARTIAL IMPLEMENTATION ....................................97 - 5.1.1 Event-Related Fallbacks ...............................97 - 5.1.2 Free/Busy-Related Fallbacks ...........................99 - 5.1.3 To-Do-Related Fallbacks ...............................99 - 5.1.4 Journal-Related Fallbacks ............................101 - 5.2 LATENCY ISSUES ...........................................102 - 5.2.1 Cancellation of an Unknown Calendar Component. .......102 - 5.2.2 Unexpected Reply from an Unknown Delegate ............103 - 5.3 SEQUENCE NUMBER ..........................................103 - 6 SECURITY CONSIDERATIONS......................................103 - 6.1 SECURITY THREATS .........................................103 - 6.1.1 Spoofing the "Organizer" .............................103 - 6.1.2 Spoofing the "Attendee" ..............................103 - 6.1.3 Unauthorized Replacement of the Organizer ............104 - 6.1.4 Eavesdropping ........................................104 - 6.1.5 Flooding a Calendar ..................................104 - 6.1.6 Procedural Alarms ....................................104 - 6.1.7 Unauthorized REFRESH Requests ........................104 - 6.2 RECOMMENDATIONS ..........................................104 - 6.2.1 Use of [RFC-1847] to secure iTIP transactions ........105 - 6.2.2 Implementation Controls ..............................105 - 7 ACKNOWLEDGMENTS..............................................106 - 8 BIBLIOGRAPHY.................................................106 - 9 AUTHORS' ADDRESSES...........................................107 - 10 FULL COPYRIGHT STATEMENT....................................109 - - - - -Silverberg, et. al. Standards Track [Page 4] - -RFC 2446 iTIP November 1998 - - -1 Introduction - - This document specifies how calendaring systems use iCalendar objects - to interoperate with other calendar systems. In particular, it - specifies how to schedule events, to-dos, or daily journal entries. - It further specifies how to search for available busy time - information. It does so in a general way so as to allow multiple - methods of communication between systems. Subsequent documents - specify transport bindings between systems that use this protocol. - - This protocol is based on messages sent from an originator to one or - more recipients. For certain types of messages, a recipient may - reply, in order to update their status and may also return - transaction/request status information. The protocol supports the - ability for the message originator to modify or cancel the original - message. The protocol also supports the ability for recipients to - suggest changes to the originator of a message. The elements of the - protocol also define the user roles for its transactions. - -1.1 Formatting Conventions - - In order to refer to elements of the calendaring and scheduling - model, core object or interoperability protocol defined in [iCAL] and - [iTIP] several formatting conventions have been utilized. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this - document are to be interpreted as described in [RFC-2119]. - - Calendaring and scheduling roles are referred to in quoted-strings of - text with the first character of each word in upper case. For - example, "Organizer" refers to a role of a "Calendar User" (CU) - within the scheduling protocol defined by [iTIP]. Calendar components - defined by [iCAL] are referred to with capitalized, quoted-strings of - text. All calendar components start with the letter "V". For example, - "VEVENT" refers to the event calendar component, "VTODO" refers to - the to-do calendar component and "VJOURNAL" refers to the daily - journal calendar component. Scheduling methods defined by [iTIP] are - referred to with capitalized, quoted-strings of text. For example, - "REQUEST" refers to the method for requesting a scheduling calendar - component be created or modified, "REPLY" refers to the method a - recipient of a request uses to update their status with the - "Organizer" of the calendar component. - - Properties defined by [iCAL] are referred to with capitalized, - quoted-strings of text, followed by the word "property". For example, - "ATTENDEE" property refers to the iCalendar property used to convey - the calendar address of a "Calendar User". Property parameters - - - -Silverberg, et. al. Standards Track [Page 5] - -RFC 2446 iTIP November 1998 - - - defined by this memo are referred to with lower case, quoted-strings - of text, followed by the word "parameter". For example, "value" - parameter refers to the iCalendar property parameter used to override - the default data type for a property value. Enumerated values defined - by this memo are referred to with capitalized text, either alone or - followed by the word "value". - - In tables, the quoted-string text is specified without quotes in - order to minimize the table length. - -1.2 Related Documents - - Implementers will need to be familiar with several other memos that, - along with this one, describe the Internet calendaring and scheduling - standards. This document, [iTIP], specifies an interoperability - protocol for scheduling between different implementations. The - related documents are: - - [iCAL] - specifies the objects, data types, properties and - property parameters used in the protocols, along with the - methods for representing and encoding them; - - [iMIP] specifies an Internet email binding for [iTIP]. - - This memo does not attempt to repeat the specification of concepts or - definitions from these other memos. Where possible, references are - made to the memo that provides for the specification of these - concepts or definitions. - -1.3 ITIP Roles and Transactions - - ITIP defines methods for exchanging [iCAL] objects for the purposes - of group calendaring and scheduling between "Calendar Users" (CUs). - CUs take on one of two roles in iTIP. The CU who initiates an - exchange takes on the role of "Organizer". For example, the CU who - proposes a group meeting is the "Organizer". The CUs asked to - participate in the group meeting by the "Organizer" take on the role - of "Attendee". Note that "role" is also a descriptive parameter to - the _ATTENDEE_ property. Its use is to convey descriptive context to - an "Attendee" such as "chair", "req-participant" or "non-participant" - and has nothing to do with the calendaring workflow. - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 6] - -RFC 2446 iTIP November 1998 - - - The ITIP methods are listed below and their usage and semantics are - defined in section 3 of this document. - - +================+==================================================+ - | Method | Description | - |================+==================================================| - | PUBLISH | Used to publish a calendar entry to one or more | - | | Calendar Users. There is no interactivity | - | | between the publisher and any other calendar | - | | user. An example might include a baseball team | - | | publishing its schedule to the public. | - | | | - | REQUEST | Used to schedule a calendar entry with other | - | | Calendar Users. Requests are interactive in that | - | | they require the receiver to respond using | - | | the Reply methods. Meeting Requests, Busy | - | | Time requests and the assignment of VTODOs to | - | | other Calendar Users are all examples. | - | | Requests are also used by the "Organizer" to | - | | update the status of a calendar entry. | - | | | - | REPLY | A Reply is used in response to a Request to | - | | convey "Attendee" status to the "Organizer". | - | | Replies are commonly used to respond to meeting | - | | and task requests. | - | | | - | ADD | Add one or more instances to an existing | - | | VEVENT, VTODO, or VJOURNAL. | - | | | - | CANCEL | Cancel one or more instances of an existing | - | | VEVENT, VTODO, or VJOURNAL. | - | | | - | REFRESH | The Refresh method is used by an "Attendee" to | - | | request the latest version of a calendar entry. | - | | | - | COUNTER | The Counter method is used by an "Attendee" to | - | | negotiate a change in the calendar entry. | - | | Examples include the request to change a | - | | proposed Event time or change the due date for a | - | | VTODO. | - | | | - | DECLINE- | Used by the "Organizer" to decline the proposed | - | COUNTER | counter-proprosal. | - +================+==================================================+ - - - - - - - -Silverberg, et. al. Standards Track [Page 7] - -RFC 2446 iTIP November 1998 - - - Group scheduling in iTIP is accomplished using the set of "request" - and "response" methods described above. The following table shows the - methods broken down by who can send them. - - +================+==================================================+ - | Originator | Methods | - |================+==================================================| - | Organizer | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER | - | | | - | Attendee | REPLY, REFRESH, COUNTER | - | | REQUEST only when delegating | - +================+==================================================+ - - Note that for some calendar component types, the allowable methods - are a subset of the above set. - -2 Interoperability Models - - There are two distinct protocols relevant to interoperability: an - "Application Protocol" and a "Transport Protocol". The Application - Protocol defines the content of the iCalendar objects sent between - sender and receiver to accomplish the scheduling transactions listed - above. The Transport Protocol defines how the iCalendar objects are - sent between the sender and receiver. This document focuses on the - Application Protocol. Binding documents such as [iMIP] focus on the - Transport Protocol. - - The connection between Sender and Receiver in the diagram below - refers to the Application Protocol. The iCalendar objects passed from - the Sender to the Receiver are presented in Section 3, Application - Protocol Elements. - - +----------+ +----------+ - | | iTIP | | - | Sender |<-------------------->| Receiver | - | | | | - +----------+ +----------+ - - There are several variations of this diagram in which the Sender and - Receiver take on various roles of a "Calendar User Agent" (CUA) or a - "Calendar Service" (CS). - - The architecture of iTIP is depicted in the diagram below. An - application written to this specification may work with bindings for - the store-and-forward transport, the real time transport, or both. - Also note that iTIP could be bound to other transports. - - - - - -Silverberg, et. al. Standards Track [Page 8] - -RFC 2446 iTIP November 1998 - - - +------------------------------------------+ - | iTIP | - +------------------------------------------+ - |Real-time | Store-and-Fwd | Other | - |Transport | Transport | Transports... | - +------------------------------------------+ - -2.1 Application Protocol - - In the iTIP model, a calendar entry is created and managed by an - "Organizer". The "Organizer" interacts with other CUs by sending one - or more of the iTIP messages listed above. "Attendees" use the - "REPLY" method to communicate their status. "Attendees" do not make - direct changes to the master calendar entry. They can, however, use - the "COUNTER" method to suggest changes to the "Organizer". In any - case, the "Organizer" has complete control over the master calendar - entry. - -2.1.1 Calendar Entry State - - There are two distinct states relevant to calendar entries: the - overall state of the entry and the state associated with an - "Attendee" to that entry. - - The state of an entry is defined by the "STATUS" property and is - controlled by the "Organizer." There is no default value for the - "STATUS" property. The "Organizer" sets the "STATUS" property to the - appropriate value for each calendar entry. - - The state of a particular "Attendee" relative to an entry is defined - by the "partstat" parameter in the "ATTENDEE" property for each - "Attendee". When an "Organizer" issues the initial entry, "Attendee" - status is unknown. The "Organizer" specifies this by setting the - "partstat" parameter to "NEEDS-ACTION". Each "Attendee" modifies - their "ATTENDEE" property "partstat" parameter to an appropriate - value as part of a "REPLY" message sent back to the "Organizer". - -2.1.2 Delegation - - Delegation is defined as the process by which an "Attendee" grants - another CU (or several CUs) the right to attend on their behalf. The - "Organizer" is made aware of this change because the delegating - "Attendee" informs the "Organizer". These steps are detailed in the - REQUEST method section. - - - - - - - -Silverberg, et. al. Standards Track [Page 9] - -RFC 2446 iTIP November 1998 - - -2.1.3 Acting on Behalf of other Calendar Users - - In many organizations one user will act on behalf of another to - organize and/or respond to meeting requests. ITIP provides two - mechanisms that support these activities. - - First, the "Organizer" is treated as a special entity, separate from - "Attendees". All responses from "Attendees" flow to the "Organizer", - making it easy to separate a calendar user organizing a meeting from - calendar users attending the meeting. Additionally, iCalendar - provides descriptive roles for each "Attendee". For instance, a role - of "chair" may be ascribed to one or more "Attendees". The "chair" - and the "Organizer" may or may not be the same calendar user. This - maps well to scenarios where an assistant may manage meeting - logistics for another individual who chairs a meeting. - - Second, a "sent-by" parameter may be specified in either the - "Organizer" or "Attendee" properties. When specified, the "sent-by" - parameter indicates that the responding CU acted on behalf of the - specified "Attendee" or "Organizer". - -2.1.4 Component Revisions - - The "SEQUENCE" property is used by the "Organizer" to indicate - revisions to the calendar component. The rules for incrementing the - "SEQUENCE" number are defined in [iCAL]. For clarity, these rules are - paraphrased here in terms of how they are applied in [iTIP]. For a - given "UID" in a calendar component: - - . For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property - value is incremented according to the rules defined in [iCAL]. - - . The "SEQUENCE" property value MUST be incremented each time the - "Organizer" uses the "ADD" or "CANCEL" methods. - - . The "SEQUENCE" property value MUST NOT be incremented when using - "REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a - delegation "REQUEST". - - In some circumstances the "Organizer" may not have received responses - to the final revision sent out. In this situation, the "Organizer" - may wish to send an update "REQUEST", and set "RSVP=TRUE" for all - "Attendees", so that current responses can be collected. - - - - - - - - -Silverberg, et. al. Standards Track [Page 10] - -RFC 2446 iTIP November 1998 - - - The value of the "SEQUENCE" property contained in a response from an - "Attendee" may not always match the "Organizer's" revision. - Implementations may choose to have the CUA indicate to the CU that - the response is to an entry that has been revised and allow the CU to - decide whether or not to accept the response. - -2.1.5 Message Sequencing - - CUAs that handle the [iTIP] application protocol must often correlate - a component in a calendar store with a component received in the - [iTIP] message. For example, an event may be updated with a later - revision of the same event. To accomplish this, a CUA must correlate - the version of the event already in its calendar store with the - version sent in the [iTIP] message. In addition to this correlation, - there are several factors that can cause [iTIP] messages to arrive in - an unexpected order. That is, an "Organizer" could receive a reply - to an earlier revision of a component AFTER receiving a reply to a - later revision. - - To maximize interoperability and to handle messages that arrive in an - unexpected order, use the following rules: - - 1. The primary key for referencing a particular iCalendar component - is the "UID" property value. To reference an instance of a - recurring component, the primary key is composed of the "UID" and - the "RECURRENCE-ID" properties. - - 2. The secondary key for referencing a component is the "SEQUENCE" - property value. For components where the "UID" is the same, the - component with the highest numeric value for the "SEQUENCE" - property obsoletes all other revisions of the component with - lower values. - - 3. "Attendees" send "REPLY" messages to the "Organizer". For - replies where the "UID" property value is the same, the value of - the "SEQUENCE" property indicates the revision of the component - to which the "Attendee" is replying. The reply with the highest - numeric value for the "SEQUENCE" property obsoletes all other - replies with lower values. - - 4. In situations where the "UID" and "SEQUENCE" properties match, - the "DTSTAMP" property is used as the tie-breaker. The component - with the latest "DTSTAMP" overrides all others. Similarly, for - "Attendee" responses where the "UID" property values match and - the "SEQUENCE" property values match, the response with the - latest "DTSTAMP" overrides all others. - - - - - -Silverberg, et. al. Standards Track [Page 11] - -RFC 2446 iTIP November 1998 - - - Hence, CUAs must persist the following component properties: "UID", - "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each - "ATTENDEE" property of a component CUAs must persist the "SEQUENCE" - and "DTSTAMP" property values associated with the "Attendee's" - response. - -3 Application Protocol Elements - - ITIP messages are "text/calendar" MIME entities that contain - calendaring and scheduling information. The particular type of [iCAL] - message is referred to as the "method type". Each method type is - identified by a "METHOD" property specified as part of the - "text/calendar" content type. The table below shows various - combinations of calendar components and the method types that this - memo supports. - - +=================================================+ - | | VEVENT | VTODO | VJOURNAL | VFREEBUSY | - |=================================================| - |Publish | Yes | Yes | Yes | Yes | - |Request | Yes | Yes | No | Yes | - |Refresh | Yes | Yes | No | No | - |Cancel | Yes | Yes | Yes | No | - |Add | Yes | Yes | Yes | No | - |Reply | Yes | Yes | No | Yes | - |Counter | Yes | Yes | No | No | - |Decline- | | | | | - |Counter | Yes | Yes | No | No | - +=================================================+ - - Each method type is defined in terms of its associated components and - properties. Some components and properties are required, some are - optional and others are excluded. The restrictions are expressed in - this document using a simple "restriction table". The first column - indicates the name of a component or property. Properties of the - iCalendar object are not indented. Properties of a component are - indented. The second column contains "MUST" if the component or - property must be present, "MAY" if the component or property is - optional, and "NOT" if the component or property must not be present. - Entries in the second column sometimes contain comments for further - clarification. - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 12] - -RFC 2446 iTIP November 1998 - - -3.1 Common Component Restriction Tables - - The restriction table below applies to properties of the iCalendar - object. That is, the properties at the outermost scope. The presence - column uses the following values to assert whether a property is - required, is optional and the number of times it may appear in the - iCalendar object. - - Presence Value Description - -------------------------------------------------------------- - 1 One instance MUST be present - 1+ At least one instance MUST be present - 0 Instances of this property Must NOT be present - 0+ Multiple instances MAY be present - 0 or 1 Up to 1 instance of this property MAY be present - --------------------------------------------------------------- - - The tables also call out "X-PROPERTY" and "X-COMPONENT" to show - where vendor-specific properties and components can appear. The - tables do not lay out the restrictions of property parameters. Those - restrictions are defined in [iCAL]. - - Component/Property Presence - ------------------- ---------------------------------------------- - CALSCALE 0 or 1 - PRODID 1 - VERSION 1 Value MUST be "2.0" - X-PROPERTY 0+ - - - DateTime values MAY refer to a "VTIMEZONE" component. The property - restrictions in the table below apply to any "VTIMEZONE" component in - an ITIP message. - - Component/Property Presence - ------------------- ---------------------------------------------- - VTIMEZONE 0+ MUST be present if any date/time refers - to timezone - DAYLIGHT 0+ MUST be one or more of either STANDARD or - DAYLIGHT - COMMENT 0 or 1 - DTSTART 1 MUST be local time format - RDATE 0+ if present RRULE MUST NOT be present - RRULE 0+ if present RDATE MUST NOT be present - TZNAME 0 or 1 - TZOFFSET 1 - TZOFFSETFROM 1 - TZOFFSETTO 1 - - - -Silverberg, et. al. Standards Track [Page 13] - -RFC 2446 iTIP November 1998 - - - X-PROPERTY 0+ - LAST-MODIFIED 0 or 1 - STANDARD 0+ MUST be one or more of either STANDARD or - DAYLIGHT - COMMENT 0 or 1 - DTSTART 1 MUST be local time format - RDATE 0+ if present RRULE MUST NOT be present - RRULE 0+ if present RDATE MUST NOT be present - TZNAME 0 or 1 - TZOFFSETFROM 1 - TZOFFSETTO 1 - X-PROPERTY 0+ - TZID 1 - TZURL 0 or 1 - X-PROPERTY 0+ - - The property restrictions in the table below apply to any "VALARM" - component in an ITIP message. - - Component/Property Presence - ------------------- ---------------------------------------------- - VALARM 0+ - ACTION 1 - ATTACH 0+ - DESCRIPTION 0 or 1 - DURATION 0 or 1 if present REPEAT MUST be present - REPEAT 0 or 1 if present DURATION MUST be present - SUMMARY 0 or 1 - TRIGGER 1 - X-PROPERTY 0+ - -3.2 Methods for VEVENT Calendar Components - - This section defines the property set restrictions for the method - types that are applicable to the "VEVENT" calendar component. Each - method is defined using a table that clarifies the property - constraints that define the particular method. - - - - - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 14] - -RFC 2446 iTIP November 1998 - - - The following summarizes the methods that are defined for the - "VEVENT" calendar component. - - +================+==================================================+ - | Method | Description | - |================+==================================================| - | PUBLISH | Post notification of an event. Used primarily as | - | | a method of advertising the existence of an | - | | event. | - | | | - | REQUEST | Make a request for an event. This is an explicit | - | | invitation to one or more "Attendees". Event | - | | Requests are also used to update or change an | - | | existing event. Clients that cannot handle | - | | REQUEST may degrade the event to view it as an | - | | PUBLISH. | - | | | - | REPLY | Reply to an event request. Clients may set their | - | | status ("partstat") to ACCEPTED, DECLINED, | - | | TENTATIVE, or DELEGATED. | - | | | - | ADD | Add one or more instances to an existing event. | - | | | - | CANCEL | Cancel one or more instances of an existing | - | | event. | - | | | - | REFRESH | A request is sent to an "Organizer" by an | - | | "Attendee" asking for the latest version of an | - | | event to be resent to the requester. | - | | | - | COUNTER | Counter a REQUEST with an alternative proposal, | - | | Sent by an "Attendee" to the "Organizer". | - | | | - | DECLINECOUNTER | Decline a counter proposal. Sent to an | - | | "Attendee" by the "Organizer". | - +================+==================================================+ - -3.2.1 PUBLISH - - The "PUBLISH" method in a "VEVENT" calendar component is an - unsolicited posting of an iCalendar object. Any CU may add published - components to their calendar. The "Organizer" MUST be present in a - published iCalendar component. "Attendees" MUST NOT be present. Its - expected usage is for encapsulating an arbitrary event as an - iCalendar object. The "Organizer" may subsequently update (with - another "PUBLISH" method), add instances to (with an "ADD" method), - or cancel (with a "CANCEL" method) a previously published "VEVENT" - calendar component. - - - -Silverberg, et. al. Standards Track [Page 15] - -RFC 2446 iTIP November 1998 - - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST equal "PUBLISH" -VEVENT 1+ - DTSTAMP 1 - DTSTART 1 - ORGANIZER 1 - SUMMARY 1 Can be null. - UID 1 - RECURRENCE-ID 0 or 1 only if referring to an instance of a - recurring calendar component. Otherwise - it MUST NOT be present. - SEQUENCE 0 or 1 MUST be present if value is greater than - 0, MAY be present if 0 - ATTACH 0+ - CATEGORIES 0 or 1 This property may contain a list of - values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 Can be null - DTEND 0 or 1 if present DURATION MUST NOT be present - DURATION 0 or 1 if present DTEND MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PRIORITY 0 or 1 - RDATE 0+ - RELATED-TO 0+ - RESOURCES 0 or 1 This property MAY contain a list of values - RRULE 0+ - STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED/CANCELLED - TRANSP 0 or 1 - URL 0 or 1 - X-PROPERTY 0+ - - ATTENDEE 0 - REQUEST-STATUS 0 - -VALARM 0+ -VFREEBUSY 0 -VJOURNAL 0 - - - -Silverberg, et. al. Standards Track [Page 16] - -RFC 2446 iTIP November 1998 - - -VTODO 0 -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -3.2.2 REQUEST - - The "REQUEST" method in a "VEVENT" component provides the following - scheduling functions: - - . Invite "Attendees" to an event; - . Reschedule an existing event; - . Response to a REFRESH request; - . Update the details of an existing event, without rescheduling it; - . Update the status of "Attendees" of an existing event, without - rescheduling it; - . Reconfirm an existing event, without rescheduling it; - . Forward a "VEVENT" to another uninvited CU. - . For an existing "VEVENT" calendar component, delegate the role of - "Attendee" to another CU; - . For an existing "VEVENT" calendar component, changing the role of - "Organizer" to another CU. - - The "Organizer" originates the "REQUEST". The recipients of the - "REQUEST" method are the CUs invited to the event, the "Attendees". - "Attendees" use the "REPLY" method to convey attendance status to the - "Organizer". - - The "UID" and "SEQUENCE" properties are used to distinguish the - various uses of the "REQUEST" method. If the "UID" property value in - the "REQUEST" is not found on the recipient's calendar, then the - "REQUEST" is for a new "VEVENT" calendar component. If the "UID" - property value is found on the recipient's calendar, then the - "REQUEST" is for a rescheduling, an update, or a reconfirm of the - "VEVENT" calendar component. - - For the "REQUEST" method, multiple "VEVENT" components in a single - iCalendar object are only permitted when for components with the same - "UID" property. That is, a series of recurring events may have - instance-specific information. In this case, multiple "VEVENT" - components are needed to express the entire series. - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 17] - -RFC 2446 iTIP November 1998 - - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence ------------------------------------------------------------------ -METHOD 1 MUST be "REQUEST" -VEVENT 1+ All components MUST have the same UID - ATTENDEE 1+ - DTSTAMP 1 - DTSTART 1 - ORGANIZER 1 - SEQUENCE 0 or 1 MUST be present if value is greater than 0, - MAY be present if 0 - SUMMARY 1 Can be null - UID 1 - - ATTACH 0+ - CATEGORIES 0 or 1 This property may contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 Can be null - DTEND 0 or 1 if present DURATION MUST NOT be present - DURATION 0 or 1 if present DTEND MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PRIORITY 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 only if referring to an instance of a - recurring calendar component. Otherwise it - MUST NOT be present. - RELATED-TO 0+ - REQUEST-STATUS 0+ - RESOURCES 0 or 1 This property MAY contain a list of values - RRULE 0+ - STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED - TRANSP 0 or 1 - URL 0 or 1 - X-PROPERTY 0+ - -VALARM 0+ -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - - - -Silverberg, et. al. Standards Track [Page 18] - -RFC 2446 iTIP November 1998 - - -VFREEBUSY 0 -VJOURNAL 0 -VTODO 0 - -3.2.2.1 Rescheduling an Event - - The "REQUEST" method may be used to reschedule an event. A - rescheduled event involves a change to the existing event in terms of - its time or recurrence intervals and possibly the location or - description. If the recipient CUA of a "REQUEST" method finds that - the "UID" property value already exists on the calendar, but that the - "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is - greater than the value for the existing event, then the "REQUEST" - method describes a rescheduling of the event. - -3.2.2.2 Updating or Reconfirmation of an Event - - The "REQUEST" method may be used to update or reconfirm an event. An - update to an existing event does not involve changes to the time or - recurrence intervals, and might not involve a change to the location - or description for the event. If the recipient CUA of a "REQUEST" - method finds that the "UID" property value already exists on the - calendar and that the "SEQUENCE" property value in the "REQUEST" is - the same as the value for the existing event, then the "REQUEST" - method describes an update of the event details, but no rescheduling - of the event. - - The update "REQUEST" method is the appropriate response to a - "REFRESH" method sent from an "Attendee" to the "Organizer" of an - event. - - The "Organizer" of an event may also send unsolicited "REQUEST" - methods. The unsolicited "REQUEST" methods may be used to update the - details of the event without rescheduling it, to update the - "partstat" parameter of "Attendees", or to reconfirm the event. - -3.2.2.3 Delegating an Event to another CU - - Some calendar and scheduling systems allow "Attendees" to delegate - their presence at an event to another calendar user. ITIP supports - this concept using the following workflow. Any "Attendee" may - delegate their right to participate in a calendar VEVENT to another - CU. The implication is that the delegate participates in lieu of the - original "Attendee"; NOT in addition to the "Attendee". The delegator - MUST notify the "Organizer" of this action using the steps outlined - below. Implementations may support or restrict delegation as they - see fit. For instance, some implementations may restrict a delegate - from delegating a "REQUEST" to another CU. - - - -Silverberg, et. al. Standards Track [Page 19] - -RFC 2446 iTIP November 1998 - - - The "Delegator" of an event forwards the existing "REQUEST" to the - "Delegate". The "REQUEST" method MUST include an "ATTENDEE" property - with the calendar address of the "Delegate". The "Delegator" MUST - also send a "REPLY" method to the "Organizer" with the "Delegator's" - "ATTENDEE" property "partstat" parameter value set to "delegated". In - addition, the "delegated-to" parameter MUST be included with the - calendar address of the "Delegate". - - In response to the request, the "Delegate" MUST send a "REPLY" method - to the "Organizer" and optionally, to the "Delegator". The "REPLY" - method " SHOULD include the "ATTENDEE" property with the "delegated- - from" parameter value of the "Delegator's" calendar address. - - The "Delegator" may continue to receive updates to the event even - though they will not be attending. This is accomplished by the - "Delegator" setting their "role" attribute to " NON-PARTICIPANT" in - the "REPLY" to the "Organizer" - -3.2.2.4 Changing the Organizer - - The situation may arise where the "Organizer" of a VEVENT is no - longer able to perform the "Organizer" role and abdicates without - passing on the "Organizer" role to someone else. When this occurs the - "Attendees" of the VEVENT may use out-of-band mechanisms to - communicate the situation and agree upon a new "Organizer". The new - "Organizer" should then send out a new "REQUEST" with a modified - version of the VEVENT in which the "SEQUENCE" number has been - incremented and value of the "ORGANIZER" property has been changed to - the calendar address of the new "Organizer". - -3.2.2.5 Sending on Behalf of the Organizer - - There are a number of scenarios that support the need for a calendar - user to act on behalf of the "Organizer" without explicit role - changing. This might be the case if the CU designated as "Organizer" - was sick or unable to perform duties associated with that function. - In these cases iTIP supports the notion of one CU acting on behalf of - another. Using the "sent-by" parameter, a calendar user could send an - updated "VEVENT" REQUEST. In the case where one CU sends on behalf of - another CU, the "Attendee" responses are still directed back towards - the CU designated as "Organizer". - -3.2.2.6 Forwarding to An Uninvited CU - - An "Attendee" invited to an event may invite another uninvited CU to - the event. The invited "Attendee" accomplishes this by forwarding the - original "REQUEST" method to the uninvited CU. The "Organizer" - decides whether or not the uninvited CU is added to the attendee - - - -Silverberg, et. al. Standards Track [Page 20] - -RFC 2446 iTIP November 1998 - - - list. If the "Organizer" decides not to add the uninvited CU no - further action is required, however the "Organizer" MAY send the - uninvited CU a "CANCEL" message. If the "Organizer" decides to add - an uninvited CU, a new "ATTENDEE" property is added for the uninvited - CU with its property parameters set as the "Organizer" deems - appropriate. When forwarding a "REQUEST" to another CU, the - forwarding "Attendee" MUST NOT make changes to the VEVENT property - set. - -3.2.2.7 Updating Attendee Status - - The "Organizer" of an event may also request updated status from one - or more "Attendees. The "Organizer" sends a "REQUEST" method to the - "Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The - "SEQUENCE" property for the event is not changed from its previous - value. A recipient will determine that the only change in the - "REQUEST" is that their "RSVP" property parameter indicates a request - for updated status. The recipient SHOULD respond with a "REPLY" - method indicating their current status with respect to the "REQUEST". - -3.2.3 REPLY - - The "REPLY" method in a "VEVENT" calendar component is used to - respond (e.g., accept or decline) to a "REQUEST" or to reply to a - delegation "REQUEST". When used to provide a delegation response, the - "Delegator" SHOULD include the calendar address of the "Delegate" on - the "delegated-to" property parameter of the "Delegator's" "ATTENDEE" - property. The "Delegate" SHOULD include the calendar address of the - "Delegator" on the "delegated-from" property parameter of the - "Delegate's" "ATTENDEE" property. - - The "REPLY" method may also be used to respond to an unsuccessful - "REQUEST" method. Depending on the value of the "REQUEST-STATUS" - property no scheduling action may have been performed. - - The "Organizer" of an event may receive the "REPLY" method from a CU - not in the original "REQUEST". For example, a "REPLY" may be received - from a "Delegate" to an event. In addition, the "REPLY" method may be - received from an unknown CU (a "Party Crasher"). This uninvited - "Attendee" may be accepted, or the "Organizer" may cancel the event - for the uninvited "Attendee" by sending a "CANCEL" method to the - uninvited "Attendee". - - An "Attendee" can include a message to the "Organizer" using the - "COMMENT" property. For example, if the user indicates tentative - acceptance and wants to let the "Organizer" know why, the reason can - be expressed in the "COMMENT" property value. - - - - -Silverberg, et. al. Standards Track [Page 21] - -RFC 2446 iTIP November 1998 - - - The "Organizer" may also receive a "REPLY" from one CU on behalf of - another. Like the scenario enumerated above for the "Organizer", - "Attendees" may have another CU respond on their behalf. This is done - using the "sent-by" parameter. - - The optional properties listed in the table below (those listed as - "0+" or "0 or 1") MUST NOT be changed from those of the original - request. If property changes are desired the COUNTER message must be - used. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "REPLY" -VEVENT 1+ All components MUST have the same UID - ATTENDEE 1 MUST be the address of the Attendee - replying. - DTSTAMP 1 - ORGANIZER 1 - RECURRENCE-ID 0 or 1 only if referring to an instance of a - recurring calendar component. Otherwise - it must NOT be present. - UID 1 MUST be the UID of the original REQUEST - - SEQUENCE 0 or 1 MUST if non-zero, MUST be the sequence - number of the original REQUEST. MAY be - present if 0. - - ATTACH 0+ - CATEGORIES 0 or 1 This property may contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 - DTEND 0 or 1 if present DURATION MUST NOT be present - DTSTART 0 or 1 - DURATION 0 or 1 if present DTEND MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PRIORITY 0 or 1 - RDATE 0+ - RELATED-TO 0+ - - - -Silverberg, et. al. Standards Track [Page 22] - -RFC 2446 iTIP November 1998 - - - RESOURCES 0 or 1 This property MAY contain a list of values - REQUEST-STATUS 0+ - RRULE 0+ - STATUS 0 or 1 - SUMMARY 0 or 1 - TRANSP 0 or 1 - URL 0 or 1 - X-PROPERTY 0+ - -VTIMEZONE 0 or 1 MUST be present if any date/time refers - to a timezone -X-COMPONENT 0+ - -VALARM 0 -VFREEBUSY 0 -VJOURNAL 0 -VTODO 0 - -3.2.4 ADD - - The "ADD" method in a "VEVENT" calendar component is used to add one - or more instances to an existing "VEVENT". Unlike the "REQUEST" - method, when using issuing an "ADD" method, the "Organizer" does not - send the full "VEVENT" description; only the new instance(s). The - "ADD" method is especially useful if there are instance-specific - properties to be preserved in a recurring "VEVENT". For instance, an - "Organizer" may have originally scheduled a weekly Thursday meeting. - At some point, several instances changed. Location or start time may - have changed, or some instances may have unique "DESCRIPTION" - properties. The "ADD" method allows the "Organizer" to add new - instances to an existing event using a single ITIP message without - redefining the entire recurring pattern. - - The "UID" must be that of the existing event. If the "UID" property - value in the "ADD" is not found on the recipient's calendar, then the - recipient SHOULD send a "REFRESH" to the "Organizer" in order to be - updated with the latest version of the "VEVENT". If an "Attendee" - implementation does not support the "ADD" method it should respond - with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH". - - This method type is an iCalendar object that conforms to the - following property constraints: - - - - - - - - - -Silverberg, et. al. Standards Track [Page 23] - -RFC 2446 iTIP November 1998 - - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "ADD" -VEVENT 1 - DTSTAMP 1 - DTSTART 1 - ORGANIZER 1 - SEQUENCE 1 MUST be greater than 0 - SUMMARY 1 Can be null - UID 1 MUST match that of the original event - - ATTACH 0+ - ATTENDEE 0+ - CATEGORIES 0 or 1 This property MAY contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 Can be null - DTEND 0 or 1 if present DURATION MUST NOT be present - DURATION 0 or 1 if present DTEND MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PRIORITY 0 or 1 - RDATE 0+ - RELATED-TO 0+ - RESOURCES 0 or 1 This property MAY contain a list of values - RRULE 0+ - STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED - TRANSP 0 or 1 - URL 0 or 1 - X-PROPERTY 0+ - - RECURRENCE-ID 0 - REQUEST-STATUS 0 - -VALARM 0+ -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VFREEBUSY 0 -VTODO 0 -VJOURNAL 0 - - - - -Silverberg, et. al. Standards Track [Page 24] - -RFC 2446 iTIP November 1998 - - -3.2.5 CANCEL - - The "CANCEL" method in a "VEVENT" calendar component is used to send - a cancellation notice of an existing event request to the - "Attendees". The message is sent by the "Organizer" of the event. For - a recurring event, either the whole event or instances of an event - may be cancelled. To cancel the complete range of recurring event, - the "UID" property value for the event MUST be specified and a - "RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In - order to cancel an individual instance of the event, the - "RECURRENCE-ID" property value for the event MUST be specified in the - "CANCEL" method. - - There are two options for canceling a sequence of instances of a - recurring "VEVENT" calendar component: - - (a) the "RECURRENCE-ID" property for an instance in the sequence MUST - be specified with the "RANGE" property parameter value of - THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the - specified "VEVENT" calendar component and all instances before - (or after); or - - (b) individual recurrence instances may be cancelled by specifying - multiple "RECURRENCE-ID" properties corresponding to the - instances to be cancelled. - - When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be - incremented. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "CANCEL" - -VEVENT 1+ All must have the same UID - ATTENDEE 0+ MUST include all "Attendees" being removed - the event. MUST include all "Attendees" if - the entire event is cancelled. - DTSTAMP 1 - ORGANIZER 1 - SEQUENCE 1 - UID 1 MUST be the UID of the original REQUEST - - COMMENT 0 or 1 - ATTACH 0+ - CATEGORIES 0 or 1 This property may contain a list of values - - - -Silverberg, et. al. Standards Track [Page 25] - -RFC 2446 iTIP November 1998 - - - CLASS 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 - DTEND 0 or 1 if present DURATION MUST NOT be present - DTSTART 0 or 1 - DURATION 0 or 1 if present DTEND MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PRIORITY 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 MUST be present if referring to one or - more or more recurring instances. - Otherwise it MUST NOT be present - RELATED-TO 0+ - RESOURCES 0 or 1 - RRULE 0+ - STATUS 0 or 1 MUST be set to CANCELLED. If uninviting - specific "Attendees" then MUST NOT be - included. - SUMMARY 0 or 1 - TRANSP 0 or 1 - URL 0 or 1 - X-PROPERTY 0+ - REQUEST-STATUS 0 - -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VTODO 0 -VJOURNAL 0 -VFREEBUSY 0 -VALARM 0 - -3.2.6 REFRESH - - The "REFRESH" method in a "VEVENT" calendar component is used by - "Attendees" of an existing event to request an updated description - from the event "Organizer". The "REFRESH" method must specify the - "UID" property of the event to update. A recurrence instance of an - event may be requested by specifying the "RECURRENCE-ID" property - corresponding to the associated event. The "Organizer" responds with - the latest description and version of the event. - - - - -Silverberg, et. al. Standards Track [Page 26] - -RFC 2446 iTIP November 1998 - - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "REFRESH" - -VEVENT 1 - ATTENDEE 1 MUST be the address of requestor - DTSTAMP 1 - ORGANIZER 1 - UID 1 MUST be the UID associated with original - REQUEST - COMMENT 0 or 1 - RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a - recurring calendar component. Otherwise - it must NOT be present. - X-PROPERTY 0+ - - ATTACH 0 - CATEGORIES 0 - CLASS 0 - CONTACT 0 - CREATED 0 - DESCRIPTION 0 - DTEND 0 - DTSTART 0 - DURATION 0 - EXDATE 0 - EXRULE 0 - GEO 0 - LAST-MODIFIED 0 - LOCATION 0 - PRIORITY 0 - RDATE 0 - RELATED-TO 0 - REQUEST-STATUS 0 - RESOURCES 0 - RRULE 0 - SEQUENCE 0 - STATUS 0 - SUMMARY 0 - TRANSP 0 - URL 0 - -X-COMPONENT 0+ - -VTODO 0 - - - -Silverberg, et. al. Standards Track [Page 27] - -RFC 2446 iTIP November 1998 - - -VJOURNAL 0 -VFREEBUSY 0 -VTIMEZONE 0 -VALARM 0 - -3.2.7 COUNTER - - The "COUNTER" method for a "VEVENT" calendar component is used by an - "Attendee" of an existing event to submit to the "Organizer" a - counter proposal to the event description. The "Attendee" sends this - message to the "Organizer" of the event. - - The counter proposal is an iCalendar object consisting of a VEVENT - calendar component describing the complete description of the - alternate event. - - The "Organizer" rejects the counter proposal by sending the - "Attendee" a VEVENT "DECLINECOUNTER" method. The "Organizer" accepts - the counter proposal by rescheduling the event as described in - section 3.2.2.1 Rescheduling an Event. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "COUNTER" - -VEVENT 1 - DTSTAMP 1 - DTSTART 1 - ORGANIZER 1 MUST be the "Organizer" of the original - event - SEQUENCE 1 MUST be present if value is greater than 0, - MAY be present if 0 - SUMMARY 1 Can be null - UID 1 MUST be the UID associated with the REQUEST - being countered - - ATTACH 0+ - ATTENDEE 0+ Can also be used to propose other - "Attendees" - CATEGORIES 0 or 1 This property may contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 - - - -Silverberg, et. al. Standards Track [Page 28] - -RFC 2446 iTIP November 1998 - - - DTEND 0 or 1 if present DURATION MUST NOT be present - DURATION 0 or 1 if present DTEND MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PRIORITY 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a - recurring calendar component. Otherwise it - MUST NOT be present. - RELATED-TO 0+ - REQUEST-STATUS 0+ - RESOURCES 0 or 1 This property may contain a list of values - RRULE 0+ - STATUS 0 or 1 Value must be one of CONFIRMED/TENATIVE/ - CANCELLED - TRANSP 0 or 1 - URL 0 or 1 - X-PROPERTY 0+ - -VALARM 0+ -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VTODO 0 -VJOURNAL 0 -VFREEBUSY 0 - -3.2.8 DECLINECOUNTER - - The "DECLINECOUNTER" method in a "VEVENT" calendar component is used - by the "Organizer" of an event to reject a counter proposal submitted - by an "Attendee". The "Organizer" must send the "DECLINECOUNTER" - message to the "Attendee" that sent the "COUNTER" method to the - "Organizer". - - This method type is an iCalendar object that conforms to the - following property constraints: - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 29] - -RFC 2446 iTIP November 1998 - - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "DECLINECOUNTER" - -VEVENT 1 - DTSTAMP 1 - ORGANIZER 1 - UID 1 MUST, same UID specified in original - REQUEST and subsequent COUNTER - COMMENT 0 or 1 - RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a - recurring calendar component. Otherwise it - MUST NOT be present. - REQUEST-STATUS 0+ - SEQUENCE 0 OR 1 MUST be present if value is greater than 0, - MAY be present if 0 - X-PROPERTY 0+ - ATTACH 0 - ATTENDEE 0 - CATEGORIES 0 - CLASS 0 - CONTACT 0 - CREATED 0 - DESCRIPTION 0 - DTEND 0 - DTSTART 0 - DURATION 0 - EXDATE 0 - EXRULE 0 - GEO 0 - LAST-MODIFIED 0 - LOCATION 0 - PRIORITY 0 - RDATE 0 - RELATED-TO 0 - RESOURCES 0 - RRULE 0 - STATUS 0 - SUMMARY 0 - TRANSP 0 - URL 0 - -X-COMPONENT 0+ -VTODO 0 -VJOURNAL 0 -VFREEBUSY 0 -VTIMEZONE 0 -VALARM 0 - - - -Silverberg, et. al. Standards Track [Page 30] - -RFC 2446 iTIP November 1998 - - -3.3 Methods For VFREEBUSY Components - - This section defines the property set for the methods that are - applicable to the "VFREEBUSY" calendar component. Each of the methods - is defined using a restriction table. - - This document only addresses the transfer of busy time information. - Applications desiring free time information MUST infer this from - available busy time information. - - The busy time information within the iCalendar object MAY be grouped - into more than one "VFREEBUSY" calendar component. This capability - allows busy time periods to be grouped according to some common - periodicity, such as a calendar week, month, or year. In this case, - each "VFREEBUSY" calendar component MUST include the "ATTENDEE", - "DTSTART" and "DTEND" properties in order to specify the source of - the busy time information and the date and time interval over which - the busy time information covers. - - The "FREEBUSY" property value MAY include a list of values, separated - by the COMMA character ([US-ASCII] decimal 44). Alternately, multiple - busy time periods MAY be specified with multiple instances of the - "FREEBUSY" property. Both forms MUST be supported by implementations - conforming to this document. Duplicate busy time periods SHOULD NOT - be specified in an iCalendar object. However, two different busy time - periods MAY overlap. - - "FREEBUSY" properties should be sorted such that their values are in - ascending order, based on the start time, and then the end time, with - the earliest periods first. For example, today's busy time - information should appear after yesterday's busy time information. - And the busy time for this half-hour should appear after the busy - time for earlier today. - - Since events may span a day boundary, free busy time period may also - span a day boundary. Individual "A" requests busy time from - individuals "B", "C" and "D". Individual "B" and "C" replies with - busy time data to individual "A". Individual "D" does not support - busy time requests and does not reply with any data. If the transport - binding supports exception messages, then individual "D" returns an - "unsupported capability" message to individual "A4.34.3". - - The following summarizes the methods that are defined for the - "VFREEBUSY" calendar component. - - - - - - - -Silverberg, et. al. Standards Track [Page 31] - -RFC 2446 iTIP November 1998 - - - |================|==================================================| - | Method | Description | - |================|==================================================| - | PUBLISH | Publish unsolicited busy time data. | - | REQUEST | Request busy time data. | - | REPLY | Reply to a busy time request. | - |================|==================================================| - -3.3.1 PUBLISH - - The "PUBLISH" method in a "VFREEBUSY" calendar component is used to - publish busy time data. The method may be sent from one CU to any - other. The purpose of the method is to provide a message for sending - unsolicited busy time data. That is, the busy time data is not being - sent as a "REPLY" to the receipt of a "REQUEST" method. - - The "ATTENDEE" property must be specified in the busy time - information. The value is the CU address of the originator of the - busy time information. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "PUBLISH" - -VFREEBUSY 1+ - DTSTAMP 1 - DTSTART 1 DateTime values must be in UTC - DTEND 1 DateTime values must be in UTC - FREEBUSY 1+ MUST be BUSYTIME. Multiple instances are - allowed. Multiple instances must be sorted - in ascending order - ORGANIZER 1 MUST contain the address of originator of - busy time data. - - COMMENT 0 or 1 - CONTACT 0+ - X-PROPERTY 0+ - URL 0 or 1 Specifies busy time URL - - ATTENDEE 0 - DURATION 0 - REQUEST-STATUS 0 - UID 0 - -X-COMPONENT 0+ - - - -Silverberg, et. al. Standards Track [Page 32] - -RFC 2446 iTIP November 1998 - - -VEVENT 0 -VTODO 0 -VJOURNAL 0 -VTIMEZONE 0 -VALARM 0 - -3.3.2 REQUEST - - The "REQUEST" method in a "VFREEBUSY" calendar component is used to - ask a "Calendar User" for their busy time information. The request - may be for a busy time information bounded by a specific date and - time interval. - - This message only permits requests for busy time information. The - message is sent from a "Calendar User" requesting the busy time - information to one or more intended recipients. - - If the originator of the "REQUEST" method is not authorized to make a - busy time request on the recipient's calendar system, then an - exception message SHOULD be returned in a "REPLY" method, but no busy - time data need be returned. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "REQUEST" - -VFREEBUSY 1 - ATTENDEE 1+ contain the address of the calendar store - DTEND 1 DateTime values must be in UTC - DTSTAMP 1 - DTSTART 1 DateTime values must be in UTC - ORGANIZER 1 MUST be the request originator's address - UID 1 - COMMENT 0 or 1 - CONTACT 0+ - X-PROPERTY 0+ - - FREEBUSY 0 - DURATION 0 - REQUEST-STATUS 0 - URL 0 - -X-COMPONENT 0+ -VALARM 0 -VEVENT 0 - - - -Silverberg, et. al. Standards Track [Page 33] - -RFC 2446 iTIP November 1998 - - -VTODO 0 -VJOURNAL 0 -VTIMEZONE 0 - -3.3.3 REPLY - - The "REPLY" method in a "VFREEBUSY" calendar component is used to - respond to a busy time request. The method is sent by the recipient - of a busy time request to the originator of the request. - - The "REPLY" method may also be used to respond to an unsuccessful - "REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy - time information may be returned. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "REPLY" - -VFREEBUSY 1 - ATTENDEE 1 (address of recipient replying) - DTSTAMP 1 - DTEND 1 DateTime values must be in UTC - DTSTART 1 DateTime values must be in UTC - FREEBUSY 1+ (values MUST all be of the same data - type. Multiple instances are allowed. - Multiple instances MUST be sorted in - ascending order. Values MAY NOT overlap) - ORGANIZER 1 MUST be the request originator's address - UID 1 - - COMMENT 0 or 1 - CONTACT 0+ - REQUEST-STATUS 0+ - URL 0 or 1 (specifies busy time URL) - X-PROPERTY 0+ - DURATION 0 - SEQUENCE 0 - -X-COMPONENT 0+ -VALARM 0 -VEVENT 0 -VTODO 0 -VJOURNAL 0 -VTIMEZONE 0 - - - - -Silverberg, et. al. Standards Track [Page 34] - -RFC 2446 iTIP November 1998 - - -3.4 Methods For VTODO Components - - This section defines the property set for the methods that are - applicable to the "VTODO" calendar component. Each of the methods is - defined using a restriction table that specifies the property - constraints that define the particular method. - - The following summarizes the methods that are defined for the "VTODO" - calendar component. - - +================+==================================================+ - | Method | Description | - |================+==================================================| - | PUBLISH | Post notification of a VTODO. Used primarily as | - | | a method of advertising the existence of a VTODO.| - | | | - | REQUEST | Assign a VTODO. This is an explicit assignment to| - | | one or more Calendar Users. The REQUEST method | - | | is also used to update or change an existing | - | | VTODO. Clients that cannot handle REQUEST MAY | - | | degrade the method to treat it as a PUBLISH. | - | | | - | REPLY | Reply to a VTODO request. Attendees MAY set | - | | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE, | - | | DELEGATED, PARTIAL, and COMPLETED. | - | | | - | ADD | Add one or more instances to an existing to-do. | - | | | - | CANCEL | Cancel one or more instances of an existing | - | | to-do. | - | | | - | REFRESH | A request sent to a VTODO Organizer asking for | - | | the latest version of a VTODO. | - | | | - | COUNTER | Counter a REQUEST with an alternative proposal. | - | | | - | DECLINECOUNTER | Decline a counter proposal by an Attendee. | - +================+==================================================+ - -3.4.1 PUBLISH - - The "PUBLISH" method in a "VTODO" calendar component has no - associated response. It is simply a posting of an iCalendar object - that maybe added to a calendar. It MUST have an "Organizer". It MUST - NOT have "Attendees". Its expected usage is for encapsulating an - arbitrary "VTODO" calendar component as an iCalendar object. The - "Organizer" MAY subsequently update (with another "PUBLISH" method), - add instances to (with an "ADD" method), or cancel (with a "CANCEL" - - - -Silverberg, et. al. Standards Track [Page 35] - -RFC 2446 iTIP November 1998 - - - method) a previously published "VTODO" calendar component. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "PUBLISH" -VTODO 1+ - DTSTAMP 1 - DTSTART 1 - ORGANIZER 1 - PRIORITY 1 - SEQUENCE 0 or 1 MUST be present if value is greater than - 0, MAY be present if 0 - SUMMARY 1 Can be null. - UID 1 - - ATTACH 0+ - CATEGORIES 0 or 1 This property may contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 Can be null - DUE 0 or 1 If present DURATION MUST NOT be present - DURATION 0 or 1 If present DUE MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PERCENT-COMPLETE 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a - recurring calendar component. Otherwise - it MUST NOT be present. - - RELATED-TO 0+ - RESOURCES 0 or 1 This property may contain a list of values - RRULE 0+ -STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- - PROCESS/CANCELLED - URL 0 or 1 - X-PROPERTY 0+ - - ATTENDEE 0 - REQUEST-STATUS 0 - - - -Silverberg, et. al. Standards Track [Page 36] - -RFC 2446 iTIP November 1998 - - -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -VALARM 0+ -X-COMPONENT 0+ - -VFREEBUSY 0 -VEVENT 0 -VJOURNAL 0 - -3.4.2 REQUEST - - The "REQUEST" method in a "VTODO" calendar component provides the - following scheduling functions: - - . Assign a to-do to one or more "Calendar Users"; - . Reschedule an existing to-do; - . Update the details of an existing to-do, without rescheduling - it; - . Update the completion status of "Attendees" of an existing - to-do, without rescheduling it; - . Reconfirm an existing to-do, without rescheduling it; - . Delegate/reassign an existing to-do to another "Calendar User". - - The assigned "Calendar Users" are identified in the "VTODO" calendar - component by individual "ATTENDEE;ROLE=REQ-PARTICIPANT" property - value sequences. - - The originator of a "REQUEST" is the "Organizer" of the to-do. The - recipient of a "REQUEST" is the "Calendar User" assigned the to-do. - The "Attendee" uses the "REPLY" method to convey their acceptance and - completion status to the "Organizer" of the "REQUEST". - - The "UID", "SEQUENCE", and "DTSTAMP" properties are used to - distinguish the various uses of the "REQUEST" method. If the "UID" - property value in the "REQUEST" is not found on the recipient's - calendar, then the "REQUEST" is for a new to-do. If the "UID" - property value is found on the recipient's calendar, then the - "REQUEST" is a rescheduling, an update, or a reconfirm of the "VTODO" - calendar object. - - If the "Organizer" of the "REQUEST" method is not authorized to make - a to-do request on the "Attendee's" calendar system, then an - exception is returned in the "REQUEST-STATUS" property of a - subsequent "REPLY" method, but no scheduling action is performed. - - For the "REQUEST" method, multiple "VTODO" components in a single - iCalendar object are only permitted when for components with the same - "UID" property. That is, a series of recurring events may have - - - -Silverberg, et. al. Standards Track [Page 37] - -RFC 2446 iTIP November 1998 - - - instance-specific information. In this case, multiple "VTODO" - components are needed to express the entire series. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "REQUEST" -VTODO 1+ All components must have the same UID - ATTENDEE 1+ - DTSTAMP 1 - DTSTART 1 - ORGANIZER 1 - PRIORITY 1 - SEQUENCE 0 or 1 MUST be present if value is greater than - 0, MAY be present if 0 - SUMMARY 1 Can be null. - UID 1 - - ATTACH 0+ - CATEGORIES 0 or 1 This property may contain a list of - values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 Can be null - DUE 0 or 1 If present DURATION MUST NOT be present - DURATION 0 or 1 If present DUE MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PERCENT-COMPLETE 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 present if referring to an instance of a - recurring calendar component. Otherwise - it MUST NOT be present. - RELATED-TO 0+ - RESOURCES 0 or 1 This property may contain a list of - values - RRULE 0+ - STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- - PROCESS - URL 0 or 1 - X-PROPERTY 0+ - - - -Silverberg, et. al. Standards Track [Page 38] - -RFC 2446 iTIP November 1998 - - - REQUEST-STATUS 0 - -VALARM 0+ - -VTIMEZONE 0+ MUST be present if any date/time refers - to a timezone -X-COMPONENT 0+ - -VEVENT 0 -VFREEBUSY 0 -VJOURNAL 0 - -3.4.2.1 REQUEST for Rescheduling a VTODO - - The "REQUEST" method may be used to reschedule a "VTODO" calendar - component. - - Rescheduling a "VTODO" calendar component involves a change to the - existing "VTODO" calendar component in terms of its start or due time - or recurrence intervals and possibly the description. If the - recipient CUA of a "REQUEST" method finds that the "UID" property - value already exists on the calendar, but that the "SEQUENCE" - property value in the "REQUEST" is greater than the value for the - existing VTODO, then the "REQUEST" method describes a rescheduling of - the "VTODO" calendar component. - -3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO - - The "REQUEST" method may be used to update or reconfirm a "VTODO" - calendar component. Reconfirmation is merely an update of "Attendee" - completion status or overall "VTODO" calendar component status. - - An update to an existing "VTODO" calendar component does not involve - changes to the start or due time or recurrence intervals, nor - generally to the description for the "VTODO" calendar component. If - the recipient CUA of a "REQUEST" method finds that the "UID" property - value already exists on the calendar and that the "SEQUENCE" property - value in the "REQUEST" is the same as the value for the existing - event, then the "REQUEST" method describes an update of the "VTODO" - calendar component details, but not a rescheduling of the "VTODO" - calendar component. - - The update "REQUEST" is the appropriate response to a "REFRESH" - method sent from an "Attendee" to the "Organizer" of a "VTODO" - calendar component. - - Unsolicited "REQUEST" methods MAY be sent by the "Organizer" of a - "VTODO" calendar component. The unsolicited "REQUEST" methods are - - - -Silverberg, et. al. Standards Track [Page 39] - -RFC 2446 iTIP November 1998 - - - used to update the details of the "VTODO" (without rescheduling it or - updating the completion status of "Attendees") or the "VTODO" - calendar component itself (i.e., reconfirm the "VTODO"). - -3.4.2.3 REQUEST for Delegating a VTODO - - The "REQUEST" method is also used to delegate or reassign ownership - of a "VTODO" calendar component to another "Calendar User". For - example, it may be used to delegate an "Attendee's" role (i.e. - "chair", or "participant") for a "VTODO" calendar component. The - "REQUEST" method is sent by one of the "Attendees" of an existing - - "VTODO" calendar component to some other individual. An "Attendee" of - a "VTODO" calendar component MUST NOT delegate to the "Organizer" of - the event. - - For the purposes of this description, the "Attendee" delegating the - "VTODO" calendar component is referred to as the "Delegator". The - "Attendee" receiving the delegation request is referred to as the - "Delegate". - - The "Delegator" of a "VTODO" calendar component MUST forward the - existing "REQUEST" method for a "VTODO" calendar component to the - "Delegate". The "VTODO" calendar component description MUST include - the "Delegator's" up-to-date "VTODO" calendar component definition. - The "REQUEST" method MUST also include an "ATTENDEE" property with - the calendar address of the "Delegate". The "Delegator" MUST also - send a "REPLY" method back to the "Organizer" with the "Delegator's" - "Attendee" property "partstat" parameter value set to "DELEGATED". In - addition, the "delegated-to" parameter MUST be included with the - calendar address of the "Delegate". A response to the delegation - "REQUEST" is sent from the "Delegate" to the "Organizer" and - optionally, to the "Delegator". The "REPLY" method from the - "Delegate" SHOULD include the "ATTENDEE" property with their calendar - address and the "delegated-from" parameter with the value of the - "Delegator's" calendar address. - - The delegation "REQUEST" method MUST assign a value for the "RSVP" - property parameter associated with the "Delegator's" "Attendee" - property to that of the "Delegate's" "ATTENDEE" property. For example - if the "Delegator's" "ATTENDEE" property specifies "RSVP=TRUE", then - the "Delegate's" "ATTENDEE" property MUST specify "RSVP=TRUE". - -3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User - - An "Attendee" assigned a "VTODO" calendar component may send the - "VTODO" calendar component to another new CU, not previously - associated with the "VTODO" calendar component. The current - - - -Silverberg, et. al. Standards Track [Page 40] - -RFC 2446 iTIP November 1998 - - - "Attendee" assigned the "VTODO" calendar component does this by - forwarding the original "REQUEST" method to the new CU. The new CU - can send a "REPLY" to the "Organizer" of the "VTODO" calendar - component. The reply contains an "ATTENDEE" property for the new CU. - - The "Organizer" ultimately decides whether or not the new CU becomes - part of the to-do and is not obligated to do anything with a "REPLY" - from a new (uninvited) CU. If the "Organizer" does not want the new - CU to be part of the to-do, the new "ATTENDEE" property is not added - to the "VTODO" calendar component. The "Organizer" MAY send the CU a - "CANCEL" message to indicate that they will not be added to the to- - do. If the "Organizer" decides to add the new CU, the new "ATTENDEE" - property is added to the "VTODO" calendar component. Furthermore, the - "Organizer" is free to change any "ATTENDEE" property parameter from - the values supplied by the new CU to something the "Organizer" - considers appropriate. - -3.4.2.5 REQUEST Updated Attendee Status - - An "Organizer" of a "VTODO" may request an updated status from one or - more "Attendees". The "Organizer" sends a "REQUEST" method to the - "Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The - "SEQUENCE" property for the "VTODO" is not changed from its previous - value. A recipient determines that the only change in the "REQUEST" - is that their "RSVP" property parameter indicates a request for an - updated status. The recipient SHOULD respond with a "REPLY" method - indicating their current status with respect to the "REQUEST". - -3.4.3 REPLY - - The "REPLY" method in a "VTODO" calendar component is used to respond - (e.g., accept or decline) to a request or to reply to a delegation - request. It is also used by an "Attendee" to update their completion - status. When used to provide a delegation response, the "Delegator" - MUST include the calendar address of the "Delegate" in the - "delegated-to" parameter of the "Delegator's" "ATTENDEE" property. - The "Delegate" MUST include the calendar address of the "Delegator" - on the "delegated-from" parameter of the "Delegate's" "ATTENDEE" - property. - - The "REPLY" method MAY also be used to respond to an unsuccessful - "VTODO" calendar component "REQUEST" method. Depending on the - "REQUEST-STATUS" value, no scheduling action may have been performed. - - The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY" - method from a "Calendar User" not in the original "REQUEST". For - example, a "REPLY" method MAY be received from a "Delegate" of a - "VTODO" calendar component. In addition, the "REPLY" method MAY be - - - -Silverberg, et. al. Standards Track [Page 41] - -RFC 2446 iTIP November 1998 - - - received from an unknown "Calendar User", having been forwarded the - "REQUEST" by an original "Attendee" of the "VTODO" calendar - component. This uninvited "Attendee" MAY be accepted, or the - "Organizer" MAY cancel the "VTODO" calendar component for the - uninvited "Attendee" by sending them a "CANCEL" method. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- --------------------------------------------- -METHOD 1 MUST be "REPLY" -VTODO 1+ All component MUST have the same UID - ATTENDEE 1+ - DTSTAMP 1 - ORGANIZER 1 - REQUEST-STATUS 1+ - UID 1 MUST must be the address of the replying - attendee - - ATTACH 0+ - CATEGORIES 0 or 1 This property may contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 - DTSTART 0 or 1 - DUE 0 or 1 If present DURATION MUST NOT be present - DURATION 0 or 1 If present DUE MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PERCENT-COMPLETE 0 or 1 - PRIORITY 0 or 1 - RDATE 0+ - RELATED-TO 0+ - RESOURCES 0 or 1 This property may contain a list of values - RRULE 0+ - RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a - Recurring calendar component. Otherwise it - MUST NOT be present - SEQUENCE 0 or 1 MUST be the sequence number of - the original REQUEST if greater than 0. - MAY be present if 0. - STATUS 0 or 1 - - - -Silverberg, et. al. Standards Track [Page 42] - -RFC 2446 iTIP November 1998 - - - SUMMARY 0 or 1 Can be null - URL 0 or 1 - X-PROPERTY 0+ - -VTIMEZONE 0 or 1 MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VALARM 0 -VEVENT 0 -VFREEBUSY 0 - -3.4.4 ADD - - The "ADD" method in a "VTODO" calendar component is used to add one - or more instances to an existing to-do. - - If the "UID" property value in the "ADD" is not found on the - recipient's calendar, then the recipient SHOULD send a "REFRESH" to - the "Organizer" in order to be updated with the latest version of the - "VTODO". If an "Attendee" implementation does not support the "ADD" - method it should respond with a "REQUEST-STATUS" value of 5.3 and ask - for a "REFRESH". - - The "SEQUENCE" property value is incremented as the sequence of to- - dos has changed. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "ADD" -VTODO 1 - DTSTAMP 1 - ORGANIZER 1 - PRIORITY 1 - SEQUENCE 1 MUST be greater than 0 - SUMMARY 1 Can be null. - UID 1 MUST match that of the original to-do - - ATTACH 0+ - ATTENDEE 0+ - CATEGORIES 0 or 1 This property may contain a list of - values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - - - -Silverberg, et. al. Standards Track [Page 43] - -RFC 2446 iTIP November 1998 - - - CREATED 0 or 1 - DESCRIPTION 0 or 1 Can be null - DTSTART 0 or 1 - DUE 0 or 1 If present DURATION MUST NOT be present - DURATION 0 or 1 If present DUE MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PERCENT-COMPLETE 0 or 1 - RDATE 0+ - RELATED-TO 0+ - RESOURCES 0 or 1 This property may contain a list of - values - RRULE 0+ - STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- - PROCESS - URL 0 or 1 - X-PROPERTY 0+ - - RECURRENCE-ID 0 - REQUEST-STATUS 0 - -VALARM 0+ -VTIMEZONE 0+ MUST be present if any date/time refers - to a timezone -X-COMPONENT 0+ - -VEVENT 0 -VJOURNAL 0 -VFREEBUSY 0 - -3.4.5 CANCEL - - The "CANCEL" method in a "VTODO" calendar component is used to send a - cancellation notice of an existing "VTODO" calendar request to the - "Attendees". The message is sent by the "Organizer" of a "VTODO" - calendar component to the "Attendees" of the "VTODO" calendar - component. For a recurring "VTODO" calendar component, either the - whole "VTODO" calendar component or instances of a "VTODO" calendar - component may be cancelled. To cancel the complete range of a - recurring "VTODO" calendar component, the "UID" property value for - the "VTODO" calendar component MUST be specified and a "RECURRENCE- - ID" MUST NOT be specified in the "CANCEL" method. In order to cancel - an individual instance of a recurring "VTODO" calendar component, the - "RECURRENCE-ID" property value for the "VTODO" calendar component - MUST be specified in the "CANCEL" method. - - - -Silverberg, et. al. Standards Track [Page 44] - -RFC 2446 iTIP November 1998 - - - There are two options for canceling a sequence of instances of a - recurring "VTODO" calendar component: - - (a) the "RECURRENCE-ID" property for an instance in the sequence MUST - be specified with the "RANGE" property parameter value of - THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the - specified "VTODO" calendar component and all instances before (or - after); or - - (b) individual recurrence instances may be cancelled by specifying - multiple "RECURRENCE-ID" properties corresponding to the - instances to be cancelled. - - When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be - incremented. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- --------------------------------------------- -METHOD 1 MUST be "CANCEL" -VTODO 1 - ATTENDEE 0+ include all "Attendees" being removed from - the todo. MUST include all "Attendees" if - the entire todo is cancelled. - UID 1 MUST echo original UID - DTSTAMP 1 - ORGANIZER 1 - SEQUENCE 1 - - ATTACH 0+ - CATEGORIES 0 or 1 This property MAY contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 - DTSTART 0 or 1 - DUE 0 or 1 If present DURATION MUST NOT be present - DURATION 0 or 1 If present DUE MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PERCENT-COMPLETE 0 or 1 - RDATE 0+ - - - -Silverberg, et. al. Standards Track [Page 45] - -RFC 2446 iTIP November 1998 - - - RECURRENCE-ID 0 or 1 MUST only if referring to one or more - instances of a recurring calendar - component. Otherwise it MUST NOT be - present. - RELATED-TO 0+ - RESOURCES 0 or 1 This property MAY contain a list of values - RRULE 0+ - PRIORITY 0 or 1 - STATUS 0 or 1 If present it MUST be set to "CANCELLED". - MUST NOT be used if purpose is to remove - "ATTENDEES" rather than cancel the entire - VTODO. - URL 0 or 1 - X-PROPERTY 0+ - - REQUEST-STATUS 0 - -VTIMEZONE 0 or 1 MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VALARM 0 -VEVENT 0 -VFREEBUSY 0 - -3.4.6 REFRESH - - The "REFRESH" method in a "VTODO" calendar component is used by - "Attendees" of an existing "VTODO" calendar component to request an - updated description from the "Organizer" of the "VTODO" calendar - component. The "Organizer" of the "VTODO" calendar component MAY use - this method to request an updated status from the "Attendees". The - "REFRESH" method MUST specify the "UID" property corresponding to the - "VTODO" calendar component needing update. - - A refresh of a recurrence instance of a "VTODO" calendar component - may be requested by specifying the "RECURRENCE-ID" property - corresponding to the associated "VTODO" calendar component. The - "Organizer" responds with the latest description and rendition of the - "VTODO" calendar component. In most cases this will be a REQUEST - unless the "VTODO" has been cancelled, in which case the ORGANIZER - MUST send a "CANCEL". This method is intended to facilitate machine - processing of requests for updates to a "VTODO" calendar component. - - This method type is an iCalendar object that conforms to the - following property constraints: - - - - - -Silverberg, et. al. Standards Track [Page 46] - -RFC 2446 iTIP November 1998 - - -Component/Property Presence -------------------- --------------------------------------------- -METHOD 1 MUST be "REFRESH" -VTODO 1 - ATTENDEE 1 - DTSTAMP 1 - UID 1 MUST echo original UID - - RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a - Recurring calendar component. Otherwise it - MUST NOT be present - X-PROPERTY 0+ - - ATTACH 0 - CATEGORIES 0 - CLASS 0 - COMMENT 0 - CONTACT 0 - CREATED 0 - DESCRIPTION 0 - DTSTART 0 - DUE 0 - DURATION 0 - EXDATE 0 - EXRULE 0 - GEO 0 - LAST-MODIFIED 0 - LOCATION 0 - ORGANIZER 0 - PERCENT-COMPLETE 0 - PRIORITY 0 - RDATE 0 - RELATED-TO 0 - REQUEST-STATUS 0 - RESOURCES 0 - RRULE 0 - SEQUENCE 0 - STATUS 0 - URL 0 - -X-COMPONENT 0+ - -VALARM 0 -VEVENT 0 -VFREEBUSY 0 -VTIMEZONE 0 - - - - - -Silverberg, et. al. Standards Track [Page 47] - -RFC 2446 iTIP November 1998 - - -3.4.7 COUNTER - - The "COUNTER" method in a "VTODO" calendar component is used by an - "Attendee" of an existing "VTODO" calendar component to submit to the - "Organizer" a counter proposal for the "VTODO" calendar component. - The "Attendee" sends the message to the "Organizer" of the "VTODO" - calendar component. - - The counter proposal is an iCalendar object consisting of a "VTODO" - calendar component describing the complete description of the - alternate "VTODO" calendar component. - - The "Organizer" rejects the counter proposal by sending the - "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the - counter proposal by sending all of the "Attendees" of the "VTODO" - calendar component a "REQUEST" method rescheduling the "VTODO" - calendar component. In the latter case, the "Organizer" SHOULD reset - the individual "RSVP" property parameter values to TRUE on each - "ATTENDEE" property; in order to force a response by the "Attendees". - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "COUNTER" -VTODO 1 - ATTENDEE 1+ - DTSTAMP 1 - ORGANIZER 1 - PRIORITY 1 - SUMMARY 1 Can be null - UID 1 - - ATTACH 0+ - CATEGORIES 0 or 1 This property MAY contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 Can be null - DTSTART 0 or 1 - DUE 0 or 1 If present DURATION MUST NOT be present - DURATION 0 or 1 If present DUE MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - - - -Silverberg, et. al. Standards Track [Page 48] - -RFC 2446 iTIP November 1998 - - - LOCATION 0 or 1 - PERCENT-COMPLETE 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 MUST only 3.5if referring to an instance of a - recurring calendar component. Otherwise it - MUST NOT be present. - RELATED-TO 0+ - REQUEST-STATUS 0+ - RESOURCES 0 or 1 This property MAY contain a list of values - RRULE 0 or 1 - SEQUENCE 0 or 1 MUST echo the original SEQUENCE number. - MUST be present if non-zero. MAY be present - if zero. - STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- - PROCESS/CANCELLED - URL 0 or 1 - X-PROPERTY 0+ - - -VALARM 0+ -VTIMEZONE 0 or 1 MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VEVENT 0 -VFREEBUSY 0 - -3.4.8 DECLINECOUNTER - - The "DECLINECOUNTER" method in a "VTODO" calendar component is used - by an "Organizer" of "VTODO" calendar component to reject a counter - proposal offered by one of the "Attendees". The "Organizer" sends the - message to the "Attendee" that sent the "COUNTER" method to the - "Organizer". - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- --------------------------------------------- -METHOD 1 MUST be "DECLINECOUNTER" - -VTODO 1 - ATTENDEE 1+ MUST for all attendees - DTSTAMP 1 - ORGANIZER 1 - SEQUENCE 1 MUST echo the original SEQUENCE number - UID 1 MUST echo original UID - - - -Silverberg, et. al. Standards Track [Page 49] - -RFC 2446 iTIP November 1998 - - - ATTACH 0+ - CATEGORIES 0 or 1 This property may contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 - DTSTART 0 or 1 - DUE 0 or 1 If present DURATION MUST NOT be present - DURATION 0 or 1 If present DUE MUST NOT be present - EXDATE 0+ - EXRULE 0+ - GEO 0 or 1 - LAST-MODIFIED 0 or 1 - LOCATION 0 or 1 - PERCENT-COMPLETE 0 or 1 - PRIORITY 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a - recurring calendar component. Otherwise - it MUST NOT be present. - RELATED-TO 0+ - REQUEST-STATUS 0+ - RESOURCES 0 or 1 This property MAY contain a list of values - RRULE 0+ - STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- - PROCESS - URL 0 or 1 - X-PROPERTY 0+ - -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VALARM 0 -VEVENT 0 -VFREEBUSY 0 - -3.5 Methods For VJOURNAL Components - - This section defines the property set for the methods that are - applicable to the "VJOURNAL" calendar component. - - The following summarizes the methods that are defined for the - "VJOURNAL" calendar component. - - - - - - -Silverberg, et. al. Standards Track [Page 50] - -RFC 2446 iTIP November 1998 - - - +================+==================================================+ - | Method | Description | - |================+==================================================| - | PUBLISH | Post a journal entry. Used primarily as a method | - | | of advertising the existence of a journal entry. | - | | | - | ADD | Add one or more instances to an existing journal | - | | entry. | - | | | - | CANCEL | Cancel one or more instances of an existing | - | | journal entry. | - +================+==================================================+ - -3.5.1 PUBLISH - - The "PUBLISH" method in a "VJOURNAL" calendar component has no - associated response. It is simply a posting of an iCalendar object - that may be added to a calendar. It MUST have an "Organizer". It MUST - NOT have "Attendees". The expected usage is for encapsulating an - - arbitrary journal entry as an iCalendar object. The "Organizer" MAY - subsequently update (with another "PUBLISH" method) or cancel (with a - "CANCEL" method) a previously published journal entry. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "PUBLISH" -VJOURNAL 1+ - DESCRIPTION 1 Can be null. - DTSTAMP 1 - DTSTART 1 - ORGANIZER 1 - UID 1 - - ATTACH 0+ - CATEGORIES 0 or 1 This property MAY contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - EXDATE 0+ - EXRULE 0+ - LAST-MODIFIED 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a - - - -Silverberg, et. al. Standards Track [Page 51] - -RFC 2446 iTIP November 1998 - - - recurring calendar component. Otherwise - it MUST NOT be present. - RELATED-TO 0+ - RRULE 0+ - SEQUENCE 0 or 1 MUST echo the original SEQUENCE number. - MUST be present if non-zero. MAY be - present if zero. - STATUS 0 or 1 MAY be one of DRAFT/FINAL/CANCELLED - SUMMARY 0 or 1 Can be null - URL 0 or 1 - X-PROPERTY 0+ - - ATTENDEE 0 - -VALARM 0+ -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VEVENT 0 -VFREEBUSY 0 -VTODO 0 - -3.5.2 ADD - - The "ADD" method in a "VJOURNAL" calendar component is used to add - one or more instances to an existing "VJOURNAL" entry. There is no - response to the "Organizer". - - If the "UID" property value in the "ADD" is not found on the - recipient's calendar, then the recipient MAY treat the "ADD" as a - "PUBLISH". - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- ---------------------------------------------- -METHOD 1 MUST be "ADD" -VJOURNAL 1 - DESCRIPTION 1 Can be null. - DTSTAMP 1 - DTSTART 1 - ORGANIZER 1 - SEQUENCE 1 MUST be greater than 0 - UID 1 MUST match that of the original journal - - ATTACH 0+ - - - -Silverberg, et. al. Standards Track [Page 52] - -RFC 2446 iTIP November 1998 - - - CATEGORIES 0 or 1 This property MAY contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - EXDATE 0+ - EXRULE 0+ - LAST-MODIFIED 0 or 1 - RDATE 0+ - RELATED-TO 0+ - RRULE 0+ - STATUS 0 or 1 MAY be one of DRAFT/FINAL/CANCELLED - SUMMARY 0 or 1 Can be null - URL 0 or 1 - X-PROPERTY 0+ - - ATTENDEE 0 - RECURRENCE-ID 0 - -VALARM 0+ -VTIMEZONE 0 or 1 MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ - -VEVENT 0 -VFREEBUSY 0 -VTODO 0 - -3.5.3 CANCEL - - The "CANCEL" method in a "VJOURNAL" calendar component is used to - send a cancellation notice of an existing journal entry. The message - is sent by the "Organizer" of a journal entry. For a recurring - journal entry, either the whole journal entry or instances of a - journal entry may be cancelled. To cancel the complete range of a - recurring journal entry, the "UID" property value for the journal - entry MUST be specified and a "RECURRENCE-ID" property MUST NOT be - specified in the "CANCEL" method. In order to cancel an individual - instance of the journal entry, the "RECURRENCE-ID" property value for - the journal entry MUST be specified in the "CANCEL" method. - - There are two options for canceling a sequence of instances of a - recurring "VJOURNAL" calendar component: - - - - - - - - -Silverberg, et. al. Standards Track [Page 53] - -RFC 2446 iTIP November 1998 - - - (a) the "RECURRENCE-ID" property for an instance in the sequence MUST - be specified with the "RANGE" property parameter value of - THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the - specified "VTODO" calendar component and all instances before (or - after); or - - (b) individual recurrence instances may be cancelled by specifying - multiple "RECURRENCE-ID" properties corresponding to the - instances to be cancelled. - - When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be - incremented. - - This method type is an iCalendar object that conforms to the - following property constraints: - -Component/Property Presence -------------------- --------------------------------------------- -METHOD 1 MUST be "CANCEL" -VJOURNAL 1+ All MUST have the same UID - DTSTAMP 1 - ORGANIZER 1 - SEQUENCE 1 - UID 1 MUST be the UID of the original REQUEST - - ATTACH 0+ - ATTENDEE 0+ - CATEGORIES 0 or 1 This property MAY contain a list of values - CLASS 0 or 1 - COMMENT 0 or 1 - CONTACT 0+ - CREATED 0 or 1 - DESCRIPTION 0 or 1 - DTSTART 0 or 1 - EXDATE 0+ - EXRULE 0+ - LAST-MODIFIED 0 or 1 - RDATE 0+ - RECURRENCE-ID 0 or 1 only if referring to an instance of a - recurring calendar component. Otherwise - it MUST NOT be present. - RELATED-TO 0+ - RRULE 0+ - STATUS 0 or 1 MAY be present, must be "CANCELLED" if - present - SUMMARY 0 or 1 - URL 0 or 1 - X-PROPERTY 0+ - - - -Silverberg, et. al. Standards Track [Page 54] - -RFC 2446 iTIP November 1998 - - - REQUEST-STATUS 0 - -VTIMEZONE 0+ MUST be present if any date/time refers to - a timezone -X-COMPONENT 0+ -VALARM 0 -VEVENT 0 -VFREEBUSY 0 -VTODO 0 - -3.6 Status Replies - - The "REQUEST-STATUS" property may include the following values: - -|==============+============================+=========================| -| Short Return | Longer Return Status | Offending Data | -| Status Code | Description | | -|==============+============================+=========================| -| 2.0 | Success. | None. | -|==============+============================+=========================| -| 2.1 | Success but fallback taken | Property name and value | -| | on one or more property | MAY be specified. | -| | values. | | -|==============+============================+=========================| -| 2.2 | Success, invalid property | Property name MAY be | -| | ignored. | specified. | -|==============+============================+=========================| -| 2.3 | Success, invalid property | Property parameter name | -| | parameter ignored. | and value MAY be | -| | | specified. | -|==============+============================+=========================| -| 2.4 | Success, unknown non- | Non-standard property | -| | standard property ignored. | name MAY be specified. | -|==============+============================+=========================| -| 2.5 | Success, unknown non | Property and non- | -| | standard property value | standard value MAY be | -| | ignored. | specified. | -|==============+============================+=========================| -| 2.6 | Success, invalid calendar | Calendar component | -| | component ignored. | sentinel (e.g., BEGIN: | -| | | ALARM) MAY be | -| | | specified. | -|==============+============================+=========================| -| 2.7 | Success, request forwarded | Original and forwarded | -| | to Calendar User. | caluser addresses MAY | -| | | be specified. | -|==============+============================+=========================| -| 2.8 | Success, repeating event | RRULE or RDATE property | - - - -Silverberg, et. al. Standards Track [Page 55] - -RFC 2446 iTIP November 1998 - - -| | ignored. Scheduled as a | name and value MAY be | -| | single component. | specified. | -|==============+============================+=========================| -| 2.9 | Success, truncated end date| DTEND property value | -| | time to date boundary. | MAY be specified. | -|==============+============================+=========================| -| 2.10 | Success, repeating VTODO | RRULE or RDATE property | -| | ignored. Scheduled as a | name and value MAY be | -| | single VTODO. | specified. | -|==============+============================+=========================| -| 2.11 | Success, unbounded RRULE | RRULE property name and | -| | clipped at some finite | value MAY be specified. | -| | number of instances | Number of instances MAY | -| | | also be specified. | -|==============+============================+=========================| -| 3.0 | Invalid property name. | Property name MAY be | -| | | specified. | -|==============+============================+=========================| -| 3.1 | Invalid property value. | Property name and value | -| | | MAY be specified. | -|==============+============================+=========================| -| 3.2 | Invalid property parameter.| Property parameter name | -| | | and value MAY be | -| | | specified. | -|==============+============================+=========================| -| 3.3 | Invalid property parameter | Property parameter name | -| | value. | and value MAY be | -| | | specified. | -|==============+============================+=========================| -| 3.4 | Invalid calendar component | Calendar component | -| | sequence. | sentinel MAY be | -| | | specified (e.g., BEGIN: | -| | | VTIMEZONE). | -|==============+============================+=========================| -| 3.5 | Invalid date or time. | Date/time value(s) MAY | -| | | be specified. | -|==============+============================+=========================| -| 3.6 | Invalid rule. | Rule value MAY be | -| | | specified. | -|==============+============================+=========================| -| 3.7 | Invalid Calendar User. | Attendee property value | -| | |MAY be specified. | -|==============+============================+=========================| -| 3.8 | No authority. | METHOD and Attendee | -| | | property values MAY be | -| | | specified. | -|==============+============================+=========================| - - - - -Silverberg, et. al. Standards Track [Page 56] - -RFC 2446 iTIP November 1998 - - -| 3.9 | Unsupported version. | VERSION property name | -| | | and value MAY be | -| | | specified. | -|==============+============================+=========================| -| 3.10 | Request entity too large. | None. | -|==============+============================+=========================| -| 3.11 | Required component or | Component or property | -| | property missing. | name MAY be specified. | -|==============+============================+=========================| -| 3.12 | Unknown component or | Component or property | -| | property found | name MAY be specified | -|==============+============================+=========================| -| 3.13 | Unsupported component or | Component or property | -| | property found | name MAY be specified | -|==============+============================+=========================| -| 3.14 | Unsupported capability | Method or action MAY | -| | | be specified | -|==============+============================+=========================| -| 4.0 | Event conflict. Date/time | DTSTART and DTEND | -| | is busy. | property name and values| -| | | MAY be specified. | -|==============+============================+=========================| -| 5.0 | Request MAY supported. | Method property value | -| | | MAY be specified. | -|==============+============================+=========================| -| 5.1 | Service unavailable. | ATTENDEE property value | -| | | MAY be specified. | -|==============+============================+=========================| -| 5.2 | Invalid calendar service. | ATTENDEE property value | -| | | MAY be specified. | -|==============+============================+=========================| -| 5.3 | No scheduling support for | ATTENDEE property value | -| | user. | MAY be specified. | -|==============+============================+=========================| - -3.7 Implementation Considerations - -3.7.1 Working With Recurrence Instances - - iCalendar includes a recurrence grammar to represent recurring - events. The benefit of such a grammar is the ability to represent a - number of events in a single object. However, while this simplifies - creation of a recurring event, meeting instances still need to be - referenced. For instance, an "Attendee" may decline the third - instance of a recurring Friday event. Similarly, the "Organizer" may - change the time or location to a single instance of the recurring - event. - - - - -Silverberg, et. al. Standards Track [Page 57] - -RFC 2446 iTIP November 1998 - - - Since implementations may elect to store recurring events as either a - single event object or a collection of discreet, related event - objects, the protocol is designed so that each recurring instance may - be both referenced and versioned. Hence, implementations that choose - to maintain per-instance properties (such as "ATTENDEE" property - "partstat" parameter) may do so. However, the protocol does not - require per-instance recognition unless the instance itself must be - renegotiated. - - The scenarios for recurrence instance referencing are listed below. - For purposes of simplification a change to an event refers to a - "trigger property." That is, a property that has a substantive - effect on the meeting itself such as start time, location, due date - (for "VTODO" calendar component components) and possibly description. - - "Organizer" initiated actions: - - . "Organizer" deletes or changes a single instance of a recurring - event - . "Organizer" makes changes that affect all future instances - . "Organizer" makes changes that affect all previous instances - . "Organizer" deletes or modifies a previously changed instance - - "Attendee" initiated actions: - - . "Attendee" changes status for a particular recurrence instance - . "Attendee" sends Event-Counter for a particular recurrence - instance - - An instance of a recurring event is assigned a unique identification, - "RECURRENCE-ID" property, when that instance is renegotiated. - Negotiation may be necessary when a substantive change to the event - or to-do has be made (such as changing the start time, end time, due - date or location). The "Organizer" can identify a specific recurrence - instance using the "RECURRENCE-ID" property. The property value is - equal to the date/time of the instance. If the "Organizer" wishes to - change the "DTSTART", the original "DTSTART" value is used for - "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values - reflect the change. Note that after the change has occurred, the - "RECURRENCE-ID" has changed to the new "DTSTART" value. - -3.7.2 Attendee Property Considerations - - The "ORGANIZER" property is required on published events, to-dos, and - journal entries for two reasons. First, only the "Organizer" is - allowed to update and redistribute an event or to-do component. It - follows that the "ORGANIZER" property MUST be present in the event, - to-do, or journal entry component so that the CUA has a basis for - - - -Silverberg, et. al. Standards Track [Page 58] - -RFC 2446 iTIP November 1998 - - - authorizing an update. Second, it is prudent to provide a point of - contact for anyone who receives a published component in case of - problems. - - There are valid [RFC-822] addresses that represent groups. Sending - email to such an address results in mail being sent to multiple - recipients. Such an address may be used as the value of an - "ATTENDEE" property. Thus, it is possible that the recipient of a - "REQUEST" does not appear explicitly in the list. - - It is recommended that the general approach to finding a "Calendar - User" in an attendee list be as follows: - - 1. Search for the "Calendar User" in the attendee list where - "TYPE=INDIVIDUAL" - - 2. Failing (1) look for attendees where "TYPE=GROUP" or - 'TYPE=UNKNOWN". The CUA then determines if the "Calendar User" - is a member of one of these groups. If so, the "REPLY" method - sent to the "Organizer" MUST contain a new "ATTENDEE" property in - which: - . the "type" property parameter is set to INDIVIDUAL - . the "member" property parameter is set to the name of the - group - - 3. Failing (2) the CUA MAY ignore or accept the request as the - "Calendar User" wishes. - -3.7.3 X-Tokens - - To make iCalendar objects extensible, new property types MAY be - inserted into components. These properties are called X-Tokens as - they are prefixed with "X-". A client is not required to make sense - of X-Tokens. Clients are not required to save X-Tokens or use them - in replies. - -4 Examples - -4.1 Published Event Examples - - In the calendaring and scheduling context, publication refers to the - one way transfer of event information. Consumers of published events - simply incorporate the event into a calendar. No reply is expected. - Individual "A" publishes an event. Individual "B" reads the event and - incorporates it into their calendar. Events are published in several - ways including: embedding the event as an object in a web page, e- - mailing the event to a distribution list, and posting the event to a - newsgroup. - - - -Silverberg, et. al. Standards Track [Page 59] - -RFC 2446 iTIP November 1998 - - - The table below illustrates the sequence of events between the - publisher and the consumers of a published event. - - +-------------------------------------------------------------------+ - | Action | "Organizer" | - +---------------------------------+---------------------------------+ - | Publish an event | "A" sends or posts a PUBLISH | - | | message | - +---------------------------------+---------------------------------+ - | "B" reads a published event | | - +---------------------------------+---------------------------------+ - | Publish an updated event | "A" sends or posts a PUBLISH | - | | message | - +---------------------------------+---------------------------------+ - | "B" reads the updated event | | - +---------------------------------+---------------------------------+ - | Cancel a published event | "A" sends or posts a CANCEL | - | | message | - +---------------------------------+---------------------------------+ - | "B" reads the canceled event | | - | publication | | - +---------------------------------+---------------------------------+ - -4.1.1 A Minimal Published Event - - The iCalendar object below describes a single event that begins on - July 1, 1997 at 20:00 UTC. This event contains the minimum set of - properties for a "PUBLISH" for a "VEVENT" calendar component. - - BEGIN:VCALENDAR - METHOD:PUBLISH - PRODID:-//ACME/DesktopCalendar//EN - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - DTSTART:19970701T200000Z - DTSTAMP:19970611T190000Z - SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES - UID:0981234-1234234-23@example.com - END:VEVENT - END:VCALENDAR - -4.1.2 Changing A Published Event - - The iCalendar object below describes an update to the event described - in 4.1.1, the time has been changed, an end time has been added, and - the sequence number has been adjusted. - - - - -Silverberg, et. al. Standards Track [Page 60] - -RFC 2446 iTIP November 1998 - - - BEGIN:VCALENDAR - METHOD:PUBLISH - VERSION:2.0 - PRODID:-//ACME/DesktopCalendar//EN - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - DTSTAMP:19970612T190000Z - DTSTART:19970701T210000Z - DTEND:19970701T230000Z - SEQUENCE:1 - UID:0981234-1234234-23@example.com - SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES - END:VEVENT - END:VCALENDAR - - The "UID" property is used by the client to identify the event. The - "SEQUENCE" property indicates that this is a change to the event. The - event with a matching UID and sequence number 0 is superseded by this - event. - - The "SEQUENCE" property provides a reliable way to distinguish - different versions of the same event. Each time an event is - published, its sequence number is incremented. If a client receives - an event with a sequence number 5 and finds it has the same event - with sequence number 2, the event SHOULD be updated. However, if the - client received an event with sequence number 2 and finds it already - has sequence number 5 of the same event, the event MUST NOT be - updated. - -4.1.3 Canceling A Published Event - - The iCalendar object below cancels the event described in 4.1.1. This - cancels the event with "SEQUENCE" property of 0, 1, and 2. - - BEGIN:VCALENDAR - METHOD:CANCEL - VERSION:2.0 - PRODID:-//ACME/DesktopCalendar//EN - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - COMMENT:DUKES forfeit the game - SEQUENCE:2 - UID:0981234-1234234-23@example.com - DTSTAMP:19970613T190000Z - END:VEVENT - END:VCALENDAR - - - - - -Silverberg, et. al. Standards Track [Page 61] - -RFC 2446 iTIP November 1998 - - -4.1.4 A Rich Published Event - - This example describes the same event as in 4.1.1, but in much - greater detail. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:PUBLISH - SCALE:GREGORIAN - VERSION:2.0 - BEGIN:VTIMEZONE - TZID:America-Chicago - TZURL:http://zones.stds_r_us.net/tz/America-Chicago - BEGIN:STANDARD - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0600 - TZNAME:CST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 - TZOFFSETFROM:-0600 - TZOFFSETTO:-0500 - TZNAME:CDT - END:DAYLIGHT - END:VTIMEZONE - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTACH:http://www.dukes.com/ - CATEGORIES:SPORTS EVENT,ENTERTAINMENT - CLASS:PRIVATE - DESCRIPTION:MIDWAY STADIUM\n - Big time game. MUST see.\n - Expected duration:2 hours\n - DTEND;TZID=America-Chicago:19970701T180000 - DTSTART;TZID=America-Chicago:19970702T160000 - DTSTAMP:19970614T190000Z - STATUS:CONFIRMED - LOCATION;VALUE=URI:http://www.midwaystadium.com/ - PRIORITY:2 - RESOURCES:SCOREBOARD - SEQUENCE:3 - SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES - UID:0981234-1234234-23@example.com - RELATED-TO:0981234-1234234-14@example.com - BEGIN:VALARM - - - -Silverberg, et. al. Standards Track [Page 62] - -RFC 2446 iTIP November 1998 - - - TRIGGER:-PT2H - ACTION:DISPLAY - DESCRIPTION:You should be leaving for the game now. - END:VALARM - BEGIN:VALARM - TRIGGER:-PT30M - ACTION:AUDIO - END:VALARM - END:VEVENT - END:VCALENDAR - - The "RELATED-TO" field contains the "UID" property of a related - calendar event. The "SEQUENCE" property 3 indicates that this event - supersedes versions 0, 1, and 2. - -4.1.5 Anniversaries or Events attached to entire days - - This example demonstrates the use of the "value" parameter to tie a - "VEVENT" to day rather than a specific time. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:PUBLISH - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - DTSTAMP:19970614T190000Z - UID:0981234-1234234-23@example.com - DTSTART;VALUE=DATE:19970714 - RRULE:FREQ=YEARLY;INTERVAL=1 - SUMMARY: Bastille Day - END:VEVENT - END:VCALENDAR - -4.2 Group Event Examples - - Group events are distinguished from published events in that they - have "Attendees" and that there is interaction between the - "Attendees" and the "Organizer" with respect to the event. Individual - "A" requests a meeting between individuals "A", "B", "C" and "D". - Individual "B" confirms attendance to the meeting. Individual "C" - declines attendance. Individual "D" tentatively confirms attendance. - The following table illustrates the the message flow between these - individuals. A, the CU scheduling the meeting, is referenced as the - "Organizer". - - - - - - -Silverberg, et. al. Standards Track [Page 63] - -RFC 2446 iTIP November 1998 - - -+---------------------------------------------------------------------+ -| Action | "Organizer" | Attendee | -+---------------------------------------------------------------------+ -| Initiate a meeting | "A" sends a REQUEST | | -| request | message to "B", "C",| | -| | and "D" | | -+---------------------------------------------------------------------+ -| Accept the meeting | | "B" sends a REPLY | -| request | | message to "A" with its | -| | | ATTENDEE "partstat" para-| -| | | set to "accepted" | -+---------------------------------------------------------------------+ -| Decline the meeting| | "C" sends a REPLY | -| request | | message to "A" with its | -| | | ATTENDEE "partstat" para-| -| | | set to "declined" | -+---------------------------------------------------------------------+ -| Tentatively accept | | "D" sends a REPLY | -| the meeting request| | message to "A" with its | -| | | ATTENDEE "partstat" para-| -| | | set to "tentative" | -+---------------------------------------------------------------------+ -| Confirm meeting | "A" sends a REQUEST | | -| status with | message to "B" and | | -| attendees | "D" with updated | | -| | information. | | -+---------------------------------------------------------------------+ - -4.2.1 A Group Event Request - - A sample meeting request is sent from "A" to "B", "C", and "D". _E_ - is also sent a copy of the request but is not expected to attend and - need not reply. "E" illustrates how CUAs might implement an "FYI" - type feature. Note the use of the "role" parameter. The default value - for the "role" parameter is "req-participant" and it need not be - enumerated. In this case we are using the value "non-participant" to - indicate "E" is a non-attending CU. The parameter is not needed on - other "Attendees" since "participant" is the default value. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=BIG A:Mailto:A@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com - - - -Silverberg, et. al. Standards Track [Page 64] - -RFC 2446 iTIP November 1998 - - - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com - ATTENDEE;RSVP=FALSE;TYPE=ROOM:conf_Big@example.com - ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970701T200000Z - DTEND:19970701T2000000Z - SUMMARY:Conference - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.2.2 Reply To A Group Event Request - - Attendee "B" accepts the meeting. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VEVENT - ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com - ORGANIZER:MAILTO:A@example.com - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - REQUEST-STATUS:2.0;Success - DTSTAMP:19970612T190000Z - END:VEVENT - END:VCALENDAR - - "B" could have declined the meeting or indicated tentative acceptance - by setting the "ATTENDEE" "partstat" parameter to "declined" or - "tentative", respectively. Also, "REQUEST-STATUS" is not required in - successful transactions. - -4.2.3 Update An Event - - The event is moved to a different time. The combination of the "UID" - property (unchanged) and the "SEQUENCE" (bumped to 1) properties - indicate the update. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - - - -Silverberg, et. al. Standards Track [Page 65] - -RFC 2446 iTIP November 1998 - - - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com - ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE; - CUTYPE=ROOM:Mailto:Conf@example.com - ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com - DTSTART:19970701T180000Z - DTEND:19970701T190000Z - SUMMARY:Phone Conference - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:1 - DTSTAMP:19970613T190000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.2.4 Countering an Event Proposal - - "A" sends a "REQUEST" to "B" and "C". "B" makes a counter-proposal to - "A" to change the time and location. - - "A" sends the following "REQUEST": - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com - DTSTART:19970701T190000Z - DTEND:19970701T200000Z - SUMMARY:Discuss the Merits of the election results - LOCATION:Green Conference Room - UID:calsrv.example.com-873970198738777a@example.com - SEQUENCE:0 - DTSTAMP:19970611T190000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - "B" sends "COUNTER" to "A", requesting changes to time and place. "B" - uses the "COMMENT" property to communicate a rationale for the - change. Note that the "SEQUENCE" property is NOT incremented on a - "COUNTER". - - - -Silverberg, et. al. Standards Track [Page 66] - -RFC 2446 iTIP November 1998 - - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:COUNTER - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com - DTSTART:19970701T160000Z - DTEND:19970701T190000Z - DTSTAMP:19970612T190000Z - SUMMARY:Discuss the Merits of the election results - LOCATION:Green Conference Room - COMMENT:This time works much better and I think the big conference - room is too big - UID:calsrv.example.com-873970198738777a@example.com - SEQUENCE:0 - DTSTAMP:19970611T190000Z - END:VEVENT - END:VCALENDAR - - "A" accepts the changes from "B". To accept a counter-proposal, the - "Organizer" sends a new event "REQUEST" with an incremented sequence - number. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com - DTSTAMP:19970613T190000Z - DTSTART:19970701T160000Z - DTEND:19970701T190000Z - SUMMARY:Discuss the Merits of the election results - changed to - meet B's schedule - LOCATION:Green Conference Room - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:1 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - Instead, "A" rejects "B's" counter proposal - - - -Silverberg, et. al. Standards Track [Page 67] - -RFC 2446 iTIP November 1998 - - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:DECLINECOUNTER - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com - COMMENT:Sorry, I cannot change this meeting time - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - DTSTAMP:19970614T190000Z - END:VEVENT - END:VCALENDAR - -4.2.5 Delegating an Event - - When delegating an event request to another "Calendar User", the - "Delegator" must both update the "Organizer" with a "REPLY" and send - a request to the "Delegate". There is currently no protocol - limitation to delegation depth. It is possible for the original - - delegate to delegate the meeting to someone else, and so on. When a - request is delegated from one CUA to another there are a number of - responsibilities required of the "Delegator". The "Delegator" MUST: - - . Send a "REPLY" to the "Organizer" with the following updates: - . The "Delegator's" "ATTENDEE" property "partstat" parameter set - to "delegated" and the "delegated-to" parameter is set to the - address of the "Delegate" - . Add an additional "ATTENDEE" property for the "Delegate" with - the "delegated-from" property parameter set to the "Delegator" - . Indicate whether they want to continue to receive updates when - the "Organizer" sends out updated versions of the event. - Setting the "rsvp" property parameter to "TRUE" will cause the - updates to be sent, setting it to "FALSE" causes no further - updates to be sent. Note that in either case, if the "Delegate" - declines the invitation the "Delegator" will be notified. - . The "Delegator" MUST also send a copy of the original "REQUEST" - method to the "Delegate". - - It is not required that the "Delegate" include the "Delegator" in - their "REPLY" method. However, it is strongly advised since this will - inform the "Delegator" whether the "Delegate" plans to attend the - meeting. [Editors note: How so?] If the "Delegate" declines the - meeting, the "Delegator" may elect to delegate the "REQUEST" to - another CUA. The process is the same. - - - - - -Silverberg, et. al. Standards Track [Page 68] - -RFC 2446 iTIP November 1998 - - -+---------------------------------------------------------------------+ -| Action | "Organizer" | Attendee | -+---------------------------------------------------------------------+ -| Initiate a meeting | "A" sends a REQUEST | | -| request | message to "B" and | | -| | "C" | | -+---------------------------------------------------------------------+ -| Delegate: | | "C" sends a REPLY to "A" | -| "C" delegates to | | with the ATTENDEE. | -| "E" | | "partstat" parameter set | -| | | to "delegated" and with a| -| | | new "ATTENDEE" property | -| | | for "E". "E's" ATTENDEE | -| | | "delegated-from" param | -| | | is set to "C". "C's" | -| | | ATTENDEE "delegated-to" | -| | | param is set to "E". | -| | | "C" sends REQUEST message| -| | | to "E" with the original | -| | | meeting request | -| | | information. The | -| | | "partstat" property | -| | | parameter for "C" is set | -| | | to "delegated" and the | -| | | "delegated-to" | -| | | parameter is set to | -| | | the address of "E". An | -| | | "ATTENDEE" property is | -| | | added for "E" and the | -| | | "delegated-from" | -| | | parameter is set to | -| | | the address of "C". | -+---------------------------------------------------------------------+ -| Confirm meeting | | "E" sends REPLY message | -| attendance | | to "A" and optionally "C"| -| | | with its "partstat" | -| | | property parameter set | -| | | to "ACCEPTED" | -+---------------------------------------------------------------------+ -| Optional: | "A" sends REQUEST | | -| Redistribute | message to "B", "C" | | -| meeting to | and "E". | | -| attendees | | | -+---------------------------------------------------------------------+ - - - - - - - -Silverberg, et. al. Standards Track [Page 69] - -RFC 2446 iTIP November 1998 - - - "C" responds to the "Organizer". - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:MAILTO:A@Example.com - ATTENDEE;PARTSTAT=DELEGATED;DELEGATED- - TO="Mailto:E@example.com":Mailto:C@example.com - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - REQUEST-STATUS:2.0;Success - DTSTAMP:19970611T190000Z - END:VEVENT - END:VCALENDAR - - Attendee "C" delegates presence at the meeting to "E". - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;PARTSTAT=DELEGATED;DELEGATED- - TO="Mailto:E@example.com":Mailto:C@example.com - ATTENDEE;RSVP=TRUE; - DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com - DTSTART:19970701T180000Z - DTEND:19970701T200000Z - SUMMARY:Phone Conference - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - STATUS:CONFIRMED - DTSTAMP:19970611T190000Z - END:VEVENT - END:VCALENDAR - -4.2.6 Delegate Accepts the Meeting - - To accept a delegated meeting, the delegate, "E", sends the following - message to "A" and "C": - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - - - -Silverberg, et. al. Standards Track [Page 70] - -RFC 2446 iTIP November 1998 - - - BEGIN:VEVENT - ORGANIZER:MAILTO:A@Example.com - ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED- - FROM="Mailto:C@example.com":Mailto:E@example.com - ATTENDEE;PARTSTAT=DELEGATED; - DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - REQUEST-STATUS:2.0;Success - DTSTAMP:19970614T190000Z - END:VEVENT - END:VCALENDAR - -4.2.7 Delegate Declines the Meeting - - In this example the "Delegate" declines the meeting request and sets - the "ATTENDEE" property "partstat" parameter to "DECLINED". The - "Organizer" SHOULD resend the "REQUEST" to "C" with the "partstat" - parameter of the "Delegate" set to "declined". This lets the - "Delegator" know that the "Delegate" has declined and provides an - opportunity to the "Delegator" to either accept the request or - delegate it to another CU. - - Response from "E" to "A" and "C". Note the use of the "COMMENT" - property "E" uses to indicate why the delegation was declined. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:MAILTO:A@Example.com - ATTENDEE;PARTSTAT=DELEGATED; - DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com - ATTENDEE;PARTSTAT=DECLINED; - DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com - COMMENT:Sorry, I will be out of town at that time. - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - REQUEST-STATUS:2.0;Success - DTSTAMP:19970614T190000Z - END:VEVENT - END:VCALENDAR - - "A" resends the "REQUEST" method to "C". "A" may also wish to express - the fact that the item was delegated in the "COMMENT" property. - - - - - -Silverberg, et. al. Standards Track [Page 71] - -RFC 2446 iTIP November 1998 - - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:MAILTO:A@Example.com - ATTENDEE;PARTSTAT=DECLINED; - DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com - ATTENDEE;RSVP=TRUE:Mailto:C@example.com - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - SUMMARY:Phone Conference - DTSTART:19970701T180000Z - DTEND:19970701T200000Z - DTSTAMP:19970614T200000Z - COMMENT:DELEGATE (ATTENDEE Mailto:E@example.com) DECLINED YOUR - INVITATION - END:VEVENT - END:VCALENDAR - -4.2.8 Forwarding an Event Request - - The protocol does not prevent an "Attendee" from "forwarding" an - "VEVENT" calendar component to other "Calendar Users". Forwarding - differs from delegation in that the forwarded "Calendar User" (often - referred to as a "Party Crasher") does not replace the forwarding - "Calendar User". Implementations are not required to add the "Party - Crasher" to the "Attendee" list and hence there is no guarantee that - a "Party Crasher" will receive additional updates to the Event. The - forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the - attendee list. The "Organizer" MAY add the forwarded "Calendar User" - to the attendee list. - -4.2.9 Cancel A Group Event - - Individual "A" requests a meeting between individuals "A", "B", "C", - and "D". Individual "B" declines attendance to the meeting. - Individual "A" decides to cancel the meeting. The following table - illustrates the sequence of messages that would be exchanged between - these individuals. - - Messages related to a previously canceled event ("SEQUENCE" property - value is less than the "SEQUENCE" property value of the "CANCEL" - message) MUST be ignored. - - - - - - - -Silverberg, et. al. Standards Track [Page 72] - -RFC 2446 iTIP November 1998 - - - +--------------------------------------------------------------------+ - | Action | "Organizer" | "Attendee" | - +--------------------------------------------------------------------+ - | Initiate a meeting | "A" sends a REQUEST | | - | request | message to "B", "C",| | - | | and "D" | | - +--------------------------------------------------------------------+ - | Decline the meeting| | "B" sends a "REPLY" | - | request | | message to "A" with its | - | | | "partstat" para- | - | | | set to "declined". | - +--------------------------------------------------------------------+ - | Cancel the meeting | "A" sends a CANCEL | | - | | message to "B", "C" | | - | | and "D" | | - +--------------------------------------------------------------------+ - - The example shows how "A" cancels the event. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:CANCEL - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;TYPE=INDIVIDUAL;Mailto:A@example.com - ATTENDEE;TYPE=INDIVIDUAL:Mailto:B@example.com - ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com - ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com - COMMENT:Mr. B cannot attend. It's raining. Lets cancel. - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:1 - STATUS:CANCELLED - DTSTAMP:19970613T190000Z - END:VEVENT - END:VCALENDAR - - - - - - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 73] - -RFC 2446 iTIP November 1998 - - -4.2.10 Removing Attendees - - "A" wants to remove "B" from a meeting. This is done by sending a - "CANCEL" to "B" and removing "B" from the attendee list in the master - copy of the event. - - +--------------------------------------------------------------------+ - | Action | "Organizer" | "Attendee" | - +--------------------------------------------------------------------+ - | Remove an "B" | "A" sends a CANCEL | | - | as an "Attendee" | message to "B" | | - +--------------------------------------------------------------------+ - | Update the master | "A" sends the | | - | copy of the event | updated event to | | - | | the remaining | | - | | "Attendees" | | - +--------------------------------------------------------------------+ - - The original meeting includes "A", "B", "C", and "D". The example - below shows the "CANCEL" that "A" sends to "B". Note that in the - example below the "STATUS" property is omitted. This is used when the - meeting itself is cancelled and not when the intent is to remove an - "Attendee" from the Event. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:CANCEL - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE:mailto:B@example.com - COMMENT:You're off the hook for this meeting - UID:calsrv.example.com-873970198738777@example.com - DTSTAMP:19970613T193000Z - SEQUENCE:1 - END:VEVENT - END:VCALENDAR - - The updated master copy of the event is shown below. The "Organizer" - MAY resend the updated event to the remaining "Attendees". Note that - "B" has been removed. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - - - -Silverberg, et. al. Standards Track [Page 74] - -RFC 2446 iTIP November 1998 - - - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com - ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com - ATTENDEE;TYPE=ROOM:CR_Big@example.com - ATTENDEE;ROLE=NON-PARTICIPANT; - RSVP=FALSE:Mailto:E@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970701T200000Z - DTEND:19970701T203000Z - SUMMARY:Phone Conference - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:2 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.2.11 Replacing the Organizer - - The scenario for this example begins with "A" as the "Organizer" for - a recurring meeting with "B", "C", and "D". "A" receives a new job - offer in another country and drops out of touch. "A" left no - forwarding address or way to be reached. Using out-of-band - communication, the other "Attendees" eventually learn what has - happened and reach an agreement that "B" should become the new - "Organizer" for the meeting. To do this, "B" sends out a new version - of the event and the other "Attendees" agree to accept "B" as the new - "Organizer". "B" also removes "A" from the event. - - When the "Organizer" is replaced, the "SEQUENCE" property value MUST - be incremented. - - This is the message "B" sends to "C" and "D" - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:B@example.com - ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:Mailto:B@example.com - ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com - ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970701T200000Z - DTEND:19970701T203000Z - RRULE:FREQ=WEEKLY - SUMMARY:Phone Conference - UID:123456@example.com - - - -Silverberg, et. al. Standards Track [Page 75] - -RFC 2446 iTIP November 1998 - - - SEQUENCE:1 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.3 Busy Time Examples - - Busy time objects can be used in several ways. First, a CU may - request busy time from another CU for a specific range of time. That - request can be answered with a busy time Reply. Additionally, a CU - may simply publish their busy time for a given interval and point - other CUs to the published location. The following examples outline - both scenarios. - - Individual "A" publishes busy time for one week. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - VERSION:2.0 - METHOD:PUBLISH - BEGIN:VFREEBUSY - DTSTAMP:19980101T124100Z - ORGANIZER:MAILTO:A@Example.com - DTSTART:19980101T124200Z - DTEND:19980107T124200Z - FREEBUSY:19980101T180000Z/19980101T190000Z - FREEBUSY:19980103T020000Z/19980103T050000Z - FREEBUSY:19980107T020000Z/19980107T050000Z - FREEBUSY:19980113T000000Z/19980113T010000Z - FREEBUSY:19980115T190000Z/19980115T200000Z - FREEBUSY:19980115T220000Z/19980115T230000Z - FREEBUSY:19980116T013000Z/19980116T043000Z - END:VFREEBUSY - END:VCALENDAR - - Individual "A" requests busy time from individuals "B", "C". - Individual "B" and "C" replies with busy time data to individual "A". - The following table illustrates the sequence of messages that would - be exchanged between these individuals. - - - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 76] - -RFC 2446 iTIP November 1998 - - -+--------------------------------------------------------------------+ -| Action | "Organizer" | Attendee | -+--------------------------------------------------------------------+ -| Initiate a busy | "A" sends "REQUEST" | | -| time request | message to "B" and | | -| | and "C" | | -+--------------------------------------------------------------------+ -| Reply to the "BUSY"| | "B" sends a "REPLY" | -| request with "BUSY"| | message to "A" with | -| time data | | busy time data | -+--------------------------------------------------------------------+ - -4.3.1 Request Busy Time - - "A" sends a "BUSY-REQUEST" to "B" and "C" for busy time - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VFREEBUSY - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - ATTENDEE:Mailto:C@example.com - DTSTAMP:19970613T190000Z - DTSTART:19970701T080000Z - DTEND:19970701T200000 - UID:calsrv.example.com-873970198738777@example.com - END:VFREEBUSY - END:VCALENDAR - -4.3.2 Reply To A Busy Time Request - - "B" sends a "REPLY" method type of a "VFREEBUSY" calendar component - to "A" - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VFREEBUSY - ORGANIZER:MAILTO:A@example.com - ATTENDEE:Mailto:B@example.com - DTSTART:19970701T080000Z - DTEND:19970701T200000Z - UID:calsrv.example.com-873970198738777@example.com - FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M - - - -Silverberg, et. al. Standards Track [Page 77] - -RFC 2446 iTIP November 1998 - - - DTSTAMP:19970613T190030Z - END:VFREEBUSY - END:VCALENDAR - - "B" is busy from 09:00 to 10:00 and from 14:00 to 14:30. - -4.4 Recurring Event and Time Zone Examples - -4.4.1 A Recurring Event Spanning Time Zones - - This event describes a weekly phone conference. The "Attendees" are - each in a different time zone. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VTIMEZONE - TZID:America-SanJose - TZURL:http://zones.stds_r_us.net/tz/America-SanJose - BEGIN:STANDARD - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 - TZOFFSETFROM:-0700 - TZOFFSETTO:-0800 - TZNAME:PST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 - TZOFFSETFROM:-0800 - TZOFFSETTO:-0700 - TZNAME:PDT - END:DAYLIGHT - END:VTIMEZONE - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:A@example.COM - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:B@example.fr - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:c@example.jp - DTSTAMP:19970613T190030Z - DTSTART;TZID=America-SanJose:19970701T140000 - DTEND;TZID=America-SanJose:19970701T150000 - RRULE:FREQ=WEEKLY;INTERVAL=20;WKST=SU;BYDAY=TU - RDATE;TZID=America-SanJose:19970910T140000 - EXDATE;TZID=America-SanJose:19970909T140000 - EXDATE;TZID=America-SanJose:19971028T140000 - SUMMARY:Weekly Phone Conference - - - -Silverberg, et. al. Standards Track [Page 78] - -RFC 2446 iTIP November 1998 - - - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - The first two components of this iCalendar object are the time zone - components. The "DTSTART" date coincides with the first instance of - the RRULE property. - - The recurring meeting is defined in a particular time zone, - presumably that of the originator. The client for each "Attendee" has - the responsibility of determining the recurrence time in the - "Attendee's" time zone. - - The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT. - "Attendee" B@example.fr is in France where the local time on this - date is 9 hours ahead of PDT or 23:00. "Attendee" C@example.jp is in - Japan where local time is 8 hours ahead of UTC or Wednesday, July 2 - at 06:00. The event repeats weekly on Tuesdays (in PST/PDT). The - "RRULE" property results in 20 instances. The last instance falls on - Tuesday, November 11, 1997 2:00pm PDT. The "RDATE" property adds - another instance: WED, 10-SEP-1997 2:00 PM PST. - - There are two exceptions to this recurring appointment. The first one - is: - - TUE, 09-SEP-1997 23:00 GMT - TUE, 09-SEP-1997 14:00 PDT - WED, 10-SEP-1997 06:00 JST - - and the second is: - - TUE, 28-OCT-1997 23:00 GMT - TUE, 28-OCT-1997 14:00 PST - WED, 29-OCT-1997 06:00 JST - -4.4.2 Modify A Recurring Instance - - In this example the "Organizer" issues a recurring meeting. Later the - "Organizer" changes an instance of the event by changing the - "DTSTART" property. Note the use of "RECURRENCE-ID" property and - "SEQUENCE" property in the second request. - - Original Request: - - BEGIN:VCALENDAR - METHOD:REQUEST - - - -Silverberg, et. al. Standards Track [Page 79] - -RFC 2446 iTIP November 1998 - - - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@host1.com - SEQUENCE:0 - RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - ATTENDEE:Mailto:C@example.com - ATTENDEE:Mailto:D@example.com - DESCRIPTION:IETF-C&S Conference Call - CLASS:PUBLIC - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970601T210000Z - DTEND:19970601T220000Z - LOCATION:Conference Call - DTSTAMP:19970526T083000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - The event request below is to change the time of a specific instance. - This changes the July 1st instance to July 3rd. - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@host1com - RECURRENCE-ID:19970701T210000Z - SEQUENCE:1 - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - ATTENDEE:Mailto:C@example.com - ATTENDEE:Mailto:D@example.com - DESCRIPTION:IETF-C&S Conference Call - CLASS:PUBLIC - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970703T210000Z - DTEND:19970703T220000Z - LOCATION:Conference Call - DTSTAMP:19970626T093000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - - -Silverberg, et. al. Standards Track [Page 80] - -RFC 2446 iTIP November 1998 - - -4.4.3 Cancel an Instance - - In this example the "Organizer" of a recurring event deletes the - August 1st instance. - - BEGIN:VCALENDAR - METHOD:CANCEL - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@host1.com - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - ATTENDEE:Mailto:C@example.com - ATTENDEE:Mailto:D@example.com - RECURRENCE-ID:19970801T210000Z - SEQUENCE:2 - STATUS:CANCELLED - DTSTAMP:19970721T093000Z - END:VEVENT - END:VCALENDAR - -4.4.4 Cancel Recurring Event - - In this example the "Organizer" wishes to cancel the entire recurring - event and any exceptions. - - BEGIN:VCALENDAR - METHOD:CANCEL - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@host1.com - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - ATTENDEE:Mailto:C@example.com - ATTENDEE:Mailto:D@example.com - DTSTAMP:19970721T103000Z - STATUS:CANCELLED - SEQUENCE:3 - END:VEVENT - END:VCALENDAR - - - - - - - -Silverberg, et. al. Standards Track [Page 81] - -RFC 2446 iTIP November 1998 - - -4.4.5 Change All Future Instances - - This example changes the meeting location from a conference call to - Seattle starting September 1 and extends to all future instances. - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@host1.com - RECURRENCE-ID;THISANDFUTURE:19970901T210000Z - SEQUENCE:3 - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - ATTENDEE;RSVP=TRUE:Mailto:C@example.com - ATTENDEE;RSVP=TRUE:Mailto:D@example.com - DESCRIPTION:IETF-C&S Discussion - CLASS:PUBLIC - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970901T210000Z - DTEND:19970901T220000Z - LOCATION:Building 32, Microsoft, Seattle, WA - DTSTAMP:19970526T083000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.4.6 Add A New Instance To A Recurring Event - - This example adds a one-time additional instance to the recurring - event. "Organizer" adds a second July meeting on the 15th. - - BEGIN:VCALENDAR - METHOD:ADD - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@host1.com - SEQUENCE:4 - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - ATTENDEE;RSVP=TRUE:Mailto:C@example.com - ATTENDEE;RSVP=TRUE:Mailto:D@example.com - DESCRIPTION:IETF-C&S Conference Call - CLASS:PUBLIC - - - -Silverberg, et. al. Standards Track [Page 82] - -RFC 2446 iTIP November 1998 - - - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970715T210000Z - DTEND:19970715T220000Z - LOCATION:Conference Call - DTSTAMP:19970629T093000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.4.7 Add A New Series of Instances To A Recurring Event - - The scenario for this example involves an ongoing meeting, originally - set up to occur every Tuesday. The "Organizer" later decides that - the meetings need to be on Tuesdays and Thursdays, but does not want - to reschedule the entire meeting or lose any of the per-instance - information already collected. - - The original event: - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@host1.com - SEQUENCE:0 - RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - SUMMARY:Review Accounts - DTSTART:19980303T210000Z - DTEND:19980303T220000Z - LOCATION:The White Room - DTSTAMP:19980301T093000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - Assume that many other updates happen to this event and that a lot of - instance-specific information exists in the recurring series. The - "SEQUENCE" property value is 7 for the next update. Now the - "Organizer" wants to add Thursdays to the event: - - BEGIN:VCALENDAR - METHOD:ADD - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - - - -Silverberg, et. al. Standards Track [Page 83] - -RFC 2446 iTIP November 1998 - - - BEGIN:VEVENT - UID:123456789@host1.com - SEQUENCE:7 - RRULE:WKST=SU;BYDAY=TH;FREQ=WEEKLY - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - SUMMARY:Review Accounts - DTSTART:19980303T210000Z - DTEND:19980303T220000Z - DTSTAMP:19980303T193000Z - LOCATION:The Usual conference room - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - Alternatively, if the "Organizer" is not concerned with per-instance - updates, the entire event can be rescheduled using a "REQUEST". This - is done by using the "UID" of the event to reschedule and including - the modified "RRULE". Note, that since this is an entire rescheduling - of the event, any instance-specific information will be lost. - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@host1.com - SEQUENCE:7 - RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - SUMMARY:Review Accounts - DTSTART:19980303T210000Z - DTEND:19980303T220000Z - DTSTAMP:19980303T193000Z - LOCATION:The White Room - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - The next series of examples illustrate how an "Organizer" would - respond to a "REFRESH" submitted by an "Attendee" after a series of - instance-specific modifications. To convey all instance-specific - changes, the "Organizer" must provide the latest event description - and the relevant instances. The first three examples show the history - including the initial "VEVENT" request and subsequent instance - - - -Silverberg, et. al. Standards Track [Page 84] - -RFC 2446 iTIP November 1998 - - - changes and finally the "REFRESH". - - Original Request: - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@host1.com - SEQUENCE:0 - RDATE:19980304T180000Z - RDATE:19980311T180000Z - RDATE:19980318T180000Z - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - SUMMARY:Review Accounts - DTSTART:19980304T180000Z - DTEND:19980304T200000Z - DTSTAMP:19980303T193000Z - LOCATION:Conference Room A - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - Organizer changes 2nd instance Location and Time: - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@host1.com - SEQUENCE:1 - RECURRENCE-ID:19980311T180000Z - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - SUMMARY:Review Accounts - DTSTART:19980311T160000Z - DTEND:19980311T180000Z - DTSTAMP:19980306T193000Z - LOCATION:The Small conference room - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - - - -Silverberg, et. al. Standards Track [Page 85] - -RFC 2446 iTIP November 1998 - - - Organizer adds a 4th instance of the meeting using the "ADD" method - - BEGIN:VCALENDAR - METHOD:ADD - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@host1.com - SEQUENCE:2 - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - SUMMARY:Review Accounts - DTSTART:19980315T180000Z - DTEND:19980315T200000Z - DTSTAMP:19980307T193000Z - LOCATION:Conference Room A - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - If "B" requests a "REFRESH", "A" responds with the following to - capture all instance-specific data. In this case both the initial - request and an additional "VEVENT" that specifies the instance- - specific data are included. Because these are both of the same type - (they are both "VEVENTS"), they can be conveyed in the same iCalendar - object. - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@host1.com - SEQUENCE:2 - RDATE:19980304T180000Z - RDATE:19980311T160000Z - RDATE:19980315T180000Z - Error! Bookmark not defined. - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - SUMMARY:Review Accounts - DTSTART:19980304T180000Z - DTEND:19980304T200000Z - DTSTAMP:19980303T193000Z - LOCATION:Conference Room A - STATUS:CONFIRMED - - - -Silverberg, et. al. Standards Track [Page 86] - -RFC 2446 iTIP November 1998 - - - END:VEVENT - - BEGIN:VEVENT - Error! Bookmark not defined. - SEQUENCE:2 - RECURRENCE-ID:19980311T160000Z - Error! Bookmark not defined. - ATTENDEE;ROLE=CHAIR;Error! Bookmark not defined. - ATTENDEE;Error! Bookmark not defined. - SUMMARY:Review Accounts - DTSTART:19980311T160000Z - DTEND:19980304T180000Z - DTSTAMP:19980306T193000Z - LOCATION:The Small conference room - STATUS:CONFIRMED - END:VEVENT - - END:VCALENDAR - -4.4.8 Counter An Instance Of A Recurring Event - - In this example one of the "Attendees" counters the "DTSTART" - property of the proposed second July meeting. - - BEGIN:VCALENDAR - METHOD:COUNTER - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@host1.com - RECURRENCE-ID:19970715T210000Z - SEQUENCE:4 - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;RSVP=TRUE:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - ATTENDEE;RSVP=TRUE:Mailto:C@example.com - ATTENDEE;RSVP=TRUE:Mailto:D@example.com - DESCRIPTION:IETF-C&S Conference Call - CLASS:PUBLIC - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970715T220000Z - DTEND:19970715T230000Z - LOCATION:Conference Call - COMMENT:May we bump this by an hour? I have a conflict - DTSTAMP:19970629T094000Z - END:VEVENT - END:VCALENDAR - - - - -Silverberg, et. al. Standards Track [Page 87] - -RFC 2446 iTIP November 1998 - - -4.4.9 Error Reply To A Request - - The following example illustrates a scenario where a meeting is - proposed containing an unsupported property and a bad property. - - Original Request - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@host1.com - SEQUENCE:0 - RRULE:FREQ=MONTHLY;BYMONTHDAY=1 - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - ATTENDEE;RSVP=TRUE:Mailto:C@example.com - ATTENDEE;RSVP=TRUE:Mailto:D@example.com - DESCRIPTION:IETF-C&S Conference Call - CLASS:PUBLIC - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970601T210000Z - DTEND:19970601T220000Z - DTSTAMP:19970602T094000Z - LOCATION:Conference Call - STATUS:CONFIRMED - FOO:BAR - END:VEVENT - END:VCALENDAR - - Response from "B" to indicate that RRULE is not supported and an - unrecognized property was encountered - - BEGIN:VCALENDAR - PRODID:-//RDU Software//NONSGML HandCal//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - REQUEST-STATUS:2.8;Repeating event ignored. Scheduled as a single - event;RRULE - REQUEST-STATUS:3.0;Invalid Property Name;FOO - UID:guid-1@host1.com - SEQUENCE:0 - DTSTAMP:19970603T094000Z - - - -Silverberg, et. al. Standards Track [Page 88] - -RFC 2446 iTIP November 1998 - - - END:VEVENT - END:VCALENDAR - -4.5 Group To-do Examples - - Individual "A" creates a group task in which individuals "A", "B", - "C" and "D" will participate. Individual "B" confirms acceptance of - the task. Individual "C" declines the task. Individual "D" - tentatively accepts the task. The following table illustrates the - sequence of messages that would be exchanged between these - individuals. Individual "A" then issues a "REQUEST" method to obtain - the status of the to-do from each participant. The response indicates - the individual "Attendee's" completion status. The table below - illustrates the message flow. - -+--------------------------------------------------------------------+ -| Action | "Organizer" | Attendee | -+--------------------------------------------------------------------+ -| Initiate a to-do | "A" sends a REQUEST | | -| request | message to "B", "C",| | -| | and "D" | | -+--------------------------------------------------------------------+ -| Accept the to-do | | "B" sends a "REPLY" | -| request | | message to "A" with its | -| | | "partstat" paramater | -| | | set to "accepted". | -+--------------------------------------------------------------------+ -| Decline the to-do | | "C" sends a REPLY | -| request | | message to "A" with its | -| | | "partstat" parameter | -| | | set to "declined". | -+--------------------------------------------------------------------+ -| Tentatively accept | | "D" sends a REPLY | -| the to-do request | | message to "A" with its | -| | | "partstat" parameter | -| | | set to "tentative". | -+--------------------------------------------------------------------+ -| Check attendee | "A" sends a REQUEST | | -| completion status | message to "B" and | | -| | "D" with current | | -| | information. | | -+--------------------------------------------------------------------+ -| Attendee indicates | | "B" sends a "REPLY" | -| percent complete | | message indicating | -| | | percent complete | - - - - - - -Silverberg, et. al. Standards Track [Page 89] - -RFC 2446 iTIP November 1998 - - -+--------------------------------------------------------------------+ -| Attendee indicates | | "D" sends a "REPLY" | -| completion | | message indicating | -| | | completion | -+--------------------------------------------------------------------+ - -4.5.1 A VTODO Request - - A sample "REQUEST" for a "VTODO" calendar component that "A" sends to - "B", "C", and "D". - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR:Mailto:A@example.com - ATTENDEE;RSVP=TRUE:Mailto:B@example.com - ATTENDEE;RSVP=TRUE:Mailto:C@example.com - ATTENDEE;RSVP=TRUE:Mailto:D@example.com - DTSTART:19970701T170000Z - DUE:19970722T170000Z - PRIORITY:1 - SUMMARY:Create the requirements document - UID:calsrv.example.com-873970198738777-00@example.com - SEQUENCE:0 - DTSTAMP:19970717T200000Z - STATUS:Needs Action - END:VTODO - END:VCALENDAR - -4.5.2 A VTODO Reply - - "B" accepts the to-do. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:Mailto:A@example.com - ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com - UID:calsrv.example.com-873970198738777-00@example.com - COMMENT:I'll send you my input by e-mail - SEQUENCE:0 - DTSTAMP:19970717T203000Z - REQUEST-STATUS:2.0;Success - - - -Silverberg, et. al. Standards Track [Page 90] - -RFC 2446 iTIP November 1998 - - - END:VTODO - END:VCALENDAR - - "B" could have declined the TODO or indicated tentative acceptance by - setting the "partstat" property parameter sequence to "declined" or - "tentative", respectively. - -4.5.3 A VTODO Request for Updated Status - - "A" requests status from all "Attendees". - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR:Mailto:A@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com - UID:calsrv.example.com-873970198738777-00@example.com - SUMMARY:Create the requirements document - PRIORITY:1 - SEQUENCE:0 - STATUS:IN-PROCESS - DTSTART:19970701T170000Z - DTSTAMP:19970717T230000Z - END:VTODO - END:VCALENDAR - -4.5.4 A Reply: Percent-Complete - - A reply indicating the task being worked on and that "B" is 75% - complete with "B's" part of the assignment. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:MAILTO:A@example.com - ATTENDEE;PARTSTAT=IN-PROCESS:Mailto:B@example.com - PERCENT-COMPLETE:75 - UID:calsrv.example.com-873970198738777-00@example.com - DTSTAMP:19970717T233000Z - SEQUENCE:0 - END:VTODO - END:VCALENDAR - - - -Silverberg, et. al. Standards Track [Page 91] - -RFC 2446 iTIP November 1998 - - -4.5.5 A Reply: Completed - - A reply indicating that "D" completed "D's" part of the assignment. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:MAILTO:A@example.com - ATTENDEE;PARTSTAT=COMPLETED:Mailto:D@example.com - UID:calsrv.example.com-873970198738777-00@example.com - DTSTAMP:19970717T233000Z - SEQUENCE:0 - END:VTODO - END:VCALENDAR - -4.5.6 An Updated VTODO Request - - Organizer "A" resends the "VTODO" calendar component. "A" sets the - overall completion for the to-do at 40%. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:Mailto:B@example.com - ATTENDEE;PARTSTAT=IN-PROCESS;TYPE=INDIVIDUAL:Mailto:D@example.com - DTSTART:19970701T170000Z - DUE:19970722T170000Z - PRIORITY:1 - SUMMARY:Create the requirements document - UID:calsrv.example.com-873970198738777-00@example.com - SEQUENCE:1 - DTSTAMP:19970718T100000Z - STATUS:IN-PROGRESS - PERCENT-COMPLETE:40 - END:VTODO - END:VCALENDAR - -4.5.7 Recurring VTODOs - - The following examples relate to recurring "VTODO" calendar - components. - - - - -Silverberg, et. al. Standards Track [Page 92] - -RFC 2446 iTIP November 1998 - - -4.5.7.1 Request for a Recurring VTODO - - In this example "A" sends a recurring "VTODO" calendar component to - "B" and "D". - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR:Mailto:A@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com - ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com - RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR - DTSTART:19980101T100000-0700 - DUE:19980103T100000-0700 - SUMMARY:Send Status Reports to Area Managers - UID:calsrv.example.com-873970198738777-00@example.com - SEQUENCE:0 - DTSTAMP:19970717T200000Z - STATUS:NEEDS ACTION - PRIORITY:1 - END:VTODO - END:VCALENDAR - -4.5.7.2 Calculating due dates in recurring VTODOs - - The due date in a recurring "VTODO" calendar component is either a - fixed interval specified in the "REQUEST" method or specified using - the "RECURRENCE-ID" property. The former is calculated by applying - the difference between "DTSTART" and "DUE" properties and applying it - to each of the start of each recurring instance. Hence, if the - initial "VTODO" calendar component specifies a "DTSTART" property - value of "19970701T190000Z" and a "DUE" property value of - "19970801T190000Z" the interval of one day which is applied to each - recurring instance of the "VTODO" calendar component to determine the - "DUE" date of the instance. - -4.5.7.3 Replying to an instance of a recurring VTODO - - In this example "B" updates "A" on a single instance of the "VTODO" - calendar component. - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REPLY - VERSION:2.0 - - - -Silverberg, et. al. Standards Track [Page 93] - -RFC 2446 iTIP November 1998 - - - BEGIN:VTODO - ATTENDEE;PARTSTAT=IN-PROCESS:Mailto:B@example.com - PERCENT-COMPLETE:75 - UID:calsrv.example.com-873970198738777-00@example.com - DTSTAMP:19970717T233000Z - RECURRENCE-ID:19980101T170000Z - SEQUENCE:1 - END:VTODO - END:VCALENDAR - -4.6 Journal Examples - - The iCalendar object below describes a single journal entry for - October 2, 1997. The "RELATED-TO" property references the phone - conference event for which minutes were taken. - - BEGIN:VCALENDAR - METHOD:PUBLISH - PRODID:-//ACME/DesktopCalendar//EN - VERSION:2.0 - BEGIN:VJOURNAL - DTSTART:19971002T200000Z - ORGANIZER:MAILTO:A@Example.com - SUMMARY:Phone conference minutes - DESCRIPTION:The editors meeting was held on October 1, 1997. - Details are in the attached document. - UID:0981234-1234234-2410@example.com - RELATED-TO:0981234-1234234-2402-35@example.com - ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt - END:VJOURNAL - END:VCALENDAR - -4.7 Other Examples - -4.7.1 Event Refresh - - Refresh the event with "UID" property value of "guid-1- - 12345@host1.com": - - BEGIN:VCALENDAR - PRODID:-//RDU Software//NONSGML HandCal//EN - METHOD:REFRESH - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - ATTENDEE:Mailto:C@example.com - - - -Silverberg, et. al. Standards Track [Page 94] - -RFC 2446 iTIP November 1998 - - - ATTENDEE:Mailto:D@example.com - UID: guid-1-12345@host1.com - DTSTAMP:19970603T094000 - END:VEVENT - END:VCALENDAR - -4.7.2 Bad RECURRENCE-ID - - Component instances are identified by the combination of "UID", - "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends a request - to an "Attendee", there are three cases in which an instance cannot - be found. They are: - - 1. The component with the referenced "UID" and "RECURRENCE-ID" has - been found but the "SEQUENCE" number in the calendar store does - not match that of the ITIP message. - - 2. The component with the referenced "UID" has been found, the - "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be - found. - - 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not - support recurrences. - - In case (1), two things can happen. If the "SEQUENCE" number of the - "Attendee's" instance is larger than that in the "Organizer's" - message then the "Attendee" is receiving an out-of-sequence message - and MUST ignore it. If the "SEQUENCE" number of the "Attendee's" - instance is smaller, then the "Organizer" is sending out a newer - version of the component and the "Attendee's" version needs to be - updated. Since one or more updates have been missed, the "Attendee" - SHOULD send a "REFRESH" message to the "Organizer" to get an updated - version of the event. - - In case (2), something has gone wrong. Both the "Organizer" and the - "Attendee" should have the same instances, but the "Attendee" does - not have the referenced instance. In this case the "Attendee" SHOULD - send a "REFRESH" to the "Organizer" to get an updated version of the - event. - - In case (3), the limitations of the "Attendee's" CUA makes it - impossible to match an instance other than the single instance - scheduled. In this case, the "Attendee" need not send a "REFRESH" to - the "Organizer". - - The example below shows a sequence in which an "Attendee" sends a - "REFRESH" to the "Organizer". - - - - -Silverberg, et. al. Standards Track [Page 95] - -RFC 2446 iTIP November 1998 - - -+--------------------------------------------------------------------+ -| Action | "Organizer" | Attendee | -+--------------------------------------------------------------------+ -| Update an instance | "A" sends "REQUEST"| | -| request | message to "B" | | -+--------------------------------------------------------------------+ -| Attendee requests | | "B" sends a "REFRESH" | -| refresh because | | message to "A" | -| "RECURRENCE-ID" was| | | -| not found | | | -+--------------------------------------------------------------------+ -| Refresh the entire | "A" sends the | | -| Event | latest copy of the | | -| | Event to "B" | | -+--------------------------------------------------------------------+ -| Attendee handles | | "B" updates to the | -| the request and | | latest copy of the | -| updates the | | meeting. | -| instance | | | -+--------------------------------------------------------------------+ - - Request from "A": - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VEVENT - UID:acme-12345@host1.com - SEQUENCE:3 - RRULE:FREQ=WEEKLY - RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z - ORGANIZER:Mailto:A@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - DESCRIPTION:IETF-C&S Conference Call - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970801T210000Z - DTEND:19970801T220000Z - RECURRENCE-ID:19970809T210000Z - DTSTAMP:19970726T083000 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - "B" has the event with "UID" property "acme-12345@host1.com" but - "B's" "SEQUENCE" property value is "1" and the event does not have an - instance at the specified recurrence time. This means that "B" has - - - -Silverberg, et. al. Standards Track [Page 96] - -RFC 2446 iTIP November 1998 - - - missed at least one update and needs a new copy of the event. "B" - requests the latest copy of the event with the following refresh - message: - - BEGIN:VCALENDAR - PRODID:-//RDU Software//NONSGML HandCal//EN - METHOD:REFRESH - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:Mailto:A@example.com - ATTENDEE:Mailto:B@example.com - UID:acme-12345@host1.com - DTSTAMP:19970603T094000 - END:VEVENT - END:VCALENDAR - -5 Application Protocol Fallbacks - -5.1 Partial Implementation - - Applications that support this memo are not required to support the - entire protocol. The following describes how methods and properties - SHOULD "fallback" in applications that do not support the complete - protocol. If a method or property is not addressed in this section, - it may be ignored. - -5.1.1 Event-Related Fallbacks - -Method Fallback --------------- ----------------------------------------------------- -PUBLISH Required -REQUEST PUBLISH -REPLY Required -ADD Required -CANCEL Required -REFRESH Required -COUNTER Reply with Not Supported -DECLINECOUNTER Required if EVENT-COUNTER is implemented; otherwise - reply with Not Supported - -iCalendar -Property Fallback --------------- ----------------------------------------------------- -CALSCALE Ignore; assume GREGORIAN -PRODID Ignore -METHOD Required as described in the Method list above -VERSION Ignore - - - - -Silverberg, et. al. Standards Track [Page 97] - -RFC 2446 iTIP November 1998 - - -Event-Related -Components Fallback --------------- ----------------------------------------------------- -VALARM Reply with Not Supported -VTIMEZONE Required if any DateTime value refers to a time zone. - -Component -Property Fallback --------------- ----------------------------------------------------- -ATTACH Ignore -ATTENDEE Required if EVENT-REQUEST is not implemented; - otherwise reply with Not Supported -CATEGORIES Ignore -CLASS Ignore -COMMENT Ignore -COMPLETED Ignore -nCONTACT Ignore -CREATED Ignore -DESCRIPTION Required -DURATION Reply with Not Supported -DTSTAMP Required -DTSTART Required -DTEND Required -EXDATE Ignore -EXRULE Ignore Reply with Not Supported. If implemented, - VTIMEZONE MUST also be implemented. -GEO Ignore -LAST-MODIFIED Ignore -LOCATION Required -ORGANIZER Ignore -PRIORITY Ignore -RELATED-TO Ignore -RDATE Ignore -RRULE Ignore. The first instance occurs on the DTStart - property. If implemented, VTIMEZONE MUST also be - implemented. -RECURRENCE-ID Required if RRULE is implemented; otherwise Ignore -REQUEST-STATUS Required -RESOURCES Ignore -SEQUENCE Required -STATUS Ignore -SUMMARY Ignore -TRANSP Required if FREEBUSY is implemented; otherwise Ignore -URL Ignore -UID Required -X- Ignore - - - - - -Silverberg, et. al. Standards Track [Page 98] - -RFC 2446 iTIP November 1998 - - -5.1.2 Free/Busy-Related Fallbacks - -Method Fallback --------------- ----------------------------------------------------- -PUBLISH Implementations MAY ignore the METHOD type. The - REQUEST-STATUS "3.14;Unsupported capability" MUST be - returned. -REQUEST Implementations MAY ignore the METHOD type. The - REQUEST-STATUS "3.14;Unsupported capability" MUST be - returned. -REPLY Implementations MAY ignore the METHOD type. The - REQUEST-STATUS "3.14;Unsupported capability" MUST be - returned. - - -iCalendar -Property Fallback --------------- ----------------------------------------------------- -CALSCALE Ignore; assume GREGORIAN. -PRODID Ignore -METHOD Required as described in the Method list above. -VERSION Ignore - - -Component -Property Fallback --------------- ----------------------------------------------------- -COMMENT Ignore -CONTACT Ignore -DTEND Required -DTSTAMP Required -DTSTART Required -DURATION Required -FREEBUSY Required -ORGANIZER Ignore -REQUEST-STATUS Ignore -UID Required -URL Ignore -X- Ignore - -5.1.3 To-Do-Related Fallbacks - -Method Fallback --------------- ----------------------------------------------------- -PUBLISH Required -REQUEST PUBLISH -REPLY Required -ADD Required - - - -Silverberg, et. al. Standards Track [Page 99] - -RFC 2446 iTIP November 1998 - - -CANCEL Required -REFRESH Required -COUNTER Reply with Not Supported -DECLINECOUNTER Required if VTODO - COUNTER is implemented; otherwise - reply with Not Supported - -iCalendar -Property Fallback --------------- ----------------------------------------------------- -CALSCALE Ignore; assume GREGORIAN. -PRODID Ignore -METHOD Required as described in the Method list above. -VERSION Ignore - - -To-Do-Related -Components Fallback --------------- ----------------------------------------------------- -VALARM Reply with Not Supported -VTIMEZONE Required if any DateTime value refers to a time zone. - - -Component -Property Fallback --------------- ----------------------------------------------------- -ATTACH Ignore -ATTENDEE Required if REQUEST is not implemented; otherwise - ignore -CATEGORIES Ignore -CLASS Ignore -COMMENT Ignore -COMPLETED Required -CONTACT Ignore -CREATED Ignore -DESCRIPTION Required -DUE Required -DURATION Ignore Reply with Not Supported -DTSTAMP Required -DTSTART Required -EXDATE Ignore Reply with Not Supported -EXRULE Ignore Reply with Not Supported. If implemented, - VTIMEZONE MUST also be implemented. -LAST-MODIFIED Ignore -LOCATION Ignore -ORGANIZER Ignore -PERCENT-COMPLETE Ignore -PRIORITY Required -RECURRENCE-ID Ignore - - - -Silverberg, et. al. Standards Track [Page 100] - -RFC 2446 iTIP November 1998 - - -RELATED-TO Ignore -REQUEST-STATUS Ignore -RDATE Ignore -RRULE Ignore. The first instance occurs on the DTSTART - property. If implemented, VTIMEZONE MUST also be - implemented. -RESOURCES Ignore -SEQUENCE Required -STATUS Required -SUMMARY Ignore -URL Ignore -UID Required -X- Ignore - -5.1.4 Journal-Related Fallbacks - - -Method Fallback --------------- ----------------------------------------------------- -PUBLISH Implementations MAY ignore the METHOD type. The - REQUEST-STATUS "3.14;Unsupported capability" MUST be - returned. -ADD Implementations MAY ignore the METHOD type. The - REQUEST-STATUS "3.14;Unsupported capability" MUST be - returned. -CANCEL Implementations MAY ignore the METHOD type. The - REQUEST-STATUS "3.14;Unsupported capability" MUST be - returned. - - -iCalendar -Property Fallback --------------- ----------------------------------------------------- -CALSCALE Ignore; assume GREGORIAN. -PRODID Ignore -METHOD Required as described in the Method list above. -VERSION Ignore - - -Journal-Related -Components Fallback --------------- ----------------------------------------------------- -VTIMEZONE Required if any DateTime value refers to a time zone. - - - - - - - - -Silverberg, et. al. Standards Track [Page 101] - -RFC 2446 iTIP November 1998 - - -Component -Property Fallback --------------- ----------------------------------------------------- -ATTACH Ignore -ATTENDEE Required if JOURNAL-REQUEST is implemented; otherwise - ignore -CATEGORIES Ignore -CLASS Ignore -COMMENT Ignore -CONTACT Ignore -CREATED Ignore -DESCRIPTION Required -DTSTAMP Required -DTSTART Required -EXDATE Ignore -EXRULE Ignore Reply with Not Supported. If implemented, - VTIMEZONE MUST also be implemented. -LAST-MODIFIED Ignore -ORGANIZER Ignore -RECURRENCE-ID Ignore -RELATED-TO Ignore -RDATE Ignore. -RRULE Ignore. The first instance occurs on the DTSTART - property. If implemented, VTIMEZONE MUST also be - implemented. -SEQUENCE Required -STATUS Ignore -SUMMARY Required -URL Ignore -UID Required -X- Ignore - -5.2 Latency Issues - - With a store-and-forward transport, it is possible for events to - arrive out of sequence. That is, a "CANCEL" method may be received - prior to receiving the associated "REQUEST" for the calendar - component. This section discusses a few of these scenarios. - -5.2.1 Cancellation of an Unknown Calendar Component. - - When a "CANCEL" method is received before the original "REQUEST" - method the calendar will be unable to correlate the "UID" property of - the cancellation with an existing calendar component. It is suggested - that messages that can not be correlated that also contain non-zero - sequence numbers be held and not discarded. Implementations MAY age - them out if no other messages arrive with the same "UID" property - value and a lower sequence number. - - - -Silverberg, et. al. Standards Track [Page 102] - -RFC 2446 iTIP November 1998 - - -5.2.2 Unexpected Reply from an Unknown Delegate - - When an "Attendee" delegates an item to another CU they MUST send a - "REPLY" method to the "Organizer" using the "ATTENDEE" properties to - indicate that the request was delegated and to whom. Hence, it is - possible for an "Organizer" to receive an "REPLY" from a CU not - listed as one of the original "Attendees". The resolution is left to - the implementation but it is expected that the calendaring software - will either accept the reply or hold it until the related "REPLY" - method is received from the "Delegator". If the version of the - "REPLY" method is out of date the "Organizer" SHOULD treat the - message as a "REFRESH" message and update the delegate with the - correct version. - -5.3 Sequence Number - - Under some conditions, a CUA may receive requests and replies with - the same "SEQUENCE" property value. The "DTSTAMP" property is - utilized as a tie-breaker when two items with the same "SEQUENCE" - property value are evaluated. - -6 Security Considerations - - ITIP is an abstract transport protocol which will be bound to a - real-time transport, a store-and-forward transport, and perhaps other - transports. The transport protocol will be responsible for providing - facilities for authentication and encryption using standard Internet - mechanisms that are mutually understood between the sender and - receiver. - -6.1 Security Threats - -6.1.1 Spoofing the "Organizer" - - In iTIP, the "Organizer" (or someone working on the "Organizer's" - behalf) is the only person authorized to make changes to an existing - "VEVENT", "VTODO", "VJOURNAL" calendar component and republish it or - redistribute updates to the "Attendees". An iCalendar object that - maliciously changes or cancels an existing "VEVENT", "VTODO" or - "VJOURNAL" calendar component may be constructed by someone other - than the "Organizer" and republished or sent to the "Attendees". - -6.1.2 Spoofing the "Attendee" - - In iTIP, an "Attendee" of a "VEVENT" or "VTODO" calendar component - (or someone working on the "Attendee's" behalf) is the only person - authorized to update any parameter associated with their "ATTENDEE" - property and send it to the "Organizer". An iCalendar object that - - - -Silverberg, et. al. Standards Track [Page 103] - -RFC 2446 iTIP November 1998 - - - maliciously changes the "ATTENDEE" parameters may be constructed by - someone other than the real "Attendee" and sent to the "Organizer". - -6.1.3 Unauthorized Replacement of the Organizer - - There will be circumstances when "Attendees" of an event or to-do - decide, using out-of-band mechanisms, that the "Organizer" must be - replaced. When the new "Organizer" sends out the updated "VEVENT" or - "VTODO" the "Attendee's" CUA will detect that the "Organizer" has - been changed, but it has no way of knowing whether or not the change - was mutually agreed upon. - -6.1.4 Eavesdropping - - The iCalendar object is constructed with human-readable clear text. - Any information contained in an iCalendar object may be read and/or - changed by unauthorized persons while the object is in transit. - -6.1.5 Flooding a Calendar - - Implementations MAY provide a means to automatically incorporate - "REQUEST" methods into a calendar. This presents the opportunity for - a calendar to be flooded with requests, which effectively block all - the calendar's free time. - -6.1.6 Procedural Alarms - - The "REQUEST" methods for "VEVENT" and "VTODO" calendar components - MAY contain "VALARM" calendar components. The "VALARM" calendar - component may be of type "PROCEDURE" and MAY have an attachment - containing an executable program. Implementations that incorporate - these types of alarms are subject to any virus or malicious attack - that may occur as a result of executing the attachment. - -6.1.7 Unauthorized REFRESH Requests - - It is possible for an "Organizer" to receive a "REFRESH" request from - someone who is not an "Attendee" of an event or to-do. Only - "Attendee's" of an event or to-do are authorized to receive replies - to "REFRESH" requests. Replying to such requests to anyone who is not - an "Attendee" may be a security problem. - -6.2 Recommendations - - For an application where the information is sensitive or critical and - the network is subject is subject to a high probability of attack, - iTIP transactions SHOULD be encrypted. This may be accomplished using - public key technology, specifically Security Multiparts for MIME - - - -Silverberg, et. al. Standards Track [Page 104] - -RFC 2446 iTIP November 1998 - - - [RFC-1847] in the iTIP transport binding. This helps mitigate the - threats of spoofing, eavesdropping and malicious changes in transit. - -6.2.1 Use of [RFC-1847] to secure iTIP transactions - - iTIP transport bindings MUST provide a mechanism based on Security - Multiparts for MIME [RFC-1847] to enable authentication of the - sender's identity, and privacy and integrity of the data being - transmitted. This allows the receiver of a signed iCalendar object to - verify the identity of the sender. This sender may then be correlated - to an "ATTENDEE" property in the iCalendar object. If the correlation - is made and the sender is authorized to make the requested change or - update then the operation may proceed. It also allows the message to - be encrypted to prevent unauthorized reading of the message contents - in transit. iTIP transport binding documents describe this process in - detail. - - Implementations MAY provide controls for users to disable this - capability. - -6.2.2 Implementation Controls - - The threat of unauthorized replacement of the "Organizer" SHOULD be - mitigated by a calendar system that uses this protocol by providing - controls or alerts that make "Calendar Users" aware of such - "Organizer" changes and allowing them to decide whether or not the - request should be honored. - - The threat of flooding a calendar SHOULD be mitigated by a calendar - system that uses this protocol by providing controls that may be used - to limit the acceptable sources for iTIP transactions, and perhaps - the size of messages and volume of traffic, by source. - - The threat of malicious procedural alarms SHOULD be mitigated by a - calendar system that uses this protocol by providing controls that - may be used to disallow procedural alarms in iTIP transactions and/or - remove all alarms from the object before delivery to the recipient. - - The threat of unauthorized "REFRESH" requests SHOULD be mitigated by - a calendar system that uses this protocol by providing controls or - alerts that allow "Calendar User" to decide whether or not the - request should be honored. An implementation MAY decide to maintain, - for audit or historical purposes, "Calendar Users" who were part of - an attendee list and who were subsequently uninvited. Similar - controls or alerts should be provided when a "REFRESH" request is - received from these "Calendar Users" as well. - - - - - -Silverberg, et. al. Standards Track [Page 105] - -RFC 2446 iTIP November 1998 - - -7 Acknowledgments - - A hearty thanks to the following individuals who have participated in - the drafting, review and discussion of this memo: - - Anik Ganguly, Dan Hickman, Paul Hill, Daryl Huff, Bruce Kahn, Antoine - Leca, Bob Mahoney, John Noerenberg, Leo Parker, John Rose, Doug - Royer, Vinod Seraphin, Richard Shusterman, Derik Stenerson, John Sun, - Alexander Taler, Kevin Tsurutome. - -8 Bibliography - - [iCAL] Dawson, F. and D. Stenerson, "Internet Calendaring and - Scheduling Core Object Specification - iCalendar", RFC - 2445, November 1998. - - [iMIP] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar - Message-Based Interoperability Protocol - iMIP", RFC 2447, - November 1998. - - [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [US-ASCII] Coded Character Set--7-bit American Standard Code for - Information Interchange, ANSI X3.4-1986. - - - - - - - - - - - - - - - - - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 106] - -RFC 2446 iTIP November 1998 - - -9 Authors' Addresses - - The following address information is provided in a vCard v3.0, - Electronic Business Card, format. - - The authors of this memo are: - - BEGIN:VCARD - VERSION:3.0 - N:Dawson;Frank - FN:Frank Dawson - ORG:Lotus Development Corporation - ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613- - 3502;USA - TEL;TYPE=WORK,MSG:+1-919-676-9515 - TEL;TYPE=WORK,FAX:+1-919-676-9564 - EMAIL;TYPE=PREF,INTERNET:Frank_Dawson@Lotus.com - EMAIL;TYPE=INTERNET:fdawson@earthlink.net - URL:http://home.earthlink.net/~fdawson - END:VCARD - - BEGIN:VCARD - VERSION:3.0 - N:Hopson;Ross - FN:Ross Hopson - ORG:On Technology, Inc. - ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 1600;434 Fayetteville St. - Mall\, Two Hannover Square;Raleigh;NC;27601 - TEL;TYPE=WORK,MSG:+1-919-890-4036 - TEL;TYPE=WORK,FAX:+1-919-890-4100 - EMAIL;TYPE=INTERNET:rhopson@on.com - END:VCARD - - BEGIN:VCARD - VERSION:3.0 - N:Mansour;Steve - FN:Steve Mansour - ORG:Netscape Communications Corporation - ADR;TYPE=WORK,POSTAL,PARCEL:;;501 East Middlefield Road;Mountain - View;CA;94043;USA - TEL;TYPE=WORK,MSG:+1-650-937-2378 - TEL;TYPE=WORK,FAX:+1-650-937-2103 - EMAIL;TYPE=INTERNET:sman@netscape.com - END:VCARD - - - - - - - -Silverberg, et. al. Standards Track [Page 107] - -RFC 2446 iTIP November 1998 - - - BEGIN:VCARD - VERSION:3.0 - N:Silverberg;Steve - FN:Steve Silverberg - ORG:Microsoft Corporation - ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way; - Redmond;WA;98052-6399;USA - TEL;TYPE=WORK,MSG:+1-425-936-9277 - TEL;TYPE=WORK,FAX:+1-425-936-8019 - EMAIL;INTERNET:stevesil@Microsoft.com - END:VCARD - - The iCalendar object is a result of the work of the Internet - Engineering Task Force Calendaring and scheduling Working Group. The - chairman of that working group is: - - BEGIN:VCARD - VERSION:3.0 - N:Ganguly;Anik - FN:Anik Ganguly - ORG:Open Text Inc. - ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road; - Livonia;MI;48152;USA - TEL;TYPE=WORK,MSG:+1-734-542-5955 - EMAIL;TYPE=INTERNET:ganguly@acm.org - END:VCARD - - The co-chairman of that working group is: - - BEGIN:VCARD - VERSION:3.0 - N:Moskowitz;Robert - FN:Robert Moskowitz - NICKNAME:Bob - EMAIL; TYPE=INTERNET:rgm-ietf@htt-consult.com - END:VCARD - - - - - - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 108] - -RFC 2446 iTIP November 1998 - - -10. Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Silverberg, et. al. Standards Track [Page 109] - diff --git a/etc/rfc2447.pdf b/etc/rfc2447.pdf deleted file mode 100644 index 17c2f90..0000000 Binary files a/etc/rfc2447.pdf and /dev/null differ diff --git a/etc/rfc2447.txt b/etc/rfc2447.txt deleted file mode 100644 index c4f9790..0000000 --- a/etc/rfc2447.txt +++ /dev/null @@ -1,1011 +0,0 @@ - - - - - - -Network Working Group F. Dawson -Request for Comments: 2447 Lotus -Category: Standards Track S. Mansour - Netscape - S. Silverberg - Microsoft - November 1998 - - - iCalendar Message-Based Interoperability Protocol - (iMIP) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - This document, [iMIP], specifies a binding from the iCalendar - Transport-independent Interoperability Protocol (iTIP) to Internet - email-based transports. Calendaring entries defined by the iCalendar - Object Model [iCAL] are composed using constructs from [RFC-822], - [RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049]. - - This document is based on discussions within the Internet Engineering - Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. - More information about the IETF CALSCH working group activities can - be found on the IMC web site at http://www.imc.org, the IETF web site - at http://www.ietf.org/html.charters/calsch-charter.html. Refer to - the references within this document for further information on how to - access these various documents. - - - - - - - - - - - - -Dawson, et. al. Standards Track [Page 1] - -RFC 2447 iMIP November 1998 - - -Table of Contents - - 1 INTRODUCTION........................................................2 - 1.1 RELATED MEMOS ...................................................2 - 1.2 FORMATTING CONVENTIONS ..........................................3 - 1.3 TERMINOLOGY .....................................................4 - 2 MIME MESSAGE FORMAT BINDING.........................................4 - 2.1 MIME MEDIA TYPE .................................................4 - 2.2 SECURITY ........................................................4 - 2.2.1 Authorization ...............................................4 - 2.2.2 Authentication ..............................................5 - 2.2.3 Confidentiality .............................................5 - 2.3 [RFC-822] ADDRESSES .............................................5 - 2.4 CONTENT TYPE ....................................................5 - 2.5 CONTENT-TRANSFER-ENCODING .......................................6 - 2.6 CONTENT-DISPOSITION .............................................6 - 3 SECURITY CONSIDERATIONS.............................................7 - 4 EXAMPLES............................................................8 - 4.1 SINGLE COMPONENT WITH AN ATTACH PROPERTY ........................8 - 4.2 USING MULTIPART ALTERNATIVE FOR LOW FIDELITY CLIENTS ............8 - 4.3 SINGLE COMPONENT WITH AN ATTACH PROPERTY AND INLINE ATTACHMENT ..9 - 4.4 MULTIPLE SIMILAR COMPONENTS ....................................10 - 4.5 MULTIPLE MIXED COMPONENTS ......................................11 - 4.6 DETAILED COMPONENTS WITH AN ATTACH PROPERTY ....................13 - 5 RECOMMENDED PRACTICES..............................................14 - 5.1 USE OF CONTENT AND MESSAGE IDS .................................14 - 6 BIBLIOGRAPHY.......................................................15 - 7 AUTHORS' ADDRESSES.................................................16 - 8 FULL COPYRIGHT STATEMENT...........................................18 - -1 Introduction - - This binding document provides the transport specific information - necessary convey iCalendar Transport-independent Interoperability - Protocol (iTIP) over MIME as defined in [RFC-822] and [RFC-2045]. - -1.1 Related Memos - - Implementers will need to be familiar with several other memos that, - along with this memo, form a framework for Internet calendaring and - scheduling standards. - - This document, [iMIP], specifies an Internet email binding for iTIP. - - [iCAL] - specifies a core specification of objects, data types, - properties and property parameters; - - - - - -Dawson, et. al. Standards Track [Page 2] - -RFC 2447 iMIP November 1998 - - - [iTIP] - specifies an interoperability protocol for scheduling - between different implementations; - - This memo does not attempt to repeat the specification of concepts or - definitions from these other memos. Where possible, references are - made to the memo that provides for the specification of these - concepts or definitions. - -1.2 Formatting Conventions - - The mechanisms defined in this memo are defined in prose. In order to - refer to elements of the calendaring and scheduling model, core - object or interoperability protocol defined in [iCAL] and [iTIP] some - formatting conventions have been used. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this - document are to be interpreted as described in [RFC-2119]. - - Calendaring and scheduling roles are referred to in quoted-strings of - text with the first character of each word in upper case. For - example, "Organizer" refers to a role of a "Calendar User" within the - scheduling protocol defined by [iTIP]. - - Calendar components defined by [iCAL] are referred to with - capitalized, quoted-strings of text. All calendar components start - with the letter "V". For example, "VEVENT" refers to the event - calendar component, "VTODO" refers to the to-do calendar component - and "VJOURNAL" refers to the daily journal calendar component. - - Scheduling methods defined by [iTIP] are referred to with - capitalized, quoted-strings of text. For example, "REQUEST" refers to - the method for requesting a scheduling calendar component be created - or modified, "REPLY" refers to the method a recipient of a request - uses to update their status with the "Organizer" of the calendar - component. - - Properties defined by [iCAL] are referred to with capitalized, - quoted-strings of text, followed by the word "property". For example, - "ATTENDEE" property refers to the iCalendar property used to convey - the calendar address of a calendar user. - - Property parameters defined by [iCAL] are referred to with lower - case, quoted-strings of text, followed by the word "parameter". For - example, "value" parameter refers to the iCalendar property parameter - used to override the default data type for a property value. - - - - - -Dawson, et. al. Standards Track [Page 3] - -RFC 2447 iMIP November 1998 - - -1.3 Terminology - - The email terms used in this memo are defined in [RFC-822] and [RFC- - 2045]. The calendaring and scheduling terms used in this memo are - defined in [iCAL] and [iTIP]. - -2 MIME Message Format Binding - - This section defines the message binding to the MIME electronic mail - transport. - - The sections below refer to the "originator" and the "respondent" of - an iMIP message. Typically, the originator is the "Organizer" of an - event. The respondent is an "Attendee" of the event. - - The [RFC-822] "Reply-To" header typically contains the email address - of the originator or respondent of an event. However, this cannot be - guaranteed as Mail User Agents (MUA) are not required to enforce iMIP - semantics. - -2.1 MIME Media Type - - A MIME entity containing content information formatted according to - this document will be referenced as a "text/calendar" content type. - It is assumed that this content type will be transported through a - MIME electronic mail transport. - -2.2 Security - - This section addresses several aspects of security including - Authentication, Authorization and Confidentiality. Authentication and - confidentiality can be achieved using [RFC-1847] that specifies the - Security Multiparts for MIME. This framework defines new content - types and subtypes of multipart: signed and encrypted. Each contains - two body parts: one for the protected data and another for the - control information necessary to remove the protection. - -2.2.1 Authorization - - In [iTIP] messages, only the "Organizer" is authorized to modify or - cancel calendar entries they organize. That is, spoof@xyz.com is not - allowed to modify or cancel a meeting that was organized by - a@example.com. Furthermore, only the respondent has the authorization - to indicate their status to the "Organizer". That is, the "Organizer" - must ignore an [iTIP] message from spoof@xyz.com that declines a - meeting invitation for b@example.com. - - - - - -Dawson, et. al. Standards Track [Page 4] - -RFC 2447 iMIP November 1998 - - - Implementations of iMIP SHOULD verify the authenticity of the creator - of an iCalendar object before taking any action. The methods for - doing this are presented later in this document. - - [RFC-1847] Message flow in iTIP supports someone working on behalf of - a "Calendar User" through use of the "sent-by" parameter that is - associated with the "ATTENDEE" and "ORGANIZER" properties. However, - there is no mechanism to verify whether or not a "Calendar User" has - authorized someone to work on their behalf. It is left to - implementations to provide mechanisms for the "Calendar Users" to - make that decision. - -2.2.2 Authentication - - Authentication can be performed using an implementation of [RFC-1847] - "multipart/signed" that supports public/private key certificates. - Authentication is possible only on messages that have been signed. - Authenticating an unsigned message may not be reliable. - -2.2.3 Confidentiality - - To ensure confidentiality using iMIP implementations should utilize - [RFC-1847]-compliant encryption. The protocol does not restrict a - "Calendar User Agent" (CUA) from forwarding iCalendar objects to - other users or agents. - -2.3 [RFC-822] Addresses - - The calendar address specified within the "ATTENDEE" property in an - iCalendar object MUST be a fully qualified, [RFC-822] address - specification for the corresponding "Organizer" or "Attendee" of the - "VEVENT" or "VTODO". - - Because [iTIP] does not preclude "Attendees" from forwarding - "VEVENTS" or "VTODOS" to others, the [RFC-822] "Sender" value may not - equal that of the "Organizer". Additionally, the "Organizer" or - "Attendee" cannot be reliably inferred by the [RFC-822] "Sender" or - "Reply-to" values of an iMIP message. The relevant address MUST be - ascertained by opening the "text/calendar" MIME body part and - examining the "ATTENDEE" and "ORGANIZER" properties. - -2.4 Content Type - - A MIME body part containing content information that conforms to this - document MUST have an [RFC-2045] "Content-Type" value of - "text/calendar". The [RFC-2045] "Content-Type" header field must also - include the type parameter "method". The value MUST be the same as - the value of the "METHOD" calendar property within the iCalendar - - - -Dawson, et. al. Standards Track [Page 5] - -RFC 2447 iMIP November 1998 - - - object. This means that a MIME message containing multiple iCalendar - objects with different method values must be further encapsulated - with a "multipart/mixed" MIME entity. This will allow each of the - iCalendar objects to be encapsulated within their own "text/calendar" - MIME entity. - - A "charset" parameter MUST be present if the iCalendar object - contains characters that are not part of the US-ASCII character set. - [RFC-2046] discusses the selection of an appropriate "charset" value. - - The optional "component" parameter defines the iCalendar component - type contained within the iCalendar object. - - The following is an example of this header field with a value that - indicates an event message. - - Content-Type:text/calendar; method=request; charset=UTF-8; - component=vevent - - The "text/calendar" content type allows for the scheduling message - type to be included in a MIME message with other content information - (i.e., "multipart/mixed") or included in a MIME message with a - clear-text, human-readable form of the scheduling message (i.e., - "multipart/alternative"). - - In order to permit the information in the scheduling message to be - understood by MIME user agents (UA) that do not support the - "text/calendar" content type, scheduling messages SHOULD be sent with - an alternative, human-readable form of the information. - -2.5 Content-Transfer-Encoding - - Note that the default character set for iCalendar objects is UTF-8. A - transfer encoding SHOULD be used for iCalendar objects containing any - characters that are not part of the US-ASCII character set. - -2.6 Content-Disposition - - The handling of a MIME part should be based on its [RFC-2045] - "Content-Type". However, this is not guaranteed to work in all - environments. Some environments handle MIME attachments based on - their file type or extension. To operate correctly in these - environments, implementations may wish to include a "Content- - Disposition" property to define a file name. - - - - - - - -Dawson, et. al. Standards Track [Page 6] - -RFC 2447 iMIP November 1998 - - -3 Security Considerations - - The security threats that applications must address when implementing - iTIP are detailed in [iTIP]. Two spoofing threats are identified: - Spoofing the "Organizer", and Spoofing an "Attendee". To address - these threats, the originator of an iCalendar object must be - authenticated by a recipient. Once authenticated, a determination can - be made as to whether or not the originator is authorized to perform - the requested operation. Compliant applications MUST support signing - and encrypting text/calendar attachments using a mechanism based on - Security Multiparts for MIME [RFC-1847] to facilitate the - authentication the originator of the iCalendar object. - Implementations MAY provide a means for users to disable signing and - encrypting. The steps are described below: - - 1. The iCalendar object MUST be signed by the "Organizer" sending an - update or the "Attendee" sending a reply. - - 2. Using the [RFC-1847]-compliant security mechanism, determine who - signed the iCalendar object. This is the "signer". Note that the - signer is not necessarily the person sending an e-mail message since - an e-mail message can be forwarded. - - 3. Correlate the signer to an "ATTENDEE" property in the iCalendar - object. If the signer cannot be correlated to an "ATTENDEE" property, - ignore the message. - - 4. Determine whether or not the "ATTENDEE" is authorized to perform - the operation as defined by [iTIP]. If the conditions are not met, - ignore the message. - - 5. If all the above conditions are met, the message can be processed. - - To address the confidentiality security threats, signed iMIP messages - SHOULD be encrypted by a mechanism based on Security Multiparts for - MIME [RFC-1847]. - - It is possible to receive iMIP messages sent by someone working on - behalf of another "Calendar User". This is determined by examining - the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE" - property. [iCAL] and [iTIP] provide no mechanism to verify that a - "Calendar User" has authorized someone else to work on their behalf. - To address this security issue, implementations MUST provide - mechanisms for the "Calendar Users" to make that decision before - applying changes from someone working on behalf of a "Calendar User". - - - - - - -Dawson, et. al. Standards Track [Page 7] - -RFC 2447 iMIP November 1998 - - -4 Examples - -4.1 Single Component With An ATTACH Property - - This minimal message shows how an iCalendar object references an - attachment. The attachment is accessible via its URL. - - From: sman@netscape.com - To: stevesil@microsoft.com - Subject: Phone Conference - Mime-Version: 1.0 - Content-Type:text/calendar; method=REQUEST; charset=US-ASCII - Content-Transfer-Encoding: 7bit - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:sman@netscape.com - ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:sman@netscape.com - ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.com - DTSTAMP:19970611T190000Z - DTSTART:19970701T210000Z - DTEND:19970701T230000Z - SUMMARY:Phone Conference - DESCRIPTION:Please review the attached document. - UID:calsvr.example.com-873970198738777 - ATTACH:ftp://ftp.bar.com/pub/docs/foo.doc - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.2 Using Multipart Alternative for Low Fidelity Clients - - This example shows how a client can emit a multipart message that - includes both a plain text version as well as the full iCalendar - object. Clients that do not support text/calendar will still be - capable of rendering the plain text representation. - - From: foo1@example.com - To: foo2@example.com - Subject: Phone Conference - Mime-Version: 1.0 - Content-Type: multipart/alternative;boundary="01BD3665.3AF0D360" - - --01BD3665.3AF0D360 - Content-Type: text/plain;charset=us-ascii - - - -Dawson, et. al. Standards Track [Page 8] - -RFC 2447 iMIP November 1998 - - - Content-Transfer-Encoding: 7bit - - This is an alternative representation of a TEXT/CALENDAR MIME Object - When: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT - Where: - Organizer: foo1@example.com - Summary: Phone Conference - - --01BD3665.3AF0D360 - Content-Type:text/calendar; method=REQUEST; charset=US-ASCII - Content-Transfer-Encoding: 7bit - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:foo1@example.com - ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com - ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970701T170000Z - DTEND:19970701T173000Z - SUMMARY:Phone Conference - UID:calsvr.example.com-8739701987387771 - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - --01BD3665.3AF0D360 - -4.3 Single Component With An ATTACH Property and Inline Attachment - - This example shows how a message containing an iCalendar object - references an attached document. The reference is made using a - Content-id (CID). Thus, the iCalendar object and the document are - packaged in a multipart/related encapsulation. - - From: foo1@example.com - To: foo2@example.com - Subject: Phone Conference - Mime-Version: 1.0 - Content-Type: multipart/related; boundary="boundary-example-1"; - type=text/calendar - - --boundary-example-1 - - - - -Dawson, et. al. Standards Track [Page 9] - -RFC 2447 iMIP November 1998 - - - Content-Type:text/calendar; method=REQUEST; charset=US-ASCII - Content-Transfer-Encoding: 7bit - Content-Disposition: attachment; filename="event.vcs" - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:foo1@example.com - ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com - ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970701T180000Z - DTEND:19970701T183000Z - SUMMARY:Phone Conference - UID:calsvr.example.com-8739701987387771 - ATTACH:cid:123456789@example.com - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - --boundary-example-1 - Content-Type: application/msword; name="FieldReport.doc" - Content-Transfer-Encoding: base64 - Content-Disposition: inline; filename="FieldReport.doc" - Content-ID: <123456789@example.com> - - 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA - AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD///////////////////////////////// - - --boundary-example-1-- - -4.4 Multiple Similar Components - - Multiple iCalendar components of the same type can be included in the - iCalendar object when the METHOD is the same for each component. - - From: foo1@example.com - To: foo2@example.com - Subject: Summer Company Holidays - Mime-Version: 1.0 - Content-Type:text/calendar; method=PUBLISH; charset=US-ASCII - Content-Transfer-Encoding: 7bit - Content-Disposition: attachment; filename="event.vcs" - - - - - -Dawson, et. al. Standards Track [Page 10] - -RFC 2447 iMIP November 1998 - - - BEGIN:VCALENDAR - PRODID:-//ACME/DESKTOPCALENDAR//EN - METHOD:PUBLISH - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:MAILTO:FOO1@EXAMPLE.COM - DTSTAMP:19970611T150000Z - DTSTART:19970701T150000Z - DTEND:19970701T230000Z - SUMMARY:Company Picnic - DESCRIPTION:Food and drink will be provided - UID:CALSVR.EXAMPLE.COM-873970198738777-1 - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - BEGIN:VEVENT - ORGANIZER:MAILTO:FOO1@EXAMPLE.COM - DTSTAMP:19970611T190000Z - DTSTART:19970715T150000Z - DTEND:19970715T230000Z - SUMMARY:Company Bowling Tournament - DESCRIPTION:We have 10 lanes reserved - UID:CALSVR.EXAMPLE.COM-873970198738777-2 - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.5 Multiple Mixed Components - - Different component types must be encapsulated in separate iCalendar - objects. - - From: foo1@example.com - To: foo2@example.com - Subject: Phone Conference - Mime-Version: 1.0 - Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C" - - This is a multi-part message in MIME format. - - ----FEE3790DC7E35189CA67CE2C - Content-Type:text/calendar; method=REQUEST; charset=US-ASCII - Content-Transfer-Encoding: 7bit - Content-Disposition: attachment; filename="event1.vcs" - - - - - - -Dawson, et. al. Standards Track [Page 11] - -RFC 2447 iMIP November 1998 - - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:foo1@example.com - ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com - ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970701T210000Z - DTEND:19970701T230000Z - SUMMARY:Phone Conference - DESCRIPTION:Discuss what happened at the last meeting - UID:calsvr.example.com-8739701987387772 - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - ----FEE3790DC7E35189CA67CE2C - Content-Type:text/calendar; method=REQUEST; charset=US-ASCII - Content-Transfer-Encoding:7bit - Content-Disposition: attachment; filename="todo1.vcs" - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VTODO - DUE:19970701T090000-0700 - ORGANIZER:mailto:foo1@example.com - ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com - ATTENDEE;RSVP=YES:mailto:foo2@example.com - SUMMARY:Phone Conference - DESCRIPTION:Discuss a new location for the company picnic - UID:calsvr.example.com-td-8739701987387773 - SEQUENCE:0 - STATUS:NEEDS ACTION - END:VEVENT - END:VCALENDAR - - ----FEE3790DC7E35189CA67CE2C - - - - - - - - - -Dawson, et. al. Standards Track [Page 12] - -RFC 2447 iMIP November 1998 - - -4.6 Detailed Components With An ATTACH Property - - This example shows the format of a message containing a group meeting - between three individuals. The multipart/related encapsulation is - used because the iCalendar object contains an ATTACH property that - uses a CID to reference the attachment. - - From: foo1@example.com - MIME-Version: 1.0 - To: foo2@example.com,foo3@example.com - Subject: REQUEST - Phone Conference - Content-Type:multipart/related;boundary="--FEE3790DC7E35189CA67CE2C" - - ----FEE3790DC7E35189CA67CE2C - Content-Type: multipart/alternative; - boundary="--00FEE3790DC7E35189CA67CE2C00" - - ----00FEE3790DC7E35189CA67CE2C00 - Content-Type: text/plain; charset=us-ascii - Content-Transfer-Encoding: 7bit - - When: 7/1/1997 10:00PM PDT- 7/1/97 10:30 PM PDT - Where: - Organizer: foo1@example.com - Summary: Let's discuss the attached document - - ----00FEE3790DC7E35189CA67CE2C00 - - Content-Type:text/calendar; method=REQUEST; charset=US-ASCII; - Component=vevent - Content-Transfer-Encoding: 7bit - Content-Disposition: attachment; filename="event.vcs" - - BEGIN:VCALENDAR - PRODID:-//ACME/DesktopCalendar//EN - PROFILE:REQUEST - PROFILE-VERSION:1.0 - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:foo1@example.com - ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:foo1@example.com - ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com - ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo3@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970621T170000Z - DTEND:199706211T173000Z - SUMMARY:Let's discuss the attached document - UID:calsvr.example.com-873970198738777-8aa - - - -Dawson, et. al. Standards Track [Page 13] - -RFC 2447 iMIP November 1998 - - - ATTACH:cid:calsvr.example.com-12345aaa - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - ----00FEE3790DC7E35189CA67CE2C00 - - ----FEE3790DC7E35189CA67CE2C - Content-Type: application/msword; name="FieldReport.doc" - Content-Transfer-Encoding: base64 - Content-Disposition: inline; filename="FieldReport.doc" - Content-ID: - - - R0lGODdhTAQZAJEAAFVVVd3d3e4AAP///ywAAAAATAQZAAAC/5yPOSLhD6OctNqLs94XqAG - 4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvdriIH - 5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5iZnJY6J. - - ----FEE3790DC7E35189CA67CE2C - -5 Recommended Practices - - This section outlines a series of recommended practices when using a - messaging transport to exchange iCalendar objects. - -5.1 Use of Content and Message IDs - - The [iCAL] specification makes frequent use of the URI for data types - in properties such as "DESCRIPTION", "ATTACH", "CONTACT" and others. - Two forms of URIs are Message ID (MID) and Content ID (CID). These - are defined in [RFC-2111]. Although [RFC-2111] allows referencing - messages or MIME body parts in other MIME entities or stores, it is - strongly recommended that iMIP implementations include all referenced - messages and body parts in a single MIME entity. Simply put, if an - iCalendar object contains CID or MID references to other messages or - body parts, implementations should ensure that these messages and/or - body parts are transmitted with the iCalendar object. If they are not - there is no guarantee that the receiving "CU" will have the access or - the authorization to view those objects. - - - - - - - - - - - -Dawson, et. al. Standards Track [Page 14] - -RFC 2447 iMIP November 1998 - - -6 Bibliography - - [CHST] Character Sets, ftp://ftp.isi.edu/in- - notes/iana/assignments/character-sets - - [iCAL] Dawson, F. and D. Stenerson, "Internet Calendaring and - Scheduling Core Object Specification - iCalendar", RFC - 2445, November 1998. - - [iTIP] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson, - "iCalendar Transport-Independent Interoperability Protocol - (iTIP): Scheduling Events, Busy Time, To-dos and Journal - Entries", RFC 2446, November 1998. - - [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet - Text Messages", STD 11, RFC 822, August 1982. - - [RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, - "Security Multiparts for MIME: Multipart/Signed and - Multipart/Encrypted", RFC 1847, October 1995. - - [RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) - Part One: Format of Internet Message - Bodies", RFC 2045, November 1996. - - [RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) - Part Two: Media Types", RFC 2046, - November 1996. - - [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - - Part Three: Message Header Extensions for Non-ASCII Text", - RFC 2047, November 1996. - - [RFC-2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose - Internet Mail Extensions (MIME) - Part Four: Registration - Procedures", RFC 2048, January 1997. - - [RFC-2111] Levinson, E., "Content-ID and Message-ID Uniform Resource - Locators", RFC 2111, March 1997. - - [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - - - - - - - -Dawson, et. al. Standards Track [Page 15] - -RFC 2447 iMIP November 1998 - - -7 Authors' Addresses - - The following address information is provided in a vCard v3.0, - Electronic Business Card, format. - - BEGIN:VCARD - VERSION:3.0 - N:Dawson;Frank - FN:Frank Dawson - ORG:Lotus Development Corporation - ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford - Drive;Raleigh;NC;27613-3502;USA - TEL;TYPE=WORK,MSG:+1-919-676-9515 - TEL;TYPE=WORK,FAX:+1-919-676-9564 - EMAIL;TYPE=INTERNET:fdawson@earthlink.net - URL:http://home.earthlink.net/~fdawson - END:VCARD - - BEGIN:VCARD - VERSION:3.0 - N:Mansour;Steve - FN:Steve Mansour - ORG:Netscape Communications Corporation - ADR;TYPE=WORK,POSTAL,PARCEL:;;501 East Middlefield Road;Mountain - View;CA;94043;USA - TEL;TYPE=WORK,MSG:+1-650-937-2378 - TEL;TYPE=WORK,FAX:+1-650-937-2103 - EMAIL;TYPE=INTERNET:sman@netscape.com - END:VCARD - - BEGIN:VCARD - VERSION:3.0 - N:Silverberg;Steve - FN:Steve Silverberg - ORG:Microsoft Corporation - ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way; - Redmond;WA;98052-6399;USA - TEL;TYPE=WORK,MSG:+1-425-936-9277 - TEL;TYPE=WORK,FAX:+1-425-936-8019 - EMAIL;TYPE=INTERNET:stevesil@Microsoft.com - END:VCARD - - - - - - - - - - -Dawson, et. al. Standards Track [Page 16] - -RFC 2447 iMIP November 1998 - - - The iCalendar Object is a result of the work of the Internet - Engineering Task Force Calendaring and scheduling Working Group. The - chairmen of that working group are: - - BEGIN:VCARD - VERSION:3.0 - N:Ganguly;Anik - FN:Anik Ganguly - ORG:Open Text Inc. - ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road; - Livonia;MI;48152;USA - TEL;TYPE=WORK,MSG:+1-734-542-5955 - EMAIL;TYPE=INTERNET:ganguly@acm.org - END:VCARD - - BEGIN:VCARD - VERSION:3.0 - N:Moskowitz;Robert - FN:Robert Moskowitz - EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com - END:VCARD - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Dawson, et. al. Standards Track [Page 17] - -RFC 2447 iMIP November 1998 - - -8. Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Dawson, et. al. Standards Track [Page 18] - diff --git a/etc/rfc2739.txt b/etc/rfc2739.txt deleted file mode 100644 index 5c1dbbc..0000000 --- a/etc/rfc2739.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -Network Working Group T. Small -Request for Comments: 2739 XpertSite.Com -Category: Standards Track D. Hennessy - ISOCOR - F. Dawson - Lotus - January 2000 - - - Calendar Attributes for vCard and LDAP - - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - When scheduling a calendar entity, such as an event, it is a - prerequisite that an organizer has the calendar address of each - attendee that will be invited to the event. Additionally, access to - an attendee's current "busy time" provides an a priori indication of - whether the attendee will be free to participate in the event. - - In order to meet these challenges, a calendar user agent (CUA) needs - a mechanism to locate (URI) individual user's calendar and free/busy - time. - - This memo defines three mechanisms for obtaining a URI to a user's - calendar and free/busy time. These include: - - - Manual transfer of the information; - - - Personal data exchange using the vCard format; and - - - Directory lookup using the LDAP protocol. - - - - - - - -Small, et al. Standards Track [Page 1] - -RFC 2739 Locating a Calendar User January 2000 - - -Table of Contents - - 1 CALENDARING AND SCHEDULING URIS...................................3 - 1.1 FREE/BUSY URI (FBURL) .........................................3 - 1.2 CALENDAR ACCESS URI (CAPURI) ..................................4 - 1.3 CALENDAR URI (CALURI) .........................................4 - 1.4 DEFAULT URIS ..................................................4 - 2 DISTRIBUTION......................................................4 - 2.1 MANUAL TRANSFER ...............................................5 - 2.2 PERSONAL DATA EXCHANGE USING A VCARD ..........................5 - 2.3 VCARD SCHEMA EXTENSIONS .......................................5 - 2.3.1 FBURL Property IANA Registration ...........................6 - 2.3.2 CALADRURI Property IANA Registration .......................7 - 2.3.3 CAPURI Property IANA Registration ......................... 8 - 2.3.4 CALURI Property IANA Registration ......................... 8 - 2.4 DIRECTORY LOOKUP USING THE LDAP V3 PROTOCOL .................. 9 - 2.4.1 LDAP Schema Extensions .................................... 9 - 2.4.2 Notation ..................................................10 - 2.4.3 Object Definitions ........................................10 - 2.4.3.1 calEntry ..............................................10 - 2.4.4 Attribute Definitions .....................................10 - 2.4.4.1 calCalURI .............................................10 - 2.4.4.2 calFBURL ..............................................10 - 2.4.4.3 calCAPURI .............................................11 - 2.4.4.4 calCalAdrURI ..........................................11 - 2.4.4.5 calOtherCalURIs .......................................11 - 2.4.4.6 calOtherFBURLs ........................................11 - 2.4.4.7 calOtherCAPURIs .......................................12 - 2.4.4.8 calOtherCalAdrURIs ....................................12 - 3 IANA Considerations..............................................12 - 4 Security Considerations..........................................12 - 5 Acknowledgments..................................................13 - 6 Authors' Addresses...............................................13 - 7 Bibliography.....................................................15 - 8 Full Copyright Statement.........................................16 - - - - - - - - - - - - - - - - -Small, et al. Standards Track [Page 2] - -RFC 2739 Locating a Calendar User January 2000 - - -1 Calendaring and Scheduling URIs - - This memo defines four classes of URIs. URIs are more useful if it is - understood what the URIs point to. Here is a brief description: - -1.1 Free/Busy URI (FBURL) - - The free/busy URI is defined to be a transport independent location - where a client can obtain information about when a user is busy. At - the present time, this URI only points to busy time data. Future - revisions of this specification may provide for the extended - capability of publishing free time data. - - If a calendaring and scheduling client (i.e., CUA) were to retrieve - data from this location using FTP or HTTP, it would get back an - iCalendar object [4] containing one or more "VFREEBUSY" calendar - components. If a MIME transport is being used, the response will be - contained within a "text/calendar" MIME body part as specified in the - iCalendar specification [4]. For example: - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//hacksw/handcal//NONSGML v1.0//EN - METHOD:PUBLISH - BEGIN:VFREEBUSY - ATTENDEE:MAILTO:jane_doe@host1.com - DTSTART:19971013T050000Z - DTEND:19971124T050000Z - DTSTAMP:19970901T083000Z - FREEBUSY:19971015T133000Z/19971015T180000Z - FREEBUSY:19971015T190000Z/19971015T220000Z - FBURL:http://www.host.com/calendar/busy/jdoe.ifb - END:VFREEBUSY - END:VCALENDAR - - The amount of busy time data pointed to by the FBURL will generally - be pre-determined; for example one month of busy time data. As a - guideline, it is recommended that the previous six weeks of busy time - data be published at the location associated with the FBURL. If this - URI points to a file resource, it is recommended that the file - extension be "ifb" to distinguish it from an arbitrary iCalendar - object (e.g., with the "ics" file extension). - - - - - - - - - -Small, et al. Standards Track [Page 3] - -RFC 2739 Locating a Calendar User January 2000 - - -1.2 Calendar Access URI (CAPURI) - - The Calendar Access URI is defined to be a protocol independent - location from which a calendaring and scheduling client (i.e., CUA) - can communicate with a user's entire calendar. - - The semantics for using this URI as an access protocol locator are - yet to be defined by the IETF CALSCH Working Group. This will be - addressed in the "Calendar Access Protocol" specification. - -1.3 Calendar URI (CALURI) - - The Calendar URI is defined to be a protocol independent location - from which a calendaring and scheduling client (i.e. CUA) can - retrieve an entire copy of a user's calendar. Retrieving data from - this URI obtains a published "snapshot" of the user's calendar. - - HTTP URI -- If the URI is an HTTP URI, then the content returned with - a GET should be a "text/calendar" MIME body part containing one or - more iCalendar object. - - FTP URI -- If the URI is an FTP URI, then the resource pointed to - should be a file with an "ics" file extension containing one or more - iCalendar objects. - -1.4 Default URIs - - There are many cases where a user may have more than one calendar. In - these cases, a user may have multiple URIs, each URI pointing to a - calendar or free/busy data. - - To make the case of multiple calendars simpler for clients, the - concept of the "default" calendar is introduced. A "default" calendar - is one that the user has designated as the calendar that other users - should look at when accessing the user's calendar, or retrieving the - user's free/busy time. - - The default calendar may, in fact, include rolled-up information from - all the user's other calendars. The other calendars may only exist - for organizational purposes. - -2 Distribution - - These four URIs provide valuable pointers to calendaring and - scheduling data that other users need in order to know when to - schedule meetings, etc. There are several possibilities on how users - can communicate these URIs to other users. The following section - outlines how these URIs can be distributed to other users. - - - -Small, et al. Standards Track [Page 4] - -RFC 2739 Locating a Calendar User January 2000 - - -2.1 Manual Transfer - - The simplest way to obtain these URIs is for a user to communicate - the URIs using some out-of-band mechanism such as verbally, or in an - e-mail message, or by printing these URIs on a paper business card. - - When using this mechanism, the user obtains these URIs using an out- - of-band mechanism and then enters these URIs into their calendaring - software manually. - -2.2 Personal Data Exchange Using A vCard - - A more sophisticated way to obtain these URIs is for users to publish - vCards containing these URIs. The vCard object can be transferred - between one another. Since many e-mail clients allow a user to - automatically include a vCard with every message that the user sends, - this provides a simple, transparent way for a user to distribute - their calendaring and scheduling URIs. - - On the receiving end, an e-mail client that provides an integrated - vCard database can provide a way to lookup calendaring URIs for users - whose vCards are stored locally. - -2.3 vCard Schema Extensions - - Since the vCard [3] specification doesn't specify how to encode - calendaring URIs in a vCard, this section is provided as an extension - to vCard which specifies how to encode calendaring URIs within a - vCard. - - Inside a vCard object, four new properties are defined: "CALURI", - "CAPURI", "CALADRURI", and "FBURL", as defined above. - - Any vCard can have one or more of these properties, each representing - a calendar or free/busy time that is associated with the user. - - One of these properties can be designated as the "default" by adding - the "PREF" parameter. - - - - - - - - - - - - - -Small, et al. Standards Track [Page 5] - -RFC 2739 Locating a Calendar User January 2000 - - - Here is a simple example of a vCard containing a "FBURL" and a - "CALURI". - - BEGIN:VCARD - VERSION:3.0 - N:Dun;Alec - FN:Alec Dun - ORG:Microsoft Corporation - ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; - Redmond;WA;98052-6399;USA - TEL;WORK;MSG:+1-206-936-4544 - TEL;WORK;FAX:+1-206-936-7329 - EMAIL;INTERNET:user@host1.com - CALADRURI;PREF:mailto:user@host1.com - CALURI;PREF:http://cal.host1.com/user/cal.ics - FBURL;PREF:http://cal.host1.com/user/fb.ifb - CALURI:http://cal.company.com/projectA/pjtA.ics - FBURL:http://cal.company.com/projectA/pjtAfb.ifb - END:VCARD - -2.3.1 FBURL Property IANA Registration - - To: ietf-mime-directory@imc.org - - Subject: Registration of FBURL type for text/directory MIME type - vCard profile. - - Type name: FBURL - - Type purpose: To specify the URI for a user's busy time in a vCard - object. - - Type encoding: 8bit - - Type value: A single URI value. - - Type special notes: Where multiple FBURL properties are specified, - the default FBURL property is indicated with the PREF parameter. The - FTP or HTTP type of URI points to an iCalendar object associated with - a snapshot of the last six weeks of the user's busy time data. If the - iCalendar object is represented as a file or document, it's file type - should be "ifb". - - Intended usage: Refer to section 1.1. - - - - - - - -Small, et al. Standards Track [Page 6] - -RFC 2739 Locating a Calendar User January 2000 - - - Type examples: - - FBURL;PREF:http://www.host1.com/busy/janedoe - FBURL:FTP://ftp.host.com/busy/project-a.ifb - -2.3.2 CALADRURI Property IANA Registration - - To: ietf-mime-directory@imc.org - - Subject: Registration of CALADRURI type for application/directory - MIME type vCard profile. - - Type name: CALADRURI - - Type purpose: To specify the location to which an event request - should be sent for the user. - - Type encoding: 8bit - - Type value: A single URI value. - - Type special notes: Where multiple CALADRURI properties are - specified, the default CALADRURI property is indicated with the PREF - parameter. - - Intended usage: Refer to section 1.2. - - Type examples: - - CALADRURI;PREF:mailto:janedoe@host.com - - - - - - - - - - - - - - - - - - - - - -Small, et al. Standards Track [Page 7] - -RFC 2739 Locating a Calendar User January 2000 - - -2.3.3 CAPURI Property IANA Registration - - To: ietf-mime-directory@imc.org - - Subject: Registration of CAPURI type for application/directory MIME - type vCard profile. - - Type name: CAPURI - - Type purpose: To specify a protocol independent location from which a - calendaring and scheduling client (i.e., CUA) can communicate with a - user's entire calendar. - - Type encoding: 8bit - - Type value: A single URI value. - - Type special notes: Where multiple CAPURI properties are specified, - the default CAPURI property is indicated with the PREF parameter. - - Intended usage: Refer to section 1.3. - -2.3.4 CALURI Property IANA Registration - - To: ietf-mime-directory@imc.org - - Subject: Registration of CALURI type for text/directory MIME type - vCard profile. - - Type name: CALURI - - Type purpose: To specify the URI for a user's calendar in a vCard - object. - - Type encoding: 8bit - - Type value type: A single URI value. - - Type special notes: Where multiple CALURI properties are specified, - the default CALURI property is indicated with the PREF parameter. The - property should contain a URI pointing to an iCalendar object - associated with a snapshot of the user's calendar store. If the - iCalendar object is represented as a file or document, it's file type - should be "ics". - - Intended usage: Refer to section 1.4. - - - - - -Small, et al. Standards Track [Page 8] - -RFC 2739 Locating a Calendar User January 2000 - - - Type examples: - - CALURI;PREF:http://cal.host1.com/calA - CALURI:ftp://ftp.host1.com/calA.ics - -2.4 Directory Lookup Using The LDAP v3 Protocol - - Another way to obtain these URIs is to look them up in a directory - using the LDAP protocol [1]. - - If a user's URIs can be found using directory lookup (i.e., searching - for one of the LDAP schema extensions defined below), they should, in - general, be considered "more up-to-date" than URIs in any vCards that - are stored locally. - -2.4.1 LDAP Schema Extensions - - In order to encode the calendaring URIs in the directory, the - following are defined: - - - One object class: - - - calEntry - - - Eight attributes: - - - calCalURI - - - calFBURL - - - calCAPURI - - - calCalAdrURI - - - calOtherCalURIs - - - calOtherFBURLs - - - calOtherCAPURIs - - - calOtherCalAdrURIs - - The calCalURI contains the URI to a snapshot of the user's entire - default calendar. The calFBURL contains the URI to the user's default - busy time data. The calCAPURI represents contains a URI that can be - used to communicate with the user's calendar. The calCalAdrURI - contains a URI that points to the location to which event requests - should be sent for that user. - - - -Small, et al. Standards Track [Page 9] - -RFC 2739 Locating a Calendar User January 2000 - - - The calOtherCalURIs is a multi-valued property containing URIs to - snapshots of other calendars that the user may have. The - calOtherFBURLs is a multi-valued property containing URIs to other - free/busy data that the user may have. The calOtherCAPURIs attribute - is a multi-valued property containing URIs to other calendars that - the user may have. The calOtherCalAdrURIs attribute is a multi-valued - property containing URIs to other locations that a user may want - event requests sent to. - - There is no predetermined order to the values in either multi-valued - property. - -2.4.2 Notation - - The notation used in this memo is the same as that used in [2]. - -2.4.3 Object Definitions - -2.4.3.1 calEntry - - The Calendar Entry is a class derived from "TOP" [2], which contains - the four calendaring attributes. - - (1.2.840.113556.1.5.87 - NAME 'calEntry' - TOP - AUXILIARY - MAY (calCalURI calFBURL calOtherCalURIs calOtherFBURLs calCAPURI - calOtherCAPURLs) - ) - -2.4.4 Attribute Definitions - -2.4.4.1 calCalURI - - (1.2.840.113556.1.4.478 - NAME 'calCalURI' - EQUALITY caseIgnoreMatch - SUBSTRING caseIgnoreMatch - SYNTAX 'IA5String' - USAGE userApplications - ) - -2.4.4.2 calFBURL - - (1.2.840.113556.1.4.479 - NAME 'calFBURL' - EQUALITY caseIgnoreMatch - - - -Small, et al. Standards Track [Page 10] - -RFC 2739 Locating a Calendar User January 2000 - - - SUBSTRING caseIgnoreMatch - SYNTAX 'IA5String' - USAGE userApplications - ) - -2.4.4.3 calCAPURI - - (1.2.840.113556.1.4.480 - NAME 'calCAPURI' - EQUALITY caseIgnoreMatch - SUBSTRING caseIgnoreMatch - SYNTAX 'IA5String' - USAGE userApplications - ) - -2.4.4.4 calCalAdrURI - - (1.2.840.113556.1.4.481 - NAME 'calCalAdrURI' - EQUALITY caseIgnoreMatch - SUBSTRING caseIgnoreMatch - SYNTAX 'IA5String' - USAGE userApplications - ) - -2.4.4.5 calOtherCalURIs - - (1.2.840.113556.1.4.482 - NAME 'calOtherCalURIs' - EQUALITY caseIgnoreMatch - SUBSTRING caseIgnoreMatch - SYNTAX 'IA5String' - MULTI-VALUE - USAGE userApplications - ) - -2.4.4.6 calOtherFBURLs - - (1.2.840.113556.1.4.483 - NAME 'calOtherFBURLs' - EQUALITY caseIgnoreMatch - SUBSTRING caseIgnoreMatch - SYNTAX 'IA5String' - MULTI-VALUE - USAGE userApplications - ) - - - - - -Small, et al. Standards Track [Page 11] - -RFC 2739 Locating a Calendar User January 2000 - - -2.4.4.7 calOtherCAPURIs - - (1.2.840.113556.1.4.484 - NAME 'calOtherCAPURIs' - EQUALITY caseIgnoreMatch - SUBSTRING caseIgnoreMatch - SYNTAX 'IA5String' - MULTI-VALUE - USAGE userApplications - ) - -2.4.4.8 calOtherCalAdrURIs - - (1.2.840.113556.1.4.485 - NAME 'calOtherCalAdrURIs' - EQUALITY caseIgnoreMatch - SUBSTRING caseIgnoreMatch - SYNTAX 'IA5String' - MULTI-VALUE - USAGE userApplications - ) - -3 IANA Considerations - - This memo defines IANA registered extensions to the attributes - defined by LDAP [1] and vCard [3]. - - IANA registration proposals for vCard are to be emailed to the - registration agent for the "text/directory" MIME content-type, - using the format defined in - [3]. - -4 Security Considerations - - Standard vCard and LDAP security rules and support apply for the - extensions described in this document, and there are no special - security issues for these extensions. - - Please note, though, that LDAP servers may permit anonymous clients - to refresh entries which they did not create. Servers are also - permitted to control a refresh access to an entry by requiring - clients to bind before issuing a RefreshRequest. This will have - implications on the server performance and scalability. - - Please also note, though, that vCard objects may have been created by - an entity other than that represented by the vCard. Recipients should - be certain of the source that generated the vCard. - - - - -Small, et al. Standards Track [Page 12] - -RFC 2739 Locating a Calendar User January 2000 - - - Also, care should be taken in making use of information obtained from - directory servers that has been supplied by client, as it may now be - out of date. In many networks, for example, IP addresses are - automatically assigned when a host connects to the network, and may - be reassigned if that host later disconnects. An IP address obtained - from the directory may no longer be assigned to the host that placed - the address in the directory. This issue is not specific to LDAP or - dynamic directories. - -5 Acknowledgments - - The authors wish to acknowledge the work of Alec Dun, who acted as an - author for the early drafts of this memo. In addition, this document - received input from the various participants in the IETF CALSCH - Working Group discussions. - -6 Authors' Addresses - - The following address information is provided in a vCard v3.0 [3], - Electronic Business Card, format. - - BEGIN:VCARD - VERSION:3.0 - N:Small;Tony - FN:Tony Small - ORG:XpertSite.Com - ADR;TYPE=WORK,POSTAL,PARCEL:;;4700 42nd Ave. SW, Suite 440; - Seattle;WA;98116;USA - TEL;TYPE=WORK,MSG:+1-206-937-9972 - TEL;TYPE=WORK,FAX:+1-206-936-7329 - EMAIL;TYPE=INTERNET:tony@xpertsite.com - CALADRURI:MAILTO:tony@xpertsite.com - END:VCARD - - BEGIN:VCARD - VERSION:3.0 - N:Hennessy;Denis - FN:Denis Hennessy - ORG:ISOCOR - ADR;TYPE=WORK,POSTAL,PARCEL:;;42-47 Lower Mount St; - Dublin 2;Ireland - TEL;TYPE=WORK,MSG:+353-1-676-0366 - TEL;TYPE=WORK,FAX:+353-1-676-0856 - EMAIL;TYPE=INTERNET:denis.hennessy@isocor.com - CALADRURI:MAILTO:denis.hennessy@isocor.com - END:VCARD - - - - - -Small, et al. Standards Track [Page 13] - -RFC 2739 Locating a Calendar User January 2000 - - - BEGIN:VCARD - VERSION:3.0 - N:Dawson;Frank - FN:Frank Dawson - ORG:Lotus Development Corporation - ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive; - Raleigh;NC;27613-3502;USA - TEL;TYPE=WORK,PREF:+1-617-693-8728 - TEL;TYPE=WORK,MSG:+1-919-676-9515 - TEL;TYPE=FAX:+1-617-693-8728 - EMAIL;TYPE=INTERNET,PREF:Frank_Dawson@Lotus.com - EMAIL;TYPE=INTERNET:fdawson@earthlink.net - CALADRURI;TYPE=PREF:MAILTO:Frank_Dawson@Lotus.com - CALADRURI:MAILTO:fdawson@earthlink.net - URL:http://home.earthlink.net/~fdawson - END:VCARD - - This memo is a result of the work of the Internet Engineering Task - Force Calendaring and scheduling Working Group. The chairman of that - working group is: - - BEGIN:VCARD - VERSION:3.0 - N:Egen;Pat - FN:Pat Egen - ORG:Engan Consulting - ADR;TYPE=WORK:;;803 Creek Overlook;Chattanooga;TN;37415;USA - TEL;TYPE=WORK,VOICE:423.875.2652 - TEL;TYPE=WORK,FAX:423.875.2017 - EMAIL:pregen@egenconsulting.com - URL:http://www.egenconsulting.com - CALADRURI:MAILTO:pregen@egenconsulting.com - END:VCARD - - - - - - - - - - - - - - - - - - -Small, et al. Standards Track [Page 14] - -RFC 2739 Locating a Calendar User January 2000 - - -7 Bibliography - - [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [2] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight - Directory Access Protocol (v3): Attribute Syntax Definitions", - RFC 2252, December 1997. - - [3] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC - 2426, September 1998. - - [4] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling - Core Object Specification (iCalendar)", RFC 2445, November 1997. - - [5] Dawson, F. and S. Mansour, "iCalendar Message-Based - Interopability Protocal (iMIP)", RFC 2447, November 1997. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Small, et al. Standards Track [Page 15] - -RFC 2739 Locating a Calendar User January 2000 - - -8 Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Small, et al. Standards Track [Page 16] - diff --git a/etc/rfc3261.txt b/etc/rfc3261.txt deleted file mode 100644 index 00456a9..0000000 --- a/etc/rfc3261.txt +++ /dev/null @@ -1,15067 +0,0 @@ - - - - - - -Network Working Group J. Rosenberg -Request for Comments: 3261 dynamicsoft -Obsoletes: 2543 H. Schulzrinne -Category: Standards Track Columbia U. - G. Camarillo - Ericsson - A. Johnston - WorldCom - J. Peterson - Neustar - R. Sparks - dynamicsoft - M. Handley - ICIR - E. Schooler - AT&T - June 2002 - - SIP: Session Initiation Protocol - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2002). All Rights Reserved. - -Abstract - - This document describes Session Initiation Protocol (SIP), an - application-layer control (signaling) protocol for creating, - modifying, and terminating sessions with one or more participants. - These sessions include Internet telephone calls, multimedia - distribution, and multimedia conferences. - - SIP invitations used to create sessions carry session descriptions - that allow participants to agree on a set of compatible media types. - SIP makes use of elements called proxy servers to help route requests - to the user's current location, authenticate and authorize users for - services, implement provider call-routing policies, and provide - features to users. SIP also provides a registration function that - allows users to upload their current locations for use by proxy - servers. SIP runs on top of several different transport protocols. - - - -Rosenberg, et. al. Standards Track [Page 1] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -Table of Contents - - 1 Introduction ........................................ 8 - 2 Overview of SIP Functionality ....................... 9 - 3 Terminology ......................................... 10 - 4 Overview of Operation ............................... 10 - 5 Structure of the Protocol ........................... 18 - 6 Definitions ......................................... 20 - 7 SIP Messages ........................................ 26 - 7.1 Requests ............................................ 27 - 7.2 Responses ........................................... 28 - 7.3 Header Fields ....................................... 29 - 7.3.1 Header Field Format ................................. 30 - 7.3.2 Header Field Classification ......................... 32 - 7.3.3 Compact Form ........................................ 32 - 7.4 Bodies .............................................. 33 - 7.4.1 Message Body Type ................................... 33 - 7.4.2 Message Body Length ................................. 33 - 7.5 Framing SIP Messages ................................ 34 - 8 General User Agent Behavior ......................... 34 - 8.1 UAC Behavior ........................................ 35 - 8.1.1 Generating the Request .............................. 35 - 8.1.1.1 Request-URI ......................................... 35 - 8.1.1.2 To .................................................. 36 - 8.1.1.3 From ................................................ 37 - 8.1.1.4 Call-ID ............................................. 37 - 8.1.1.5 CSeq ................................................ 38 - 8.1.1.6 Max-Forwards ........................................ 38 - 8.1.1.7 Via ................................................. 39 - 8.1.1.8 Contact ............................................. 40 - 8.1.1.9 Supported and Require ............................... 40 - 8.1.1.10 Additional Message Components ....................... 41 - 8.1.2 Sending the Request ................................. 41 - 8.1.3 Processing Responses ................................ 42 - 8.1.3.1 Transaction Layer Errors ............................ 42 - 8.1.3.2 Unrecognized Responses .............................. 42 - 8.1.3.3 Vias ................................................ 43 - 8.1.3.4 Processing 3xx Responses ............................ 43 - 8.1.3.5 Processing 4xx Responses ............................ 45 - 8.2 UAS Behavior ........................................ 46 - 8.2.1 Method Inspection ................................... 46 - 8.2.2 Header Inspection ................................... 46 - 8.2.2.1 To and Request-URI .................................. 46 - 8.2.2.2 Merged Requests ..................................... 47 - 8.2.2.3 Require ............................................. 47 - 8.2.3 Content Processing .................................. 48 - 8.2.4 Applying Extensions ................................. 49 - 8.2.5 Processing the Request .............................. 49 - - - -Rosenberg, et. al. Standards Track [Page 2] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - 8.2.6 Generating the Response ............................. 49 - 8.2.6.1 Sending a Provisional Response ...................... 49 - 8.2.6.2 Headers and Tags .................................... 50 - 8.2.7 Stateless UAS Behavior .............................. 50 - 8.3 Redirect Servers .................................... 51 - 9 Canceling a Request ................................. 53 - 9.1 Client Behavior ..................................... 53 - 9.2 Server Behavior ..................................... 55 - 10 Registrations ....................................... 56 - 10.1 Overview ............................................ 56 - 10.2 Constructing the REGISTER Request ................... 57 - 10.2.1 Adding Bindings ..................................... 59 - 10.2.1.1 Setting the Expiration Interval of Contact Addresses 60 - 10.2.1.2 Preferences among Contact Addresses ................. 61 - 10.2.2 Removing Bindings ................................... 61 - 10.2.3 Fetching Bindings ................................... 61 - 10.2.4 Refreshing Bindings ................................. 61 - 10.2.5 Setting the Internal Clock .......................... 62 - 10.2.6 Discovering a Registrar ............................. 62 - 10.2.7 Transmitting a Request .............................. 62 - 10.2.8 Error Responses ..................................... 63 - 10.3 Processing REGISTER Requests ........................ 63 - 11 Querying for Capabilities ........................... 66 - 11.1 Construction of OPTIONS Request ..................... 67 - 11.2 Processing of OPTIONS Request ....................... 68 - 12 Dialogs ............................................. 69 - 12.1 Creation of a Dialog ................................ 70 - 12.1.1 UAS behavior ........................................ 70 - 12.1.2 UAC Behavior ........................................ 71 - 12.2 Requests within a Dialog ............................ 72 - 12.2.1 UAC Behavior ........................................ 73 - 12.2.1.1 Generating the Request .............................. 73 - 12.2.1.2 Processing the Responses ............................ 75 - 12.2.2 UAS Behavior ........................................ 76 - 12.3 Termination of a Dialog ............................. 77 - 13 Initiating a Session ................................ 77 - 13.1 Overview ............................................ 77 - 13.2 UAC Processing ...................................... 78 - 13.2.1 Creating the Initial INVITE ......................... 78 - 13.2.2 Processing INVITE Responses ......................... 81 - 13.2.2.1 1xx Responses ....................................... 81 - 13.2.2.2 3xx Responses ....................................... 81 - 13.2.2.3 4xx, 5xx and 6xx Responses .......................... 81 - 13.2.2.4 2xx Responses ....................................... 82 - 13.3 UAS Processing ...................................... 83 - 13.3.1 Processing of the INVITE ............................ 83 - 13.3.1.1 Progress ............................................ 84 - 13.3.1.2 The INVITE is Redirected ............................ 84 - - - -Rosenberg, et. al. Standards Track [Page 3] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - 13.3.1.3 The INVITE is Rejected .............................. 85 - 13.3.1.4 The INVITE is Accepted .............................. 85 - 14 Modifying an Existing Session ....................... 86 - 14.1 UAC Behavior ........................................ 86 - 14.2 UAS Behavior ........................................ 88 - 15 Terminating a Session ............................... 89 - 15.1 Terminating a Session with a BYE Request ............ 90 - 15.1.1 UAC Behavior ........................................ 90 - 15.1.2 UAS Behavior ........................................ 91 - 16 Proxy Behavior ...................................... 91 - 16.1 Overview ............................................ 91 - 16.2 Stateful Proxy ...................................... 92 - 16.3 Request Validation .................................. 94 - 16.4 Route Information Preprocessing ..................... 96 - 16.5 Determining Request Targets ......................... 97 - 16.6 Request Forwarding .................................. 99 - 16.7 Response Processing ................................. 107 - 16.8 Processing Timer C .................................. 114 - 16.9 Handling Transport Errors ........................... 115 - 16.10 CANCEL Processing ................................... 115 - 16.11 Stateless Proxy ..................................... 116 - 16.12 Summary of Proxy Route Processing ................... 118 - 16.12.1 Examples ............................................ 118 - 16.12.1.1 Basic SIP Trapezoid ................................. 118 - 16.12.1.2 Traversing a Strict-Routing Proxy ................... 120 - 16.12.1.3 Rewriting Record-Route Header Field Values .......... 121 - 17 Transactions ........................................ 122 - 17.1 Client Transaction .................................. 124 - 17.1.1 INVITE Client Transaction ........................... 125 - 17.1.1.1 Overview of INVITE Transaction ...................... 125 - 17.1.1.2 Formal Description .................................. 125 - 17.1.1.3 Construction of the ACK Request ..................... 129 - 17.1.2 Non-INVITE Client Transaction ....................... 130 - 17.1.2.1 Overview of the non-INVITE Transaction .............. 130 - 17.1.2.2 Formal Description .................................. 131 - 17.1.3 Matching Responses to Client Transactions ........... 132 - 17.1.4 Handling Transport Errors ........................... 133 - 17.2 Server Transaction .................................. 134 - 17.2.1 INVITE Server Transaction ........................... 134 - 17.2.2 Non-INVITE Server Transaction ....................... 137 - 17.2.3 Matching Requests to Server Transactions ............ 138 - 17.2.4 Handling Transport Errors ........................... 141 - 18 Transport ........................................... 141 - 18.1 Clients ............................................. 142 - 18.1.1 Sending Requests .................................... 142 - 18.1.2 Receiving Responses ................................. 144 - 18.2 Servers ............................................. 145 - 18.2.1 Receiving Requests .................................. 145 - - - -Rosenberg, et. al. Standards Track [Page 4] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - 18.2.2 Sending Responses ................................... 146 - 18.3 Framing ............................................. 147 - 18.4 Error Handling ...................................... 147 - 19 Common Message Components ........................... 147 - 19.1 SIP and SIPS Uniform Resource Indicators ............ 148 - 19.1.1 SIP and SIPS URI Components ......................... 148 - 19.1.2 Character Escaping Requirements ..................... 152 - 19.1.3 Example SIP and SIPS URIs ........................... 153 - 19.1.4 URI Comparison ...................................... 153 - 19.1.5 Forming Requests from a URI ......................... 156 - 19.1.6 Relating SIP URIs and tel URLs ...................... 157 - 19.2 Option Tags ......................................... 158 - 19.3 Tags ................................................ 159 - 20 Header Fields ....................................... 159 - 20.1 Accept .............................................. 161 - 20.2 Accept-Encoding ..................................... 163 - 20.3 Accept-Language ..................................... 164 - 20.4 Alert-Info .......................................... 164 - 20.5 Allow ............................................... 165 - 20.6 Authentication-Info ................................. 165 - 20.7 Authorization ....................................... 165 - 20.8 Call-ID ............................................. 166 - 20.9 Call-Info ........................................... 166 - 20.10 Contact ............................................. 167 - 20.11 Content-Disposition ................................. 168 - 20.12 Content-Encoding .................................... 169 - 20.13 Content-Language .................................... 169 - 20.14 Content-Length ...................................... 169 - 20.15 Content-Type ........................................ 170 - 20.16 CSeq ................................................ 170 - 20.17 Date ................................................ 170 - 20.18 Error-Info .......................................... 171 - 20.19 Expires ............................................. 171 - 20.20 From ................................................ 172 - 20.21 In-Reply-To ......................................... 172 - 20.22 Max-Forwards ........................................ 173 - 20.23 Min-Expires ......................................... 173 - 20.24 MIME-Version ........................................ 173 - 20.25 Organization ........................................ 174 - 20.26 Priority ............................................ 174 - 20.27 Proxy-Authenticate .................................. 174 - 20.28 Proxy-Authorization ................................. 175 - 20.29 Proxy-Require ....................................... 175 - 20.30 Record-Route ........................................ 175 - 20.31 Reply-To ............................................ 176 - 20.32 Require ............................................. 176 - 20.33 Retry-After ......................................... 176 - 20.34 Route ............................................... 177 - - - -Rosenberg, et. al. Standards Track [Page 5] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - 20.35 Server .............................................. 177 - 20.36 Subject ............................................. 177 - 20.37 Supported ........................................... 178 - 20.38 Timestamp ........................................... 178 - 20.39 To .................................................. 178 - 20.40 Unsupported ......................................... 179 - 20.41 User-Agent .......................................... 179 - 20.42 Via ................................................. 179 - 20.43 Warning ............................................. 180 - 20.44 WWW-Authenticate .................................... 182 - 21 Response Codes ...................................... 182 - 21.1 Provisional 1xx ..................................... 182 - 21.1.1 100 Trying .......................................... 183 - 21.1.2 180 Ringing ......................................... 183 - 21.1.3 181 Call Is Being Forwarded ......................... 183 - 21.1.4 182 Queued .......................................... 183 - 21.1.5 183 Session Progress ................................ 183 - 21.2 Successful 2xx ...................................... 183 - 21.2.1 200 OK .............................................. 183 - 21.3 Redirection 3xx ..................................... 184 - 21.3.1 300 Multiple Choices ................................ 184 - 21.3.2 301 Moved Permanently ............................... 184 - 21.3.3 302 Moved Temporarily ............................... 184 - 21.3.4 305 Use Proxy ....................................... 185 - 21.3.5 380 Alternative Service ............................. 185 - 21.4 Request Failure 4xx ................................. 185 - 21.4.1 400 Bad Request ..................................... 185 - 21.4.2 401 Unauthorized .................................... 185 - 21.4.3 402 Payment Required ................................ 186 - 21.4.4 403 Forbidden ....................................... 186 - 21.4.5 404 Not Found ....................................... 186 - 21.4.6 405 Method Not Allowed .............................. 186 - 21.4.7 406 Not Acceptable .................................. 186 - 21.4.8 407 Proxy Authentication Required ................... 186 - 21.4.9 408 Request Timeout ................................. 186 - 21.4.10 410 Gone ............................................ 187 - 21.4.11 413 Request Entity Too Large ........................ 187 - 21.4.12 414 Request-URI Too Long ............................ 187 - 21.4.13 415 Unsupported Media Type .......................... 187 - 21.4.14 416 Unsupported URI Scheme .......................... 187 - 21.4.15 420 Bad Extension ................................... 187 - 21.4.16 421 Extension Required .............................. 188 - 21.4.17 423 Interval Too Brief .............................. 188 - 21.4.18 480 Temporarily Unavailable ......................... 188 - 21.4.19 481 Call/Transaction Does Not Exist ................. 188 - 21.4.20 482 Loop Detected ................................... 188 - 21.4.21 483 Too Many Hops ................................... 189 - 21.4.22 484 Address Incomplete .............................. 189 - - - -Rosenberg, et. al. Standards Track [Page 6] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - 21.4.23 485 Ambiguous ....................................... 189 - 21.4.24 486 Busy Here ....................................... 189 - 21.4.25 487 Request Terminated .............................. 190 - 21.4.26 488 Not Acceptable Here ............................. 190 - 21.4.27 491 Request Pending ................................. 190 - 21.4.28 493 Undecipherable .................................. 190 - 21.5 Server Failure 5xx .................................. 190 - 21.5.1 500 Server Internal Error ........................... 190 - 21.5.2 501 Not Implemented ................................. 191 - 21.5.3 502 Bad Gateway ..................................... 191 - 21.5.4 503 Service Unavailable ............................. 191 - 21.5.5 504 Server Time-out ................................. 191 - 21.5.6 505 Version Not Supported ........................... 192 - 21.5.7 513 Message Too Large ............................... 192 - 21.6 Global Failures 6xx ................................. 192 - 21.6.1 600 Busy Everywhere ................................. 192 - 21.6.2 603 Decline ......................................... 192 - 21.6.3 604 Does Not Exist Anywhere ......................... 192 - 21.6.4 606 Not Acceptable .................................. 192 - 22 Usage of HTTP Authentication ........................ 193 - 22.1 Framework ........................................... 193 - 22.2 User-to-User Authentication ......................... 195 - 22.3 Proxy-to-User Authentication ........................ 197 - 22.4 The Digest Authentication Scheme .................... 199 - 23 S/MIME .............................................. 201 - 23.1 S/MIME Certificates ................................. 201 - 23.2 S/MIME Key Exchange ................................. 202 - 23.3 Securing MIME bodies ................................ 205 - 23.4 SIP Header Privacy and Integrity using S/MIME: - Tunneling SIP ....................................... 207 - 23.4.1 Integrity and Confidentiality Properties of SIP - Headers ............................................. 207 - 23.4.1.1 Integrity ........................................... 207 - 23.4.1.2 Confidentiality ..................................... 208 - 23.4.2 Tunneling Integrity and Authentication .............. 209 - 23.4.3 Tunneling Encryption ................................ 211 - 24 Examples ............................................ 213 - 24.1 Registration ........................................ 213 - 24.2 Session Setup ....................................... 214 - 25 Augmented BNF for the SIP Protocol .................. 219 - 25.1 Basic Rules ......................................... 219 - 26 Security Considerations: Threat Model and Security - Usage Recommendations ............................... 232 - 26.1 Attacks and Threat Models ........................... 233 - 26.1.1 Registration Hijacking .............................. 233 - 26.1.2 Impersonating a Server .............................. 234 - 26.1.3 Tampering with Message Bodies ....................... 235 - 26.1.4 Tearing Down Sessions ............................... 235 - - - -Rosenberg, et. al. Standards Track [Page 7] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - 26.1.5 Denial of Service and Amplification ................. 236 - 26.2 Security Mechanisms ................................. 237 - 26.2.1 Transport and Network Layer Security ................ 238 - 26.2.2 SIPS URI Scheme ..................................... 239 - 26.2.3 HTTP Authentication ................................. 240 - 26.2.4 S/MIME .............................................. 240 - 26.3 Implementing Security Mechanisms .................... 241 - 26.3.1 Requirements for Implementers of SIP ................ 241 - 26.3.2 Security Solutions .................................. 242 - 26.3.2.1 Registration ........................................ 242 - 26.3.2.2 Interdomain Requests ................................ 243 - 26.3.2.3 Peer-to-Peer Requests ............................... 245 - 26.3.2.4 DoS Protection ...................................... 246 - 26.4 Limitations ......................................... 247 - 26.4.1 HTTP Digest ......................................... 247 - 26.4.2 S/MIME .............................................. 248 - 26.4.3 TLS ................................................. 249 - 26.4.4 SIPS URIs ........................................... 249 - 26.5 Privacy ............................................. 251 - 27 IANA Considerations ................................. 252 - 27.1 Option Tags ......................................... 252 - 27.2 Warn-Codes .......................................... 252 - 27.3 Header Field Names .................................. 253 - 27.4 Method and Response Codes ........................... 253 - 27.5 The "message/sip" MIME type. ....................... 254 - 27.6 New Content-Disposition Parameter Registrations ..... 255 - 28 Changes From RFC 2543 ............................... 255 - 28.1 Major Functional Changes ............................ 255 - 28.2 Minor Functional Changes ............................ 260 - 29 Normative References ................................ 261 - 30 Informative References .............................. 262 - A Table of Timer Values ............................... 265 - Acknowledgments ................................................ 266 - Authors' Addresses ............................................. 267 - Full Copyright Statement ....................................... 269 - -1 Introduction - - There are many applications of the Internet that require the creation - and management of a session, where a session is considered an - exchange of data between an association of participants. The - implementation of these applications is complicated by the practices - of participants: users may move between endpoints, they may be - addressable by multiple names, and they may communicate in several - different media - sometimes simultaneously. Numerous protocols have - been authored that carry various forms of real-time multimedia - session data such as voice, video, or text messages. The Session - Initiation Protocol (SIP) works in concert with these protocols by - - - -Rosenberg, et. al. Standards Track [Page 8] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - enabling Internet endpoints (called user agents) to discover one - another and to agree on a characterization of a session they would - like to share. For locating prospective session participants, and - for other functions, SIP enables the creation of an infrastructure of - network hosts (called proxy servers) to which user agents can send - registrations, invitations to sessions, and other requests. SIP is - an agile, general-purpose tool for creating, modifying, and - terminating sessions that works independently of underlying transport - protocols and without dependency on the type of session that is being - established. - -2 Overview of SIP Functionality - - SIP is an application-layer control protocol that can establish, - modify, and terminate multimedia sessions (conferences) such as - Internet telephony calls. SIP can also invite participants to - already existing sessions, such as multicast conferences. Media can - be added to (and removed from) an existing session. SIP - transparently supports name mapping and redirection services, which - supports personal mobility [27] - users can maintain a single - externally visible identifier regardless of their network location. - - SIP supports five facets of establishing and terminating multimedia - communications: - - User location: determination of the end system to be used for - communication; - - User availability: determination of the willingness of the called - party to engage in communications; - - User capabilities: determination of the media and media parameters - to be used; - - Session setup: "ringing", establishment of session parameters at - both called and calling party; - - Session management: including transfer and termination of - sessions, modifying session parameters, and invoking - services. - - SIP is not a vertically integrated communications system. SIP is - rather a component that can be used with other IETF protocols to - build a complete multimedia architecture. Typically, these - architectures will include protocols such as the Real-time Transport - Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and - providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC - 2326 [29]) for controlling delivery of streaming media, the Media - - - -Rosenberg, et. al. Standards Track [Page 9] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling - gateways to the Public Switched Telephone Network (PSTN), and the - Session Description Protocol (SDP) (RFC 2327 [1]) for describing - multimedia sessions. Therefore, SIP should be used in conjunction - with other protocols in order to provide complete services to the - users. However, the basic functionality and operation of SIP does - not depend on any of these protocols. - - SIP does not provide services. Rather, SIP provides primitives that - can be used to implement different services. For example, SIP can - locate a user and deliver an opaque object to his current location. - If this primitive is used to deliver a session description written in - SDP, for instance, the endpoints can agree on the parameters of a - session. If the same primitive is used to deliver a photo of the - caller as well as the session description, a "caller ID" service can - be easily implemented. As this example shows, a single primitive is - typically used to provide several different services. - - SIP does not offer conference control services such as floor control - or voting and does not prescribe how a conference is to be managed. - SIP can be used to initiate a session that uses some other conference - control protocol. Since SIP messages and the sessions they establish - can pass through entirely different networks, SIP cannot, and does - not, provide any kind of network resource reservation capabilities. - - The nature of the services provided make security particularly - important. To that end, SIP provides a suite of security services, - which include denial-of-service prevention, authentication (both user - to user and proxy to user), integrity protection, and encryption and - privacy services. - - SIP works with both IPv4 and IPv6. - -3 Terminology - - In this document, the key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT - RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as - described in BCP 14, RFC 2119 [2] and indicate requirement levels for - compliant SIP implementations. - -4 Overview of Operation - - This section introduces the basic operations of SIP using simple - examples. This section is tutorial in nature and does not contain - any normative statements. - - - - - -Rosenberg, et. al. Standards Track [Page 10] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The first example shows the basic functions of SIP: location of an - end point, signal of a desire to communicate, negotiation of session - parameters to establish the session, and teardown of the session once - established. - - Figure 1 shows a typical example of a SIP message exchange between - two users, Alice and Bob. (Each message is labeled with the letter - "F" and a number for reference by the text.) In this example, Alice - uses a SIP application on her PC (referred to as a softphone) to call - Bob on his SIP phone over the Internet. Also shown are two SIP proxy - servers that act on behalf of Alice and Bob to facilitate the session - establishment. This typical arrangement is often referred to as the - "SIP trapezoid" as shown by the geometric shape of the dotted lines - in Figure 1. - - Alice "calls" Bob using his SIP identity, a type of Uniform Resource - Identifier (URI) called a SIP URI. SIP URIs are defined in Section - 19.1. It has a similar form to an email address, typically - containing a username and a host name. In this case, it is - sip:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP - service provider. Alice has a SIP URI of sip:alice@atlanta.com. - Alice might have typed in Bob's URI or perhaps clicked on a hyperlink - or an entry in an address book. SIP also provides a secure URI, - called a SIPS URI. An example would be sips:bob@biloxi.com. A call - made to a SIPS URI guarantees that secure, encrypted transport - (namely TLS) is used to carry all SIP messages from the caller to the - domain of the callee. From there, the request is sent securely to - the callee, but with security mechanisms that depend on the policy of - the domain of the callee. - - SIP is based on an HTTP-like request/response transaction model. - Each transaction consists of a request that invokes a particular - method, or function, on the server and at least one response. In - this example, the transaction begins with Alice's softphone sending - an INVITE request addressed to Bob's SIP URI. INVITE is an example - of a SIP method that specifies the action that the requestor (Alice) - wants the server (Bob) to take. The INVITE request contains a number - of header fields. Header fields are named attributes that provide - additional information about a message. The ones present in an - INVITE include a unique identifier for the call, the destination - address, Alice's address, and information about the type of session - that Alice wishes to establish with Bob. The INVITE (message F1 in - Figure 1) might look like this: - - - - - - - - -Rosenberg, et. al. Standards Track [Page 11] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - atlanta.com . . . biloxi.com - . proxy proxy . - . . - Alice's . . . . . . . . . . . . . . . . . . . . Bob's - softphone SIP Phone - | | | | - | INVITE F1 | | | - |--------------->| INVITE F2 | | - | 100 Trying F3 |--------------->| INVITE F4 | - |<---------------| 100 Trying F5 |--------------->| - | |<-------------- | 180 Ringing F6 | - | | 180 Ringing F7 |<---------------| - | 180 Ringing F8 |<---------------| 200 OK F9 | - |<---------------| 200 OK F10 |<---------------| - | 200 OK F11 |<---------------| | - |<---------------| | | - | ACK F12 | - |------------------------------------------------->| - | Media Session | - |<================================================>| - | BYE F13 | - |<-------------------------------------------------| - | 200 OK F14 | - |------------------------------------------------->| - | | - - Figure 1: SIP session setup example with SIP trapezoid - - INVITE sip:bob@biloxi.com SIP/2.0 - Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds - Max-Forwards: 70 - To: Bob - From: Alice ;tag=1928301774 - Call-ID: a84b4c76e66710@pc33.atlanta.com - CSeq: 314159 INVITE - Contact: - Content-Type: application/sdp - Content-Length: 142 - - (Alice's SDP not shown) - - The first line of the text-encoded message contains the method name - (INVITE). The lines that follow are a list of header fields. This - example contains a minimum required set. The header fields are - briefly described below: - - - - - - -Rosenberg, et. al. Standards Track [Page 12] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Via contains the address (pc33.atlanta.com) at which Alice is - expecting to receive responses to this request. It also contains a - branch parameter that identifies this transaction. - - To contains a display name (Bob) and a SIP or SIPS URI - (sip:bob@biloxi.com) towards which the request was originally - directed. Display names are described in RFC 2822 [3]. - - From also contains a display name (Alice) and a SIP or SIPS URI - (sip:alice@atlanta.com) that indicate the originator of the request. - This header field also has a tag parameter containing a random string - (1928301774) that was added to the URI by the softphone. It is used - for identification purposes. - - Call-ID contains a globally unique identifier for this call, - generated by the combination of a random string and the softphone's - host name or IP address. The combination of the To tag, From tag, - and Call-ID completely defines a peer-to-peer SIP relationship - between Alice and Bob and is referred to as a dialog. - - CSeq or Command Sequence contains an integer and a method name. The - CSeq number is incremented for each new request within a dialog and - is a traditional sequence number. - - Contact contains a SIP or SIPS URI that represents a direct route to - contact Alice, usually composed of a username at a fully qualified - domain name (FQDN). While an FQDN is preferred, many end systems do - not have registered domain names, so IP addresses are permitted. - While the Via header field tells other elements where to send the - response, the Contact header field tells other elements where to send - future requests. - - Max-Forwards serves to limit the number of hops a request can make on - the way to its destination. It consists of an integer that is - decremented by one at each hop. - - Content-Type contains a description of the message body (not shown). - - Content-Length contains an octet (byte) count of the message body. - - The complete set of SIP header fields is defined in Section 20. - - The details of the session, such as the type of media, codec, or - sampling rate, are not described using SIP. Rather, the body of a - SIP message contains a description of the session, encoded in some - other protocol format. One such format is the Session Description - Protocol (SDP) (RFC 2327 [1]). This SDP message (not shown in the - - - - -Rosenberg, et. al. Standards Track [Page 13] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - example) is carried by the SIP message in a way that is analogous to - a document attachment being carried by an email message, or a web - page being carried in an HTTP message. - - Since the softphone does not know the location of Bob or the SIP - server in the biloxi.com domain, the softphone sends the INVITE to - the SIP server that serves Alice's domain, atlanta.com. The address - of the atlanta.com SIP server could have been configured in Alice's - softphone, or it could have been discovered by DHCP, for example. - - The atlanta.com SIP server is a type of SIP server known as a proxy - server. A proxy server receives SIP requests and forwards them on - behalf of the requestor. In this example, the proxy server receives - the INVITE request and sends a 100 (Trying) response back to Alice's - softphone. The 100 (Trying) response indicates that the INVITE has - been received and that the proxy is working on her behalf to route - the INVITE to the destination. Responses in SIP use a three-digit - code followed by a descriptive phrase. This response contains the - same To, From, Call-ID, CSeq and branch parameter in the Via as the - INVITE, which allows Alice's softphone to correlate this response to - the sent INVITE. The atlanta.com proxy server locates the proxy - server at biloxi.com, possibly by performing a particular type of DNS - (Domain Name Service) lookup to find the SIP server that serves the - biloxi.com domain. This is described in [4]. As a result, it - obtains the IP address of the biloxi.com proxy server and forwards, - or proxies, the INVITE request there. Before forwarding the request, - the atlanta.com proxy server adds an additional Via header field - value that contains its own address (the INVITE already contains - Alice's address in the first Via). The biloxi.com proxy server - receives the INVITE and responds with a 100 (Trying) response back to - the atlanta.com proxy server to indicate that it has received the - INVITE and is processing the request. The proxy server consults a - database, generically called a location service, that contains the - current IP address of Bob. (We shall see in the next section how - this database can be populated.) The biloxi.com proxy server adds - another Via header field value with its own address to the INVITE and - proxies it to Bob's SIP phone. - - Bob's SIP phone receives the INVITE and alerts Bob to the incoming - call from Alice so that Bob can decide whether to answer the call, - that is, Bob's phone rings. Bob's SIP phone indicates this in a 180 - (Ringing) response, which is routed back through the two proxies in - the reverse direction. Each proxy uses the Via header field to - determine where to send the response and removes its own address from - the top. As a result, although DNS and location service lookups were - required to route the initial INVITE, the 180 (Ringing) response can - be returned to the caller without lookups or without state being - - - - -Rosenberg, et. al. Standards Track [Page 14] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - maintained in the proxies. This also has the desirable property that - each proxy that sees the INVITE will also see all responses to the - INVITE. - - When Alice's softphone receives the 180 (Ringing) response, it passes - this information to Alice, perhaps using an audio ringback tone or by - displaying a message on Alice's screen. - - In this example, Bob decides to answer the call. When he picks up - the handset, his SIP phone sends a 200 (OK) response to indicate that - the call has been answered. The 200 (OK) contains a message body - with the SDP media description of the type of session that Bob is - willing to establish with Alice. As a result, there is a two-phase - exchange of SDP messages: Alice sent one to Bob, and Bob sent one - back to Alice. This two-phase exchange provides basic negotiation - capabilities and is based on a simple offer/answer model of SDP - exchange. If Bob did not wish to answer the call or was busy on - another call, an error response would have been sent instead of the - 200 (OK), which would have resulted in no media session being - established. The complete list of SIP response codes is in Section - 21. The 200 (OK) (message F9 in Figure 1) might look like this as - Bob sends it out: - - SIP/2.0 200 OK - Via: SIP/2.0/UDP server10.biloxi.com - ;branch=z9hG4bKnashds8;received=192.0.2.3 - Via: SIP/2.0/UDP bigbox3.site3.atlanta.com - ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 - Via: SIP/2.0/UDP pc33.atlanta.com - ;branch=z9hG4bK776asdhds ;received=192.0.2.1 - To: Bob ;tag=a6c85cf - From: Alice ;tag=1928301774 - Call-ID: a84b4c76e66710@pc33.atlanta.com - CSeq: 314159 INVITE - Contact: - Content-Type: application/sdp - Content-Length: 131 - - (Bob's SDP not shown) - - The first line of the response contains the response code (200) and - the reason phrase (OK). The remaining lines contain header fields. - The Via, To, From, Call-ID, and CSeq header fields are copied from - the INVITE request. (There are three Via header field values - one - added by Alice's SIP phone, one added by the atlanta.com proxy, and - one added by the biloxi.com proxy.) Bob's SIP phone has added a tag - parameter to the To header field. This tag will be incorporated by - both endpoints into the dialog and will be included in all future - - - -Rosenberg, et. al. Standards Track [Page 15] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - requests and responses in this call. The Contact header field - contains a URI at which Bob can be directly reached at his SIP phone. - The Content-Type and Content-Length refer to the message body (not - shown) that contains Bob's SDP media information. - - In addition to DNS and location service lookups shown in this - example, proxy servers can make flexible "routing decisions" to - decide where to send a request. For example, if Bob's SIP phone - returned a 486 (Busy Here) response, the biloxi.com proxy server - could proxy the INVITE to Bob's voicemail server. A proxy server can - also send an INVITE to a number of locations at the same time. This - type of parallel search is known as forking. - - In this case, the 200 (OK) is routed back through the two proxies and - is received by Alice's softphone, which then stops the ringback tone - and indicates that the call has been answered. Finally, Alice's - softphone sends an acknowledgement message, ACK, to Bob's SIP phone - to confirm the reception of the final response (200 (OK)). In this - example, the ACK is sent directly from Alice's softphone to Bob's SIP - phone, bypassing the two proxies. This occurs because the endpoints - have learned each other's address from the Contact header fields - through the INVITE/200 (OK) exchange, which was not known when the - initial INVITE was sent. The lookups performed by the two proxies - are no longer needed, so the proxies drop out of the call flow. This - completes the INVITE/200/ACK three-way handshake used to establish - SIP sessions. Full details on session setup are in Section 13. - - Alice and Bob's media session has now begun, and they send media - packets using the format to which they agreed in the exchange of SDP. - In general, the end-to-end media packets take a different path from - the SIP signaling messages. - - During the session, either Alice or Bob may decide to change the - characteristics of the media session. This is accomplished by - sending a re-INVITE containing a new media description. This re- - INVITE references the existing dialog so that the other party knows - that it is to modify an existing session instead of establishing a - new session. The other party sends a 200 (OK) to accept the change. - The requestor responds to the 200 (OK) with an ACK. If the other - party does not accept the change, he sends an error response such as - 488 (Not Acceptable Here), which also receives an ACK. However, the - failure of the re-INVITE does not cause the existing call to fail - - the session continues using the previously negotiated - characteristics. Full details on session modification are in Section - 14. - - - - - - -Rosenberg, et. al. Standards Track [Page 16] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - At the end of the call, Bob disconnects (hangs up) first and - generates a BYE message. This BYE is routed directly to Alice's - softphone, again bypassing the proxies. Alice confirms receipt of - the BYE with a 200 (OK) response, which terminates the session and - the BYE transaction. No ACK is sent - an ACK is only sent in - response to a response to an INVITE request. The reasons for this - special handling for INVITE will be discussed later, but relate to - the reliability mechanisms in SIP, the length of time it can take for - a ringing phone to be answered, and forking. For this reason, - request handling in SIP is often classified as either INVITE or non- - INVITE, referring to all other methods besides INVITE. Full details - on session termination are in Section 15. - - Section 24.2 describes the messages shown in Figure 1 in full. - - In some cases, it may be useful for proxies in the SIP signaling path - to see all the messaging between the endpoints for the duration of - the session. For example, if the biloxi.com proxy server wished to - remain in the SIP messaging path beyond the initial INVITE, it would - add to the INVITE a required routing header field known as Record- - Route that contained a URI resolving to the hostname or IP address of - the proxy. This information would be received by both Bob's SIP - phone and (due to the Record-Route header field being passed back in - the 200 (OK)) Alice's softphone and stored for the duration of the - dialog. The biloxi.com proxy server would then receive and proxy the - ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently - decide to receive subsequent messages, and those messages will pass - through all proxies that elect to receive it. This capability is - frequently used for proxies that are providing mid-call features. - - Registration is another common operation in SIP. Registration is one - way that the biloxi.com server can learn the current location of Bob. - Upon initialization, and at periodic intervals, Bob's SIP phone sends - REGISTER messages to a server in the biloxi.com domain known as a SIP - registrar. The REGISTER messages associate Bob's SIP or SIPS URI - (sip:bob@biloxi.com) with the machine into which he is currently - logged (conveyed as a SIP or SIPS URI in the Contact header field). - The registrar writes this association, also called a binding, to a - database, called the location service, where it can be used by the - proxy in the biloxi.com domain. Often, a registrar server for a - domain is co-located with the proxy for that domain. It is an - important concept that the distinction between types of SIP servers - is logical, not physical. - - Bob is not limited to registering from a single device. For example, - both his SIP phone at home and the one in the office could send - registrations. This information is stored together in the location - - - - -Rosenberg, et. al. Standards Track [Page 17] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - service and allows a proxy to perform various types of searches to - locate Bob. Similarly, more than one user can be registered on a - single device at the same time. - - The location service is just an abstract concept. It generally - contains information that allows a proxy to input a URI and receive a - set of zero or more URIs that tell the proxy where to send the - request. Registrations are one way to create this information, but - not the only way. Arbitrary mapping functions can be configured at - the discretion of the administrator. - - Finally, it is important to note that in SIP, registration is used - for routing incoming SIP requests and has no role in authorizing - outgoing requests. Authorization and authentication are handled in - SIP either on a request-by-request basis with a challenge/response - mechanism, or by using a lower layer scheme as discussed in Section - 26. - - The complete set of SIP message details for this registration example - is in Section 24.1. - - Additional operations in SIP, such as querying for the capabilities - of a SIP server or client using OPTIONS, or canceling a pending - request using CANCEL, will be introduced in later sections. - -5 Structure of the Protocol - - SIP is structured as a layered protocol, which means that its - behavior is described in terms of a set of fairly independent - processing stages with only a loose coupling between each stage. The - protocol behavior is described as layers for the purpose of - presentation, allowing the description of functions common across - elements in a single section. It does not dictate an implementation - in any way. When we say that an element "contains" a layer, we mean - it is compliant to the set of rules defined by that layer. - - Not every element specified by the protocol contains every layer. - Furthermore, the elements specified by SIP are logical elements, not - physical ones. A physical realization can choose to act as different - logical elements, perhaps even on a transaction-by-transaction basis. - - The lowest layer of SIP is its syntax and encoding. Its encoding is - specified using an augmented Backus-Naur Form grammar (BNF). The - complete BNF is specified in Section 25; an overview of a SIP - message's structure can be found in Section 7. - - - - - - -Rosenberg, et. al. Standards Track [Page 18] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The second layer is the transport layer. It defines how a client - sends requests and receives responses and how a server receives - requests and sends responses over the network. All SIP elements - contain a transport layer. The transport layer is described in - Section 18. - - The third layer is the transaction layer. Transactions are a - fundamental component of SIP. A transaction is a request sent by a - client transaction (using the transport layer) to a server - transaction, along with all responses to that request sent from the - server transaction back to the client. The transaction layer handles - application-layer retransmissions, matching of responses to requests, - and application-layer timeouts. Any task that a user agent client - (UAC) accomplishes takes place using a series of transactions. - Discussion of transactions can be found in Section 17. User agents - contain a transaction layer, as do stateful proxies. Stateless - proxies do not contain a transaction layer. The transaction layer - has a client component (referred to as a client transaction) and a - server component (referred to as a server transaction), each of which - are represented by a finite state machine that is constructed to - process a particular request. - - The layer above the transaction layer is called the transaction user - (TU). Each of the SIP entities, except the stateless proxy, is a - transaction user. When a TU wishes to send a request, it creates a - client transaction instance and passes it the request along with the - destination IP address, port, and transport to which to send the - request. A TU that creates a client transaction can also cancel it. - When a client cancels a transaction, it requests that the server stop - further processing, revert to the state that existed before the - transaction was initiated, and generate a specific error response to - that transaction. This is done with a CANCEL request, which - constitutes its own transaction, but references the transaction to be - cancelled (Section 9). - - The SIP elements, that is, user agent clients and servers, stateless - and stateful proxies and registrars, contain a core that - distinguishes them from each other. Cores, except for the stateless - proxy, are transaction users. While the behavior of the UAC and UAS - cores depends on the method, there are some common rules for all - methods (Section 8). For a UAC, these rules govern the construction - of a request; for a UAS, they govern the processing of a request and - generating a response. Since registrations play an important role in - SIP, a UAS that handles a REGISTER is given the special name - registrar. Section 10 describes UAC and UAS core behavior for the - REGISTER method. Section 11 describes UAC and UAS core behavior for - the OPTIONS method, used for determining the capabilities of a UA. - - - - -Rosenberg, et. al. Standards Track [Page 19] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Certain other requests are sent within a dialog. A dialog is a - peer-to-peer SIP relationship between two user agents that persists - for some time. The dialog facilitates sequencing of messages and - proper routing of requests between the user agents. The INVITE - method is the only way defined in this specification to establish a - dialog. When a UAC sends a request that is within the context of a - dialog, it follows the common UAC rules as discussed in Section 8 but - also the rules for mid-dialog requests. Section 12 discusses dialogs - and presents the procedures for their construction and maintenance, - in addition to construction of requests within a dialog. - - The most important method in SIP is the INVITE method, which is used - to establish a session between participants. A session is a - collection of participants, and streams of media between them, for - the purposes of communication. Section 13 discusses how sessions are - initiated, resulting in one or more SIP dialogs. Section 14 - discusses how characteristics of that session are modified through - the use of an INVITE request within a dialog. Finally, section 15 - discusses how a session is terminated. - - The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal - entirely with the UA core (Section 9 describes cancellation, which - applies to both UA core and proxy core). Section 16 discusses the - proxy element, which facilitates routing of messages between user - agents. - -6 Definitions - - The following terms have special significance for SIP. - - Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI - that points to a domain with a location service that can map - the URI to another URI where the user might be available. - Typically, the location service is populated through - registrations. An AOR is frequently thought of as the "public - address" of the user. - - Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a - logical entity that receives a request and processes it as a - user agent server (UAS). In order to determine how the request - should be answered, it acts as a user agent client (UAC) and - generates requests. Unlike a proxy server, it maintains dialog - state and must participate in all requests sent on the dialogs - it has established. Since it is a concatenation of a UAC and - UAS, no explicit definitions are needed for its behavior. - - - - - - -Rosenberg, et. al. Standards Track [Page 20] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Call: A call is an informal term that refers to some communication - between peers, generally set up for the purposes of a - multimedia conversation. - - Call Leg: Another name for a dialog [31]; no longer used in this - specification. - - Call Stateful: A proxy is call stateful if it retains state for a - dialog from the initiating INVITE to the terminating BYE - request. A call stateful proxy is always transaction stateful, - but the converse is not necessarily true. - - Client: A client is any network element that sends SIP requests - and receives SIP responses. Clients may or may not interact - directly with a human user. User agent clients and proxies are - clients. - - Conference: A multimedia session (see below) that contains - multiple participants. - - Core: Core designates the functions specific to a particular type - of SIP entity, i.e., specific to either a stateful or stateless - proxy, a user agent or registrar. All cores, except those for - the stateless proxy, are transaction users. - - Dialog: A dialog is a peer-to-peer SIP relationship between two - UAs that persists for some time. A dialog is established by - SIP messages, such as a 2xx response to an INVITE request. A - dialog is identified by a call identifier, local tag, and a - remote tag. A dialog was formerly known as a call leg in RFC - 2543. - - Downstream: A direction of message forwarding within a transaction - that refers to the direction that requests flow from the user - agent client to user agent server. - - Final Response: A response that terminates a SIP transaction, as - opposed to a provisional response that does not. All 2xx, 3xx, - 4xx, 5xx and 6xx responses are final. - - Header: A header is a component of a SIP message that conveys - information about the message. It is structured as a sequence - of header fields. - - Header Field: A header field is a component of the SIP message - header. A header field can appear as one or more header field - rows. Header field rows consist of a header field name and zero - or more header field values. Multiple header field values on a - - - -Rosenberg, et. al. Standards Track [Page 21] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - given header field row are separated by commas. Some header - fields can only have a single header field value, and as a - result, always appear as a single header field row. - - Header Field Value: A header field value is a single value; a - header field consists of zero or more header field values. - - Home Domain: The domain providing service to a SIP user. - Typically, this is the domain present in the URI in the - address-of-record of a registration. - - Informational Response: Same as a provisional response. - - Initiator, Calling Party, Caller: The party initiating a session - (and dialog) with an INVITE request. A caller retains this - role from the time it sends the initial INVITE that established - a dialog until the termination of that dialog. - - Invitation: An INVITE request. - - Invitee, Invited User, Called Party, Callee: The party that - receives an INVITE request for the purpose of establishing a - new session. A callee retains this role from the time it - receives the INVITE until the termination of the dialog - established by that INVITE. - - Location Service: A location service is used by a SIP redirect or - proxy server to obtain information about a callee's possible - location(s). It contains a list of bindings of address-of- - record keys to zero or more contact addresses. The bindings - can be created and removed in many ways; this specification - defines a REGISTER method that updates the bindings. - - Loop: A request that arrives at a proxy, is forwarded, and later - arrives back at the same proxy. When it arrives the second - time, its Request-URI is identical to the first time, and other - header fields that affect proxy operation are unchanged, so - that the proxy would make the same processing decision on the - request it made the first time. Looped requests are errors, - and the procedures for detecting them and handling them are - described by the protocol. - - Loose Routing: A proxy is said to be loose routing if it follows - the procedures defined in this specification for processing of - the Route header field. These procedures separate the - destination of the request (present in the Request-URI) from - - - - - -Rosenberg, et. al. Standards Track [Page 22] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - the set of proxies that need to be visited along the way - (present in the Route header field). A proxy compliant to - these mechanisms is also known as a loose router. - - Message: Data sent between SIP elements as part of the protocol. - SIP messages are either requests or responses. - - Method: The method is the primary function that a request is meant - to invoke on a server. The method is carried in the request - message itself. Example methods are INVITE and BYE. - - Outbound Proxy: A proxy that receives requests from a client, even - though it may not be the server resolved by the Request-URI. - Typically, a UA is manually configured with an outbound proxy, - or can learn about one through auto-configuration protocols. - - Parallel Search: In a parallel search, a proxy issues several - requests to possible user locations upon receiving an incoming - request. Rather than issuing one request and then waiting for - the final response before issuing the next request as in a - sequential search, a parallel search issues requests without - waiting for the result of previous requests. - - Provisional Response: A response used by the server to indicate - progress, but that does not terminate a SIP transaction. 1xx - responses are provisional, other responses are considered - final. - - Proxy, Proxy Server: An intermediary entity that acts as both a - server and a client for the purpose of making requests on - behalf of other clients. A proxy server primarily plays the - role of routing, which means its job is to ensure that a - request is sent to another entity "closer" to the targeted - user. Proxies are also useful for enforcing policy (for - example, making sure a user is allowed to make a call). A - proxy interprets, and, if necessary, rewrites specific parts of - a request message before forwarding it. - - Recursion: A client recurses on a 3xx response when it generates a - new request to one or more of the URIs in the Contact header - field in the response. - - Redirect Server: A redirect server is a user agent server that - generates 3xx responses to requests it receives, directing the - client to contact an alternate set of URIs. - - - - - - -Rosenberg, et. al. Standards Track [Page 23] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Registrar: A registrar is a server that accepts REGISTER requests - and places the information it receives in those requests into - the location service for the domain it handles. - - Regular Transaction: A regular transaction is any transaction with - a method other than INVITE, ACK, or CANCEL. - - Request: A SIP message sent from a client to a server, for the - purpose of invoking a particular operation. - - Response: A SIP message sent from a server to a client, for - indicating the status of a request sent from the client to the - server. - - Ringback: Ringback is the signaling tone produced by the calling - party's application indicating that a called party is being - alerted (ringing). - - Route Set: A route set is a collection of ordered SIP or SIPS URI - which represent a list of proxies that must be traversed when - sending a particular request. A route set can be learned, - through headers like Record-Route, or it can be configured. - - Server: A server is a network element that receives requests in - order to service them and sends back responses to those - requests. Examples of servers are proxies, user agent servers, - redirect servers, and registrars. - - Sequential Search: In a sequential search, a proxy server attempts - each contact address in sequence, proceeding to the next one - only after the previous has generated a final response. A 2xx - or 6xx class final response always terminates a sequential - search. - - Session: From the SDP specification: "A multimedia session is a - set of multimedia senders and receivers and the data streams - flowing from senders to receivers. A multimedia conference is - an example of a multimedia session." (RFC 2327 [1]) (A session - as defined for SDP can comprise one or more RTP sessions.) As - defined, a callee can be invited several times, by different - calls, to the same session. If SDP is used, a session is - defined by the concatenation of the SDP user name, session id, - network type, address type, and address elements in the origin - field. - - SIP Transaction: A SIP transaction occurs between a client and a - server and comprises all messages from the first request sent - from the client to the server up to a final (non-1xx) response - - - -Rosenberg, et. al. Standards Track [Page 24] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - sent from the server to the client. If the request is INVITE - and the final response is a non-2xx, the transaction also - includes an ACK to the response. The ACK for a 2xx response to - an INVITE request is a separate transaction. - - Spiral: A spiral is a SIP request that is routed to a proxy, - forwarded onwards, and arrives once again at that proxy, but - this time differs in a way that will result in a different - processing decision than the original request. Typically, this - means that the request's Request-URI differs from its previous - arrival. A spiral is not an error condition, unlike a loop. A - typical cause for this is call forwarding. A user calls - joe@example.com. The example.com proxy forwards it to Joe's - PC, which in turn, forwards it to bob@example.com. This - request is proxied back to the example.com proxy. However, - this is not a loop. Since the request is targeted at a - different user, it is considered a spiral, and is a valid - condition. - - Stateful Proxy: A logical entity that maintains the client and - server transaction state machines defined by this specification - during the processing of a request, also known as a transaction - stateful proxy. The behavior of a stateful proxy is further - defined in Section 16. A (transaction) stateful proxy is not - the same as a call stateful proxy. - - Stateless Proxy: A logical entity that does not maintain the - client or server transaction state machines defined in this - specification when it processes requests. A stateless proxy - forwards every request it receives downstream and every - response it receives upstream. - - Strict Routing: A proxy is said to be strict routing if it follows - the Route processing rules of RFC 2543 and many prior work in - progress versions of this RFC. That rule caused proxies to - destroy the contents of the Request-URI when a Route header - field was present. Strict routing behavior is not used in this - specification, in favor of a loose routing behavior. Proxies - that perform strict routing are also known as strict routers. - - Target Refresh Request: A target refresh request sent within a - dialog is defined as a request that can modify the remote - target of the dialog. - - Transaction User (TU): The layer of protocol processing that - resides above the transaction layer. Transaction users include - the UAC core, UAS core, and proxy core. - - - - -Rosenberg, et. al. Standards Track [Page 25] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Upstream: A direction of message forwarding within a transaction - that refers to the direction that responses flow from the user - agent server back to the user agent client. - - URL-encoded: A character string encoded according to RFC 2396, - Section 2.4 [5]. - - User Agent Client (UAC): A user agent client is a logical entity - that creates a new request, and then uses the client - transaction state machinery to send it. The role of UAC lasts - only for the duration of that transaction. In other words, if - a piece of software initiates a request, it acts as a UAC for - the duration of that transaction. If it receives a request - later, it assumes the role of a user agent server for the - processing of that transaction. - - UAC Core: The set of processing functions required of a UAC that - reside above the transaction and transport layers. - - User Agent Server (UAS): A user agent server is a logical entity - that generates a response to a SIP request. The response - accepts, rejects, or redirects the request. This role lasts - only for the duration of that transaction. In other words, if - a piece of software responds to a request, it acts as a UAS for - the duration of that transaction. If it generates a request - later, it assumes the role of a user agent client for the - processing of that transaction. - - UAS Core: The set of processing functions required at a UAS that - resides above the transaction and transport layers. - - User Agent (UA): A logical entity that can act as both a user - agent client and user agent server. - - The role of UAC and UAS, as well as proxy and redirect servers, are - defined on a transaction-by-transaction basis. For example, the user - agent initiating a call acts as a UAC when sending the initial INVITE - request and as a UAS when receiving a BYE request from the callee. - Similarly, the same software can act as a proxy server for one - request and as a redirect server for the next request. - - Proxy, location, and registrar servers defined above are logical - entities; implementations MAY combine them into a single application. - -7 SIP Messages - - SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279 - [7]). - - - -Rosenberg, et. al. Standards Track [Page 26] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - A SIP message is either a request from a client to a server, or a - response from a server to a client. - - Both Request (section 7.1) and Response (section 7.2) messages use - the basic format of RFC 2822 [3], even though the syntax differs in - character set and syntax specifics. (SIP allows header fields that - would not be valid RFC 2822 header fields, for example.) Both types - of messages consist of a start-line, one or more header fields, an - empty line indicating the end of the header fields, and an optional - message-body. - - generic-message = start-line - *message-header - CRLF - [ message-body ] - start-line = Request-Line / Status-Line - - The start-line, each message-header line, and the empty line MUST be - terminated by a carriage-return line-feed sequence (CRLF). Note that - the empty line MUST be present even if the message-body is not. - - Except for the above difference in character sets, much of SIP's - message and header field syntax is identical to HTTP/1.1. Rather - than repeating the syntax and semantics here, we use [HX.Y] to refer - to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]). - - However, SIP is not an extension of HTTP. - -7.1 Requests - - SIP requests are distinguished by having a Request-Line for a start- - line. A Request-Line contains a method name, a Request-URI, and the - protocol version separated by a single space (SP) character. - - The Request-Line ends with CRLF. No CR or LF are allowed except in - the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed - in any of the elements. - - Request-Line = Method SP Request-URI SP SIP-Version CRLF - - Method: This specification defines six methods: REGISTER for - registering contact information, INVITE, ACK, and CANCEL for - setting up sessions, BYE for terminating sessions, and - OPTIONS for querying servers about their capabilities. SIP - extensions, documented in standards track RFCs, may define - additional methods. - - - - - -Rosenberg, et. al. Standards Track [Page 27] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Request-URI: The Request-URI is a SIP or SIPS URI as described in - Section 19.1 or a general URI (RFC 2396 [5]). It indicates - the user or service to which this request is being addressed. - The Request-URI MUST NOT contain unescaped spaces or control - characters and MUST NOT be enclosed in "<>". - - SIP elements MAY support Request-URIs with schemes other than - "sip" and "sips", for example the "tel" URI scheme of RFC - 2806 [9]. SIP elements MAY translate non-SIP URIs using any - mechanism at their disposal, resulting in SIP URI, SIPS URI, - or some other scheme. - - SIP-Version: Both request and response messages include the - version of SIP in use, and follow [H3.1] (with HTTP replaced - by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version - ordering, compliance requirements, and upgrading of version - numbers. To be compliant with this specification, - applications sending SIP messages MUST include a SIP-Version - of "SIP/2.0". The SIP-Version string is case-insensitive, - but implementations MUST send upper-case. - - Unlike HTTP/1.1, SIP treats the version number as a literal - string. In practice, this should make no difference. - -7.2 Responses - - SIP responses are distinguished from requests by having a Status-Line - as their start-line. A Status-Line consists of the protocol version - followed by a numeric Status-Code and its associated textual phrase, - with each element separated by a single SP character. - - No CR or LF is allowed except in the final CRLF sequence. - - Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF - - The Status-Code is a 3-digit integer result code that indicates the - outcome of an attempt to understand and satisfy a request. The - Reason-Phrase is intended to give a short textual description of the - Status-Code. The Status-Code is intended for use by automata, - whereas the Reason-Phrase is intended for the human user. A client - is not required to examine or display the Reason-Phrase. - - While this specification suggests specific wording for the reason - phrase, implementations MAY choose other text, for example, in the - language indicated in the Accept-Language header field of the - request. - - - - - -Rosenberg, et. al. Standards Track [Page 28] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The first digit of the Status-Code defines the class of response. - The last two digits do not have any categorization role. For this - reason, any response with a status code between 100 and 199 is - referred to as a "1xx response", any response with a status code - between 200 and 299 as a "2xx response", and so on. SIP/2.0 allows - six values for the first digit: - - 1xx: Provisional -- request received, continuing to process the - request; - - 2xx: Success -- the action was successfully received, understood, - and accepted; - - 3xx: Redirection -- further action needs to be taken in order to - complete the request; - - 4xx: Client Error -- the request contains bad syntax or cannot be - fulfilled at this server; - - 5xx: Server Error -- the server failed to fulfill an apparently - valid request; - - 6xx: Global Failure -- the request cannot be fulfilled at any - server. - - Section 21 defines these classes and describes the individual codes. - -7.3 Header Fields - - SIP header fields are similar to HTTP header fields in both syntax - and semantics. In particular, SIP header fields follow the [H4.2] - definitions of syntax for the message-header and the rules for - extending header fields over multiple lines. However, the latter is - specified in HTTP with implicit whitespace and folding. This - specification conforms to RFC 2234 [10] and uses only explicit - whitespace and folding as an integral part of the grammar. - - [H4.2] also specifies that multiple header fields of the same field - name whose value is a comma-separated list can be combined into one - header field. That applies to SIP as well, but the specific rule is - different because of the different grammars. Specifically, any SIP - header whose grammar is of the form - - header = "header-name" HCOLON header-value *(COMMA header-value) - - allows for combining header fields of the same name into a comma- - separated list. The Contact header field allows a comma-separated - list unless the header field value is "*". - - - -Rosenberg, et. al. Standards Track [Page 29] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -7.3.1 Header Field Format - - Header fields follow the same generic header format as that given in - Section 2.2 of RFC 2822 [3]. Each header field consists of a field - name followed by a colon (":") and the field value. - - field-name: field-value - - The formal grammar for a message-header specified in Section 25 - allows for an arbitrary amount of whitespace on either side of the - colon; however, implementations should avoid spaces between the field - name and the colon and use a single space (SP) between the colon and - the field-value. - - Subject: lunch - Subject : lunch - Subject :lunch - Subject: lunch - - Thus, the above are all valid and equivalent, but the last is the - preferred form. - - Header fields can be extended over multiple lines by preceding each - extra line with at least one SP or horizontal tab (HT). The line - break and the whitespace at the beginning of the next line are - treated as a single SP character. Thus, the following are - equivalent: - - Subject: I know you're there, pick up the phone and talk to me! - Subject: I know you're there, - pick up the phone - and talk to me! - - The relative order of header fields with different field names is not - significant. However, it is RECOMMENDED that header fields which are - needed for proxy processing (Via, Route, Record-Route, Proxy-Require, - Max-Forwards, and Proxy-Authorization, for example) appear towards - the top of the message to facilitate rapid parsing. The relative - order of header field rows with the same field name is important. - Multiple header field rows with the same field-name MAY be present in - a message if and only if the entire field-value for that header field - is defined as a comma-separated list (that is, if follows the grammar - defined in Section 7.3). It MUST be possible to combine the multiple - header field rows into one "field-name: field-value" pair, without - changing the semantics of the message, by appending each subsequent - field-value to the first, each separated by a comma. The exceptions - to this rule are the WWW-Authenticate, Authorization, Proxy- - Authenticate, and Proxy-Authorization header fields. Multiple header - - - -Rosenberg, et. al. Standards Track [Page 30] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - field rows with these names MAY be present in a message, but since - their grammar does not follow the general form listed in Section 7.3, - they MUST NOT be combined into a single header field row. - - Implementations MUST be able to process multiple header field rows - with the same name in any combination of the single-value-per-line or - comma-separated value forms. - - The following groups of header field rows are valid and equivalent: - - Route: - Subject: Lunch - Route: - Route: - - Route: , - Route: - Subject: Lunch - - Subject: Lunch - Route: , , - - - Each of the following blocks is valid but not equivalent to the - others: - - Route: - Route: - Route: - - Route: - Route: - Route: - - Route: ,, - - - The format of a header field-value is defined per header-name. It - will always be either an opaque sequence of TEXT-UTF8 octets, or a - combination of whitespace, tokens, separators, and quoted strings. - Many existing header fields will adhere to the general form of a - value followed by a semi-colon separated sequence of parameter-name, - parameter-value pairs: - - field-name: field-value *(;parameter-name=parameter-value) - - - - - - -Rosenberg, et. al. Standards Track [Page 31] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Even though an arbitrary number of parameter pairs may be attached to - a header field value, any given parameter-name MUST NOT appear more - than once. - - When comparing header fields, field names are always case- - insensitive. Unless otherwise stated in the definition of a - particular header field, field values, parameter names, and parameter - values are case-insensitive. Tokens are always case-insensitive. - Unless specified otherwise, values expressed as quoted strings are - case-sensitive. For example, - - Contact: ;expires=3600 - - is equivalent to - - CONTACT: ;ExPiReS=3600 - - and - - Content-Disposition: session;handling=optional - - is equivalent to - - content-disposition: Session;HANDLING=OPTIONAL - - The following two header fields are not equivalent: - - Warning: 370 devnull "Choose a bigger pipe" - Warning: 370 devnull "CHOOSE A BIGGER PIPE" - -7.3.2 Header Field Classification - - Some header fields only make sense in requests or responses. These - are called request header fields and response header fields, - respectively. If a header field appears in a message not matching - its category (such as a request header field in a response), it MUST - be ignored. Section 20 defines the classification of each header - field. - -7.3.3 Compact Form - - SIP provides a mechanism to represent common header field names in an - abbreviated form. This may be useful when messages would otherwise - become too large to be carried on the transport available to it - (exceeding the maximum transmission unit (MTU) when using UDP, for - example). These compact forms are defined in Section 20. A compact - form MAY be substituted for the longer form of a header field name at - any time without changing the semantics of the message. A header - - - -Rosenberg, et. al. Standards Track [Page 32] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - field name MAY appear in both long and short forms within the same - message. Implementations MUST accept both the long and short forms - of each header name. - -7.4 Bodies - - Requests, including new requests defined in extensions to this - specification, MAY contain message bodies unless otherwise noted. - The interpretation of the body depends on the request method. - - For response messages, the request method and the response status - code determine the type and interpretation of any message body. All - responses MAY include a body. - -7.4.1 Message Body Type - - The Internet media type of the message body MUST be given by the - Content-Type header field. If the body has undergone any encoding - such as compression, then this MUST be indicated by the Content- - Encoding header field; otherwise, Content-Encoding MUST be omitted. - If applicable, the character set of the message body is indicated as - part of the Content-Type header-field value. - - The "multipart" MIME type defined in RFC 2046 [11] MAY be used within - the body of the message. Implementations that send requests - containing multipart message bodies MUST send a session description - as a non-multipart message body if the remote implementation requests - this through an Accept header field that does not contain multipart. - - SIP messages MAY contain binary bodies or body parts. When no - explicit charset parameter is provided by the sender, media subtypes - of the "text" type are defined to have a default charset value of - "UTF-8". - -7.4.2 Message Body Length - - The body length in bytes is provided by the Content-Length header - field. Section 20.14 describes the necessary contents of this header - field in detail. - - The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP. - (Note: The chunked encoding modifies the body of a message in order - to transfer it as a series of chunks, each with its own size - indicator.) - - - - - - - -Rosenberg, et. al. Standards Track [Page 33] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -7.5 Framing SIP Messages - - Unlike HTTP, SIP implementations can use UDP or other unreliable - datagram protocols. Each such datagram carries one request or - response. See Section 18 on constraints on usage of unreliable - transports. - - Implementations processing SIP messages over stream-oriented - transports MUST ignore any CRLF appearing before the start-line - [H4.1]. - - The Content-Length header field value is used to locate the end of - each SIP message in a stream. It will always be present when SIP - messages are sent over stream-oriented transports. - -8 General User Agent Behavior - - A user agent represents an end system. It contains a user agent - client (UAC), which generates requests, and a user agent server - (UAS), which responds to them. A UAC is capable of generating a - request based on some external stimulus (the user clicking a button, - or a signal on a PSTN line) and processing a response. A UAS is - capable of receiving a request and generating a response based on - user input, external stimulus, the result of a program execution, or - some other mechanism. - - When a UAC sends a request, the request passes through some number of - proxy servers, which forward the request towards the UAS. When the - UAS generates a response, the response is forwarded towards the UAC. - - UAC and UAS procedures depend strongly on two factors. First, based - on whether the request or response is inside or outside of a dialog, - and second, based on the method of a request. Dialogs are discussed - thoroughly in Section 12; they represent a peer-to-peer relationship - between user agents and are established by specific SIP methods, such - as INVITE. - - In this section, we discuss the method-independent rules for UAC and - UAS behavior when processing requests that are outside of a dialog. - This includes, of course, the requests which themselves establish a - dialog. - - Security procedures for requests and responses outside of a dialog - are described in Section 26. Specifically, mechanisms exist for the - UAS and UAC to mutually authenticate. A limited set of privacy - features are also supported through encryption of bodies using - S/MIME. - - - - -Rosenberg, et. al. Standards Track [Page 34] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -8.1 UAC Behavior - - This section covers UAC behavior outside of a dialog. - -8.1.1 Generating the Request - - A valid SIP request formulated by a UAC MUST, at a minimum, contain - the following header fields: To, From, CSeq, Call-ID, Max-Forwards, - and Via; all of these header fields are mandatory in all SIP - requests. These six header fields are the fundamental building - blocks of a SIP message, as they jointly provide for most of the - critical message routing services including the addressing of - messages, the routing of responses, limiting message propagation, - ordering of messages, and the unique identification of transactions. - These header fields are in addition to the mandatory request line, - which contains the method, Request-URI, and SIP version. - - Examples of requests sent outside of a dialog include an INVITE to - establish a session (Section 13) and an OPTIONS to query for - capabilities (Section 11). - -8.1.1.1 Request-URI - - The initial Request-URI of the message SHOULD be set to the value of - the URI in the To field. One notable exception is the REGISTER - method; behavior for setting the Request-URI of REGISTER is given in - Section 10. It may also be undesirable for privacy reasons or - convenience to set these fields to the same value (especially if the - originating UA expects that the Request-URI will be changed during - transit). - - In some special circumstances, the presence of a pre-existing route - set can affect the Request-URI of the message. A pre-existing route - set is an ordered set of URIs that identify a chain of servers, to - which a UAC will send outgoing requests that are outside of a dialog. - Commonly, they are configured on the UA by a user or service provider - manually, or through some other non-SIP mechanism. When a provider - wishes to configure a UA with an outbound proxy, it is RECOMMENDED - that this be done by providing it with a pre-existing route set with - a single URI, that of the outbound proxy. - - When a pre-existing route set is present, the procedures for - populating the Request-URI and Route header field detailed in Section - 12.2.1.1 MUST be followed (even though there is no dialog), using the - desired Request-URI as the remote target URI. - - - - - - -Rosenberg, et. al. Standards Track [Page 35] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -8.1.1.2 To - - The To header field first and foremost specifies the desired - "logical" recipient of the request, or the address-of-record of the - user or resource that is the target of this request. This may or may - not be the ultimate recipient of the request. The To header field - MAY contain a SIP or SIPS URI, but it may also make use of other URI - schemes (the tel URL (RFC 2806 [9]), for example) when appropriate. - All SIP implementations MUST support the SIP URI scheme. Any - implementation that supports TLS MUST support the SIPS URI scheme. - The To header field allows for a display name. - - A UAC may learn how to populate the To header field for a particular - request in a number of ways. Usually the user will suggest the To - header field through a human interface, perhaps inputting the URI - manually or selecting it from some sort of address book. Frequently, - the user will not enter a complete URI, but rather a string of digits - or letters (for example, "bob"). It is at the discretion of the UA - to choose how to interpret this input. Using the string to form the - user part of a SIP URI implies that the UA wishes the name to be - resolved in the domain to the right-hand side (RHS) of the at-sign in - the SIP URI (for instance, sip:bob@example.com). Using the string to - form the user part of a SIPS URI implies that the UA wishes to - communicate securely, and that the name is to be resolved in the - domain to the RHS of the at-sign. The RHS will frequently be the - home domain of the requestor, which allows for the home domain to - process the outgoing request. This is useful for features like - "speed dial" that require interpretation of the user part in the home - domain. The tel URL may be used when the UA does not wish to specify - the domain that should interpret a telephone number that has been - input by the user. Rather, each domain through which the request - passes would be given that opportunity. As an example, a user in an - airport might log in and send requests through an outbound proxy in - the airport. If they enter "411" (this is the phone number for local - directory assistance in the United States), that needs to be - interpreted and processed by the outbound proxy in the airport, not - the user's home domain. In this case, tel:411 would be the right - choice. - - A request outside of a dialog MUST NOT contain a To tag; the tag in - the To field of a request identifies the peer of the dialog. Since - no dialog is established, no tag is present. - - For further information on the To header field, see Section 20.39. - The following is an example of a valid To header field: - - To: Carol - - - - -Rosenberg, et. al. Standards Track [Page 36] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -8.1.1.3 From - - The From header field indicates the logical identity of the initiator - of the request, possibly the user's address-of-record. Like the To - header field, it contains a URI and optionally a display name. It is - used by SIP elements to determine which processing rules to apply to - a request (for example, automatic call rejection). As such, it is - very important that the From URI not contain IP addresses or the FQDN - of the host on which the UA is running, since these are not logical - names. - - The From header field allows for a display name. A UAC SHOULD use - the display name "Anonymous", along with a syntactically correct, but - otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the - identity of the client is to remain hidden. - - Usually, the value that populates the From header field in requests - generated by a particular UA is pre-provisioned by the user or by the - administrators of the user's local domain. If a particular UA is - used by multiple users, it might have switchable profiles that - include a URI corresponding to the identity of the profiled user. - Recipients of requests can authenticate the originator of a request - in order to ascertain that they are who their From header field - claims they are (see Section 22 for more on authentication). - - The From field MUST contain a new "tag" parameter, chosen by the UAC. - See Section 19.3 for details on choosing a tag. - - For further information on the From header field, see Section 20.20. - Examples: - - From: "Bob" ;tag=a48s - From: sip:+12125551212@phone2net.com;tag=887s - From: Anonymous ;tag=hyh8 - -8.1.1.4 Call-ID - - The Call-ID header field acts as a unique identifier to group - together a series of messages. It MUST be the same for all requests - and responses sent by either UA in a dialog. It SHOULD be the same - in each registration from a UA. - - In a new request created by a UAC outside of any dialog, the Call-ID - header field MUST be selected by the UAC as a globally unique - identifier over space and time unless overridden by method-specific - behavior. All SIP UAs must have a means to guarantee that the Call- - ID header fields they produce will not be inadvertently generated by - any other UA. Note that when requests are retried after certain - - - -Rosenberg, et. al. Standards Track [Page 37] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - failure responses that solicit an amendment to a request (for - example, a challenge for authentication), these retried requests are - not considered new requests, and therefore do not need new Call-ID - header fields; see Section 8.1.3.5. - - Use of cryptographically random identifiers (RFC 1750 [12]) in the - generation of Call-IDs is RECOMMENDED. Implementations MAY use the - form "localid@host". Call-IDs are case-sensitive and are simply - compared byte-by-byte. - - Using cryptographically random identifiers provides some - protection against session hijacking and reduces the likelihood of - unintentional Call-ID collisions. - - No provisioning or human interface is required for the selection of - the Call-ID header field value for a request. - - For further information on the Call-ID header field, see Section - 20.8. - - Example: - - Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com - -8.1.1.5 CSeq - - The CSeq header field serves as a way to identify and order - transactions. It consists of a sequence number and a method. The - method MUST match that of the request. For non-REGISTER requests - outside of a dialog, the sequence number value is arbitrary. The - sequence number value MUST be expressible as a 32-bit unsigned - integer and MUST be less than 2**31. As long as it follows the above - guidelines, a client may use any mechanism it would like to select - CSeq header field values. - - Section 12.2.1.1 discusses construction of the CSeq for requests - within a dialog. - - Example: - - CSeq: 4711 INVITE - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 38] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -8.1.1.6 Max-Forwards - - The Max-Forwards header field serves to limit the number of hops a - request can transit on the way to its destination. It consists of an - integer that is decremented by one at each hop. If the Max-Forwards - value reaches 0 before the request reaches its destination, it will - be rejected with a 483(Too Many Hops) error response. - - A UAC MUST insert a Max-Forwards header field into each request it - originates with a value that SHOULD be 70. This number was chosen to - be sufficiently large to guarantee that a request would not be - dropped in any SIP network when there were no loops, but not so large - as to consume proxy resources when a loop does occur. Lower values - should be used with caution and only in networks where topologies are - known by the UA. - -8.1.1.7 Via - - The Via header field indicates the transport used for the transaction - and identifies the location where the response is to be sent. A Via - header field value is added only after the transport that will be - used to reach the next hop has been selected (which may involve the - usage of the procedures in [4]). - - When the UAC creates a request, it MUST insert a Via into that - request. The protocol name and protocol version in the header field - MUST be SIP and 2.0, respectively. The Via header field value MUST - contain a branch parameter. This parameter is used to identify the - transaction created by that request. This parameter is used by both - the client and the server. - - The branch parameter value MUST be unique across space and time for - all requests sent by the UA. The exceptions to this rule are CANCEL - and ACK for non-2xx responses. As discussed below, a CANCEL request - will have the same value of the branch parameter as the request it - cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx - response will also have the same branch ID as the INVITE whose - response it acknowledges. - - The uniqueness property of the branch ID parameter, to facilitate - its use as a transaction ID, was not part of RFC 2543. - - The branch ID inserted by an element compliant with this - specification MUST always begin with the characters "z9hG4bK". These - 7 characters are used as a magic cookie (7 is deemed sufficient to - ensure that an older RFC 2543 implementation would not pick such a - value), so that servers receiving the request can determine that the - branch ID was constructed in the fashion described by this - - - -Rosenberg, et. al. Standards Track [Page 39] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - specification (that is, globally unique). Beyond this requirement, - the precise format of the branch token is implementation-defined. - - The Via header maddr, ttl, and sent-by components will be set when - the request is processed by the transport layer (Section 18). - - Via processing for proxies is described in Section 16.6 Item 8 and - Section 16.7 Item 3. - -8.1.1.8 Contact - - The Contact header field provides a SIP or SIPS URI that can be used - to contact that specific instance of the UA for subsequent requests. - The Contact header field MUST be present and contain exactly one SIP - or SIPS URI in any request that can result in the establishment of a - dialog. For the methods defined in this specification, that includes - only the INVITE request. For these requests, the scope of the - Contact is global. That is, the Contact header field value contains - the URI at which the UA would like to receive requests, and this URI - MUST be valid even if used in subsequent requests outside of any - dialogs. - - If the Request-URI or top Route header field value contains a SIPS - URI, the Contact header field MUST contain a SIPS URI as well. - - For further information on the Contact header field, see Section - 20.10. - -8.1.1.9 Supported and Require - - If the UAC supports extensions to SIP that can be applied by the - server to the response, the UAC SHOULD include a Supported header - field in the request listing the option tags (Section 19.2) for those - extensions. - - The option tags listed MUST only refer to extensions defined in - standards-track RFCs. This is to prevent servers from insisting that - clients implement non-standard, vendor-defined features in order to - receive service. Extensions defined by experimental and - informational RFCs are explicitly excluded from usage with the - Supported header field in a request, since they too are often used to - document vendor-defined extensions. - - If the UAC wishes to insist that a UAS understand an extension that - the UAC will apply to the request in order to process the request, it - MUST insert a Require header field into the request listing the - option tag for that extension. If the UAC wishes to apply an - extension to the request and insist that any proxies that are - - - -Rosenberg, et. al. Standards Track [Page 40] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - traversed understand that extension, it MUST insert a Proxy-Require - header field into the request listing the option tag for that - extension. - - As with the Supported header field, the option tags in the Require - and Proxy-Require header fields MUST only refer to extensions defined - in standards-track RFCs. - -8.1.1.10 Additional Message Components - - After a new request has been created, and the header fields described - above have been properly constructed, any additional optional header - fields are added, as are any header fields specific to the method. - - SIP requests MAY contain a MIME-encoded message-body. Regardless of - the type of body that a request contains, certain header fields must - be formulated to characterize the contents of the body. For further - information on these header fields, see Sections 20.11 through 20.15. - -8.1.2 Sending the Request - - The destination for the request is then computed. Unless there is - local policy specifying otherwise, the destination MUST be determined - by applying the DNS procedures described in [4] as follows. If the - first element in the route set indicated a strict router (resulting - in forming the request as described in Section 12.2.1.1), the - procedures MUST be applied to the Request-URI of the request. - Otherwise, the procedures are applied to the first Route header field - value in the request (if one exists), or to the request's Request-URI - if there is no Route header field present. These procedures yield an - ordered set of address, port, and transports to attempt. Independent - of which URI is used as input to the procedures of [4], if the - Request-URI specifies a SIPS resource, the UAC MUST follow the - procedures of [4] as if the input URI were a SIPS URI. - - Local policy MAY specify an alternate set of destinations to attempt. - If the Request-URI contains a SIPS URI, any alternate destinations - MUST be contacted with TLS. Beyond that, there are no restrictions - on the alternate destinations if the request contains no Route header - field. This provides a simple alternative to a pre-existing route - set as a way to specify an outbound proxy. However, that approach - for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing - route set with a single URI SHOULD be used instead. If the request - contains a Route header field, the request SHOULD be sent to the - locations derived from its topmost value, but MAY be sent to any - server that the UA is certain will honor the Route and Request-URI - policies specified in this document (as opposed to those in RFC - 2543). In particular, a UAC configured with an outbound proxy SHOULD - - - -Rosenberg, et. al. Standards Track [Page 41] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - attempt to send the request to the location indicated in the first - Route header field value instead of adopting the policy of sending - all messages to the outbound proxy. - - This ensures that outbound proxies that do not add Record-Route - header field values will drop out of the path of subsequent - requests. It allows endpoints that cannot resolve the first Route - URI to delegate that task to an outbound proxy. - - The UAC SHOULD follow the procedures defined in [4] for stateful - elements, trying each address until a server is contacted. Each try - constitutes a new transaction, and therefore each carries a different - topmost Via header field value with a new branch parameter. - Furthermore, the transport value in the Via header field is set to - whatever transport was determined for the target server. - -8.1.3 Processing Responses - - Responses are first processed by the transport layer and then passed - up to the transaction layer. The transaction layer performs its - processing and then passes the response up to the TU. The majority - of response processing in the TU is method specific. However, there - are some general behaviors independent of the method. - -8.1.3.1 Transaction Layer Errors - - In some cases, the response returned by the transaction layer will - not be a SIP message, but rather a transaction layer error. When a - timeout error is received from the transaction layer, it MUST be - treated as if a 408 (Request Timeout) status code has been received. - If a fatal transport error is reported by the transport layer - (generally, due to fatal ICMP errors in UDP or connection failures in - TCP), the condition MUST be treated as a 503 (Service Unavailable) - status code. - -8.1.3.2 Unrecognized Responses - - A UAC MUST treat any final response it does not recognize as being - equivalent to the x00 response code of that class, and MUST be able - to process the x00 response code for all classes. For example, if a - UAC receives an unrecognized response code of 431, it can safely - assume that there was something wrong with its request and treat the - response as if it had received a 400 (Bad Request) response code. A - UAC MUST treat any provisional response different than 100 that it - does not recognize as 183 (Session Progress). A UAC MUST be able to - process 100 and 183 responses. - - - - - -Rosenberg, et. al. Standards Track [Page 42] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -8.1.3.3 Vias - - If more than one Via header field value is present in a response, the - UAC SHOULD discard the message. - - The presence of additional Via header field values that precede - the originator of the request suggests that the message was - misrouted or possibly corrupted. - -8.1.3.4 Processing 3xx Responses - - Upon receipt of a redirection response (for example, a 301 response - status code), clients SHOULD use the URI(s) in the Contact header - field to formulate one or more new requests based on the redirected - request. This process is similar to that of a proxy recursing on a - 3xx class response as detailed in Sections 16.5 and 16.6. A client - starts with an initial target set containing exactly one URI, the - Request-URI of the original request. If a client wishes to formulate - new requests based on a 3xx class response to that request, it places - the URIs to try into the target set. Subject to the restrictions in - this specification, a client can choose which Contact URIs it places - into the target set. As with proxy recursion, a client processing - 3xx class responses MUST NOT add any given URI to the target set more - than once. If the original request had a SIPS URI in the Request- - URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD - inform the user of the redirection to an insecure URI. - - Any new request may receive 3xx responses themselves containing - the original URI as a contact. Two locations can be configured to - redirect to each other. Placing any given URI in the target set - only once prevents infinite redirection loops. - - As the target set grows, the client MAY generate new requests to the - URIs in any order. A common mechanism is to order the set by the "q" - parameter value from the Contact header field value. Requests to the - URIs MAY be generated serially or in parallel. One approach is to - process groups of decreasing q-values serially and process the URIs - in each q-value group in parallel. Another is to perform only serial - processing in decreasing q-value order, arbitrarily choosing between - contacts of equal q-value. - - If contacting an address in the list results in a failure, as defined - in the next paragraph, the element moves to the next address in the - list, until the list is exhausted. If the list is exhausted, then - the request has failed. - - - - - - -Rosenberg, et. al. Standards Track [Page 43] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Failures SHOULD be detected through failure response codes (codes - greater than 399); for network errors the client transaction will - report any transport layer failures to the transaction user. Note - that some response codes (detailed in 8.1.3.5) indicate that the - request can be retried; requests that are reattempted should not be - considered failures. - - When a failure for a particular contact address is received, the - client SHOULD try the next contact address. This will involve - creating a new client transaction to deliver a new request. - - In order to create a request based on a contact address in a 3xx - response, a UAC MUST copy the entire URI from the target set into the - Request-URI, except for the "method-param" and "header" URI - parameters (see Section 19.1.1 for a definition of these parameters). - It uses the "header" parameters to create header field values for the - new request, overwriting header field values associated with the - redirected request in accordance with the guidelines in Section - 19.1.5. - - Note that in some instances, header fields that have been - communicated in the contact address may instead append to existing - request header fields in the original redirected request. As a - general rule, if the header field can accept a comma-separated list - of values, then the new header field value MAY be appended to any - existing values in the original redirected request. If the header - field does not accept multiple values, the value in the original - redirected request MAY be overwritten by the header field value - communicated in the contact address. For example, if a contact - address is returned with the following value: - - sip:user@host?Subject=foo&Call-Info= - - Then any Subject header field in the original redirected request is - overwritten, but the HTTP URL is merely appended to any existing - Call-Info header field values. - - It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID - used in the original redirected request, but the UAC MAY also choose - to update the Call-ID header field value for new requests, for - example. - - Finally, once the new request has been constructed, it is sent using - a new client transaction, and therefore MUST have a new branch ID in - the top Via field as discussed in Section 8.1.1.7. - - - - - - -Rosenberg, et. al. Standards Track [Page 44] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - In all other respects, requests sent upon receipt of a redirect - response SHOULD re-use the header fields and bodies of the original - request. - - In some instances, Contact header field values may be cached at UAC - temporarily or permanently depending on the status code received and - the presence of an expiration interval; see Sections 21.3.2 and - 21.3.3. - -8.1.3.5 Processing 4xx Responses - - Certain 4xx response codes require specific UA processing, - independent of the method. - - If a 401 (Unauthorized) or 407 (Proxy Authentication Required) - response is received, the UAC SHOULD follow the authorization - procedures of Section 22.2 and Section 22.3 to retry the request with - credentials. - - If a 413 (Request Entity Too Large) response is received (Section - 21.4.11), the request contained a body that was longer than the UAS - was willing to accept. If possible, the UAC SHOULD retry the - request, either omitting the body or using one of a smaller length. - - If a 415 (Unsupported Media Type) response is received (Section - 21.4.13), the request contained media types not supported by the UAS. - The UAC SHOULD retry sending the request, this time only using - content with types listed in the Accept header field in the response, - with encodings listed in the Accept-Encoding header field in the - response, and with languages listed in the Accept-Language in the - response. - - If a 416 (Unsupported URI Scheme) response is received (Section - 21.4.14), the Request-URI used a URI scheme not supported by the - server. The client SHOULD retry the request, this time, using a SIP - URI. - - If a 420 (Bad Extension) response is received (Section 21.4.15), the - request contained a Require or Proxy-Require header field listing an - option-tag for a feature not supported by a proxy or UAS. The UAC - SHOULD retry the request, this time omitting any extensions listed in - the Unsupported header field in the response. - - In all of the above cases, the request is retried by creating a new - request with the appropriate modifications. This new request - constitutes a new transaction and SHOULD have the same value of the - Call-ID, To, and From of the previous request, but the CSeq should - contain a new sequence number that is one higher than the previous. - - - -Rosenberg, et. al. Standards Track [Page 45] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - With other 4xx responses, including those yet to be defined, a retry - may or may not be possible depending on the method and the use case. - -8.2 UAS Behavior - - When a request outside of a dialog is processed by a UAS, there is a - set of processing rules that are followed, independent of the method. - Section 12 gives guidance on how a UAS can tell whether a request is - inside or outside of a dialog. - - Note that request processing is atomic. If a request is accepted, - all state changes associated with it MUST be performed. If it is - rejected, all state changes MUST NOT be performed. - - UASs SHOULD process the requests in the order of the steps that - follow in this section (that is, starting with authentication, then - inspecting the method, the header fields, and so on throughout the - remainder of this section). - -8.2.1 Method Inspection - - Once a request is authenticated (or authentication is skipped), the - UAS MUST inspect the method of the request. If the UAS recognizes - but does not support the method of a request, it MUST generate a 405 - (Method Not Allowed) response. Procedures for generating responses - are described in Section 8.2.6. The UAS MUST also add an Allow - header field to the 405 (Method Not Allowed) response. The Allow - header field MUST list the set of methods supported by the UAS - generating the message. The Allow header field is presented in - Section 20.5. - - If the method is one supported by the server, processing continues. - -8.2.2 Header Inspection - - If a UAS does not understand a header field in a request (that is, - the header field is not defined in this specification or in any - supported extension), the server MUST ignore that header field and - continue processing the message. A UAS SHOULD ignore any malformed - header fields that are not necessary for processing requests. - -8.2.2.1 To and Request-URI - - The To header field identifies the original recipient of the request - designated by the user identified in the From field. The original - recipient may or may not be the UAS processing the request, due to - call forwarding or other proxy operations. A UAS MAY apply any - policy it wishes to determine whether to accept requests when the To - - - -Rosenberg, et. al. Standards Track [Page 46] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - header field is not the identity of the UAS. However, it is - RECOMMENDED that a UAS accept requests even if they do not recognize - the URI scheme (for example, a tel: URI) in the To header field, or - if the To header field does not address a known or current user of - this UAS. If, on the other hand, the UAS decides to reject the - request, it SHOULD generate a response with a 403 (Forbidden) status - code and pass it to the server transaction for transmission. - - However, the Request-URI identifies the UAS that is to process the - request. If the Request-URI uses a scheme not supported by the UAS, - it SHOULD reject the request with a 416 (Unsupported URI Scheme) - response. If the Request-URI does not identify an address that the - UAS is willing to accept requests for, it SHOULD reject the request - with a 404 (Not Found) response. Typically, a UA that uses the - REGISTER method to bind its address-of-record to a specific contact - address will see requests whose Request-URI equals that contact - address. Other potential sources of received Request-URIs include - the Contact header fields of requests and responses sent by the UA - that establish or refresh dialogs. - -8.2.2.2 Merged Requests - - If the request has no tag in the To header field, the UAS core MUST - check the request against ongoing transactions. If the From tag, - Call-ID, and CSeq exactly match those associated with an ongoing - transaction, but the request does not match that transaction (based - on the matching rules in Section 17.2.3), the UAS core SHOULD - generate a 482 (Loop Detected) response and pass it to the server - transaction. - - The same request has arrived at the UAS more than once, following - different paths, most likely due to forking. The UAS processes - the first such request received and responds with a 482 (Loop - Detected) to the rest of them. - -8.2.2.3 Require - - Assuming the UAS decides that it is the proper element to process the - request, it examines the Require header field, if present. - - The Require header field is used by a UAC to tell a UAS about SIP - extensions that the UAC expects the UAS to support in order to - process the request properly. Its format is described in Section - 20.32. If a UAS does not understand an option-tag listed in a - Require header field, it MUST respond by generating a response with - status code 420 (Bad Extension). The UAS MUST add an Unsupported - header field, and list in it those options it does not understand - amongst those in the Require header field of the request. - - - -Rosenberg, et. al. Standards Track [Page 47] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL - request, or in an ACK request sent for a non-2xx response. These - header fields MUST be ignored if they are present in these requests. - - An ACK request for a 2xx response MUST contain only those Require and - Proxy-Require values that were present in the initial request. - - Example: - - UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0 - Require: 100rel - - UAS->UAC: SIP/2.0 420 Bad Extension - Unsupported: 100rel - - This behavior ensures that the client-server interaction will - proceed without delay when all options are understood by both - sides, and only slow down if options are not understood (as in the - example above). For a well-matched client-server pair, the - interaction proceeds quickly, saving a round-trip often required - by negotiation mechanisms. In addition, it also removes ambiguity - when the client requires features that the server does not - understand. Some features, such as call handling fields, are only - of interest to end systems. - -8.2.3 Content Processing - - Assuming the UAS understands any extensions required by the client, - the UAS examines the body of the message, and the header fields that - describe it. If there are any bodies whose type (indicated by the - Content-Type), language (indicated by the Content-Language) or - encoding (indicated by the Content-Encoding) are not understood, and - that body part is not optional (as indicated by the Content- - Disposition header field), the UAS MUST reject the request with a 415 - (Unsupported Media Type) response. The response MUST contain an - Accept header field listing the types of all bodies it understands, - in the event the request contained bodies of types not supported by - the UAS. If the request contained content encodings not understood - by the UAS, the response MUST contain an Accept-Encoding header field - listing the encodings understood by the UAS. If the request - contained content with languages not understood by the UAS, the - response MUST contain an Accept-Language header field indicating the - languages understood by the UAS. Beyond these checks, body handling - depends on the method and type. For further information on the - processing of content-specific header fields, see Section 7.4 as well - as Section 20.11 through 20.15. - - - - - -Rosenberg, et. al. Standards Track [Page 48] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -8.2.4 Applying Extensions - - A UAS that wishes to apply some extension when generating the - response MUST NOT do so unless support for that extension is - indicated in the Supported header field in the request. If the - desired extension is not supported, the server SHOULD rely only on - baseline SIP and any other extensions supported by the client. In - rare circumstances, where the server cannot process the request - without the extension, the server MAY send a 421 (Extension Required) - response. This response indicates that the proper response cannot be - generated without support of a specific extension. The needed - extension(s) MUST be included in a Require header field in the - response. This behavior is NOT RECOMMENDED, as it will generally - break interoperability. - - Any extensions applied to a non-421 response MUST be listed in a - Require header field included in the response. Of course, the server - MUST NOT apply extensions not listed in the Supported header field in - the request. As a result of this, the Require header field in a - response will only ever contain option tags defined in standards- - track RFCs. - -8.2.5 Processing the Request - - Assuming all of the checks in the previous subsections are passed, - the UAS processing becomes method-specific. Section 10 covers the - REGISTER request, Section 11 covers the OPTIONS request, Section 13 - covers the INVITE request, and Section 15 covers the BYE request. - -8.2.6 Generating the Response - - When a UAS wishes to construct a response to a request, it follows - the general procedures detailed in the following subsections. - Additional behaviors specific to the response code in question, which - are not detailed in this section, may also be required. - - Once all procedures associated with the creation of a response have - been completed, the UAS hands the response back to the server - transaction from which it received the request. - -8.2.6.1 Sending a Provisional Response - - One largely non-method-specific guideline for the generation of - responses is that UASs SHOULD NOT issue a provisional response for a - non-INVITE request. Rather, UASs SHOULD generate a final response to - a non-INVITE request as soon as possible. - - - - - -Rosenberg, et. al. Standards Track [Page 49] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - When a 100 (Trying) response is generated, any Timestamp header field - present in the request MUST be copied into this 100 (Trying) - response. If there is a delay in generating the response, the UAS - SHOULD add a delay value into the Timestamp value in the response. - This value MUST contain the difference between the time of sending of - the response and receipt of the request, measured in seconds. - -8.2.6.2 Headers and Tags - - The From field of the response MUST equal the From header field of - the request. The Call-ID header field of the response MUST equal the - Call-ID header field of the request. The CSeq header field of the - response MUST equal the CSeq field of the request. The Via header - field values in the response MUST equal the Via header field values - in the request and MUST maintain the same ordering. - - If a request contained a To tag in the request, the To header field - in the response MUST equal that of the request. However, if the To - header field in the request did not contain a tag, the URI in the To - header field in the response MUST equal the URI in the To header - field; additionally, the UAS MUST add a tag to the To header field in - the response (with the exception of the 100 (Trying) response, in - which a tag MAY be present). This serves to identify the UAS that is - responding, possibly resulting in a component of a dialog ID. The - same tag MUST be used for all responses to that request, both final - and provisional (again excepting the 100 (Trying)). Procedures for - the generation of tags are defined in Section 19.3. - -8.2.7 Stateless UAS Behavior - - A stateless UAS is a UAS that does not maintain transaction state. - It replies to requests normally, but discards any state that would - ordinarily be retained by a UAS after a response has been sent. If a - stateless UAS receives a retransmission of a request, it regenerates - the response and resends it, just as if it were replying to the first - instance of the request. A UAS cannot be stateless unless the request - processing for that method would always result in the same response - if the requests are identical. This rules out stateless registrars, - for example. Stateless UASs do not use a transaction layer; they - receive requests directly from the transport layer and send responses - directly to the transport layer. - - The stateless UAS role is needed primarily to handle unauthenticated - requests for which a challenge response is issued. If - unauthenticated requests were handled statefully, then malicious - floods of unauthenticated requests could create massive amounts of - - - - - -Rosenberg, et. al. Standards Track [Page 50] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - transaction state that might slow or completely halt call processing - in a UAS, effectively creating a denial of service condition; for - more information see Section 26.1.5. - - The most important behaviors of a stateless UAS are the following: - - o A stateless UAS MUST NOT send provisional (1xx) responses. - - o A stateless UAS MUST NOT retransmit responses. - - o A stateless UAS MUST ignore ACK requests. - - o A stateless UAS MUST ignore CANCEL requests. - - o To header tags MUST be generated for responses in a stateless - manner - in a manner that will generate the same tag for the - same request consistently. For information on tag construction - see Section 19.3. - - In all other respects, a stateless UAS behaves in the same manner as - a stateful UAS. A UAS can operate in either a stateful or stateless - mode for each new request. - -8.3 Redirect Servers - - In some architectures it may be desirable to reduce the processing - load on proxy servers that are responsible for routing requests, and - improve signaling path robustness, by relying on redirection. - - Redirection allows servers to push routing information for a request - back in a response to the client, thereby taking themselves out of - the loop of further messaging for this transaction while still aiding - in locating the target of the request. When the originator of the - request receives the redirection, it will send a new request based on - the URI(s) it has received. By propagating URIs from the core of the - network to its edges, redirection allows for considerable network - scalability. - - A redirect server is logically constituted of a server transaction - layer and a transaction user that has access to a location service of - some kind (see Section 10 for more on registrars and location - services). This location service is effectively a database - containing mappings between a single URI and a set of one or more - alternative locations at which the target of that URI can be found. - - A redirect server does not issue any SIP requests of its own. After - receiving a request other than CANCEL, the server either refuses the - request or gathers the list of alternative locations from the - - - -Rosenberg, et. al. Standards Track [Page 51] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - location service and returns a final response of class 3xx. For - well-formed CANCEL requests, it SHOULD return a 2xx response. This - response ends the SIP transaction. The redirect server maintains - transaction state for an entire SIP transaction. It is the - responsibility of clients to detect forwarding loops between redirect - servers. - - When a redirect server returns a 3xx response to a request, it - populates the list of (one or more) alternative locations into the - Contact header field. An "expires" parameter to the Contact header - field values may also be supplied to indicate the lifetime of the - Contact data. - - The Contact header field contains URIs giving the new locations or - user names to try, or may simply specify additional transport - parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily) - response may also give the same location and username that was - targeted by the initial request but specify additional transport - parameters such as a different server or multicast address to try, or - a change of SIP transport from UDP to TCP or vice versa. - - However, redirect servers MUST NOT redirect a request to a URI equal - to the one in the Request-URI; instead, provided that the URI does - not point to itself, the server MAY proxy the request to the - destination URI, or MAY reject it with a 404. - - If a client is using an outbound proxy, and that proxy actually - redirects requests, a potential arises for infinite redirection - loops. - - Note that a Contact header field value MAY also refer to a different - resource than the one originally called. For example, a SIP call - connected to PSTN gateway may need to deliver a special informational - announcement such as "The number you have dialed has been changed." - - A Contact response header field can contain any suitable URI - indicating where the called party can be reached, not limited to SIP - URIs. For example, it could contain URIs for phones, fax, or irc (if - they were defined) or a mailto: (RFC 2368 [32]) URL. Section 26.4.4 - discusses implications and limitations of redirecting a SIPS URI to a - non-SIPS URI. - - The "expires" parameter of a Contact header field value indicates how - long the URI is valid. The value of the parameter is a number - indicating seconds. If this parameter is not provided, the value of - the Expires header field determines how long the URI is valid. - Malformed values SHOULD be treated as equivalent to 3600. - - - - -Rosenberg, et. al. Standards Track [Page 52] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - This provides a modest level of backwards compatibility with RFC - 2543, which allowed absolute times in this header field. If an - absolute time is received, it will be treated as malformed, and - then default to 3600. - - Redirect servers MUST ignore features that are not understood - (including unrecognized header fields, any unknown option tags in - Require, or even method names) and proceed with the redirection of - the request in question. - -9 Canceling a Request - - The previous section has discussed general UA behavior for generating - requests and processing responses for requests of all methods. In - this section, we discuss a general purpose method, called CANCEL. - - The CANCEL request, as the name implies, is used to cancel a previous - request sent by a client. Specifically, it asks the UAS to cease - processing the request and to generate an error response to that - request. CANCEL has no effect on a request to which a UAS has - already given a final response. Because of this, it is most useful - to CANCEL requests to which it can take a server long time to - respond. For this reason, CANCEL is best for INVITE requests, which - can take a long time to generate a response. In that usage, a UAS - that receives a CANCEL request for an INVITE, but has not yet sent a - final response, would "stop ringing", and then respond to the INVITE - with a specific error response (a 487). - - CANCEL requests can be constructed and sent by both proxies and user - agent clients. Section 15 discusses under what conditions a UAC - would CANCEL an INVITE request, and Section 16.10 discusses proxy - usage of CANCEL. - - A stateful proxy responds to a CANCEL, rather than simply forwarding - a response it would receive from a downstream element. For that - reason, CANCEL is referred to as a "hop-by-hop" request, since it is - responded to at each stateful proxy hop. - -9.1 Client Behavior - - A CANCEL request SHOULD NOT be sent to cancel a request other than - INVITE. - - Since requests other than INVITE are responded to immediately, - sending a CANCEL for a non-INVITE request would always create a - race condition. - - - - - -Rosenberg, et. al. Standards Track [Page 53] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The following procedures are used to construct a CANCEL request. The - Request-URI, Call-ID, To, the numeric part of CSeq, and From header - fields in the CANCEL request MUST be identical to those in the - request being cancelled, including tags. A CANCEL constructed by a - client MUST have only a single Via header field value matching the - top Via value in the request being cancelled. Using the same values - for these header fields allows the CANCEL to be matched with the - request it cancels (Section 9.2 indicates how such matching occurs). - However, the method part of the CSeq header field MUST have a value - of CANCEL. This allows it to be identified and processed as a - transaction in its own right (See Section 17). - - If the request being cancelled contains a Route header field, the - CANCEL request MUST include that Route header field's values. - - This is needed so that stateless proxies are able to route CANCEL - requests properly. - - The CANCEL request MUST NOT contain any Require or Proxy-Require - header fields. - - Once the CANCEL is constructed, the client SHOULD check whether it - has received any response (provisional or final) for the request - being cancelled (herein referred to as the "original request"). - - If no provisional response has been received, the CANCEL request MUST - NOT be sent; rather, the client MUST wait for the arrival of a - provisional response before sending the request. If the original - request has generated a final response, the CANCEL SHOULD NOT be - sent, as it is an effective no-op, since CANCEL has no effect on - requests that have already generated a final response. When the - client decides to send the CANCEL, it creates a client transaction - for the CANCEL and passes it the CANCEL request along with the - destination address, port, and transport. The destination address, - port, and transport for the CANCEL MUST be identical to those used to - send the original request. - - If it was allowed to send the CANCEL before receiving a response - for the previous request, the server could receive the CANCEL - before the original request. - - Note that both the transaction corresponding to the original request - and the CANCEL transaction will complete independently. However, a - UAC canceling a request cannot rely on receiving a 487 (Request - Terminated) response for the original request, as an RFC 2543- - compliant UAS will not generate such a response. If there is no - final response for the original request in 64*T1 seconds (T1 is - - - - -Rosenberg, et. al. Standards Track [Page 54] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - defined in Section 17.1.1.1), the client SHOULD then consider the - original transaction cancelled and SHOULD destroy the client - transaction handling the original request. - -9.2 Server Behavior - - The CANCEL method requests that the TU at the server side cancel a - pending transaction. The TU determines the transaction to be - cancelled by taking the CANCEL request, and then assuming that the - request method is anything but CANCEL or ACK and applying the - transaction matching procedures of Section 17.2.3. The matching - transaction is the one to be cancelled. - - The processing of a CANCEL request at a server depends on the type of - server. A stateless proxy will forward it, a stateful proxy might - respond to it and generate some CANCEL requests of its own, and a UAS - will respond to it. See Section 16.10 for proxy treatment of CANCEL. - - A UAS first processes the CANCEL request according to the general UAS - processing described in Section 8.2. However, since CANCEL requests - are hop-by-hop and cannot be resubmitted, they cannot be challenged - by the server in order to get proper credentials in an Authorization - header field. Note also that CANCEL requests do not contain a - Require header field. - - If the UAS did not find a matching transaction for the CANCEL - according to the procedure above, it SHOULD respond to the CANCEL - with a 481 (Call Leg/Transaction Does Not Exist). If the transaction - for the original request still exists, the behavior of the UAS on - receiving a CANCEL request depends on whether it has already sent a - final response for the original request. If it has, the CANCEL - request has no effect on the processing of the original request, no - effect on any session state, and no effect on the responses generated - for the original request. If the UAS has not issued a final response - for the original request, its behavior depends on the method of the - original request. If the original request was an INVITE, the UAS - SHOULD immediately respond to the INVITE with a 487 (Request - Terminated). A CANCEL request has no impact on the processing of - transactions with any other method defined in this specification. - - Regardless of the method of the original request, as long as the - CANCEL matched an existing transaction, the UAS answers the CANCEL - request itself with a 200 (OK) response. This response is - constructed following the procedures described in Section 8.2.6 - noting that the To tag of the response to the CANCEL and the To tag - in the response to the original request SHOULD be the same. The - response to CANCEL is passed to the server transaction for - transmission. - - - -Rosenberg, et. al. Standards Track [Page 55] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -10 Registrations - -10.1 Overview - - SIP offers a discovery capability. If a user wants to initiate a - session with another user, SIP must discover the current host(s) at - which the destination user is reachable. This discovery process is - frequently accomplished by SIP network elements such as proxy servers - and redirect servers which are responsible for receiving a request, - determining where to send it based on knowledge of the location of - the user, and then sending it there. To do this, SIP network - elements consult an abstract service known as a location service, - which provides address bindings for a particular domain. These - address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com, - for example, to one or more URIs that are somehow "closer" to the - desired user, sip:bob@engineering.biloxi.com, for example. - Ultimately, a proxy will consult a location service that maps a - received URI to the user agent(s) at which the desired recipient is - currently residing. - - Registration creates bindings in a location service for a particular - domain that associates an address-of-record URI with one or more - contact addresses. Thus, when a proxy for that domain receives a - request whose Request-URI matches the address-of-record, the proxy - will forward the request to the contact addresses registered to that - address-of-record. Generally, it only makes sense to register an - address-of-record at a domain's location service when requests for - that address-of-record would be routed to that domain. In most - cases, this means that the domain of the registration will need to - match the domain in the URI of the address-of-record. - - There are many ways by which the contents of the location service can - be established. One way is administratively. In the above example, - Bob is known to be a member of the engineering department through - access to a corporate database. However, SIP provides a mechanism - for a UA to create a binding explicitly. This mechanism is known as - registration. - - Registration entails sending a REGISTER request to a special type of - UAS known as a registrar. A registrar acts as the front end to the - location service for a domain, reading and writing mappings based on - the contents of REGISTER requests. This location service is then - typically consulted by a proxy server that is responsible for routing - requests for that domain. - - An illustration of the overall registration process is given in - Figure 2. Note that the registrar and proxy server are logical roles - that can be played by a single device in a network; for purposes of - - - -Rosenberg, et. al. Standards Track [Page 56] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - clarity the two are separated in this illustration. Also note that - UAs may send requests through a proxy server in order to reach a - registrar if the two are separate elements. - - SIP does not mandate a particular mechanism for implementing the - location service. The only requirement is that a registrar for some - domain MUST be able to read and write data to the location service, - and a proxy or a redirect server for that domain MUST be capable of - reading that same data. A registrar MAY be co-located with a - particular SIP proxy server for the same domain. - -10.2 Constructing the REGISTER Request - - REGISTER requests add, remove, and query bindings. A REGISTER - request can add a new binding between an address-of-record and one or - more contact addresses. Registration on behalf of a particular - address-of-record can be performed by a suitably authorized third - party. A client can also remove previous bindings or query to - determine which bindings are currently in place for an address-of- - record. - - Except as noted, the construction of the REGISTER request and the - behavior of clients sending a REGISTER request is identical to the - general UAC behavior described in Section 8.1 and Section 17.1. - - A REGISTER request does not establish a dialog. A UAC MAY include a - Route header field in a REGISTER request based on a pre-existing - route set as described in Section 8.1. The Record-Route header field - has no meaning in REGISTER requests or responses, and MUST be ignored - if present. In particular, the UAC MUST NOT create a new route set - based on the presence or absence of a Record-Route header field in - any response to a REGISTER request. - - The following header fields, except Contact, MUST be included in a - REGISTER request. A Contact header field MAY be included: - - Request-URI: The Request-URI names the domain of the location - service for which the registration is meant (for example, - "sip:chicago.com"). The "userinfo" and "@" components of the - SIP URI MUST NOT be present. - - To: The To header field contains the address of record whose - registration is to be created, queried, or modified. The To - header field and the Request-URI field typically differ, as - the former contains a user name. This address-of-record MUST - be a SIP URI or SIPS URI. - - - - - -Rosenberg, et. al. Standards Track [Page 57] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - From: The From header field contains the address-of-record of the - person responsible for the registration. The value is the - same as the To header field unless the request is a third- - party registration. - - Call-ID: All registrations from a UAC SHOULD use the same Call-ID - header field value for registrations sent to a particular - registrar. - - If the same client were to use different Call-ID values, a - registrar could not detect whether a delayed REGISTER request - might have arrived out of order. - - CSeq: The CSeq value guarantees proper ordering of REGISTER - requests. A UA MUST increment the CSeq value by one for each - REGISTER request with the same Call-ID. - - Contact: REGISTER requests MAY contain a Contact header field with - zero or more values containing address bindings. - - UAs MUST NOT send a new registration (that is, containing new Contact - header field values, as opposed to a retransmission) until they have - received a final response from the registrar for the previous one or - the previous REGISTER request has timed out. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 58] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - bob - +----+ - | UA | - | | - +----+ - | - |3)INVITE - | carol@chicago.com - chicago.com +--------+ V - +---------+ 2)Store|Location|4)Query +-----+ - |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com - +---------+ +--------+=======>+-----+ - A 5)Resp | - | | - | | - 1)REGISTER| | - | | - +----+ | - | UA |<-------------------------------+ - cube2214a| | 6)INVITE - +----+ carol@cube2214a.chicago.com - carol - - Figure 2: REGISTER example - - The following Contact header parameters have a special meaning in - REGISTER requests: - - action: The "action" parameter from RFC 2543 has been deprecated. - UACs SHOULD NOT use the "action" parameter. - - expires: The "expires" parameter indicates how long the UA would - like the binding to be valid. The value is a number - indicating seconds. If this parameter is not provided, the - value of the Expires header field is used instead. - Implementations MAY treat values larger than 2**32-1 - (4294967295 seconds or 136 years) as equivalent to 2**32-1. - Malformed values SHOULD be treated as equivalent to 3600. - -10.2.1 Adding Bindings - - The REGISTER request sent to a registrar includes the contact - address(es) to which SIP requests for the address-of-record should be - forwarded. The address-of-record is included in the To header field - of the REGISTER request. - - - - - - -Rosenberg, et. al. Standards Track [Page 59] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The Contact header field values of the request typically consist of - SIP or SIPS URIs that identify particular SIP endpoints (for example, - "sip:carol@cube2214a.chicago.com"), but they MAY use any URI scheme. - A SIP UA can choose to register telephone numbers (with the tel URL, - RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32]) - as Contacts for an address-of-record, for example. - - For example, Carol, with address-of-record "sip:carol@chicago.com", - would register with the SIP registrar of the domain chicago.com. Her - registrations would then be used by a proxy server in the chicago.com - domain to route requests for Carol's address-of-record to her SIP - endpoint. - - Once a client has established bindings at a registrar, it MAY send - subsequent registrations containing new bindings or modifications to - existing bindings as necessary. The 2xx response to the REGISTER - request will contain, in a Contact header field, a complete list of - bindings that have been registered for this address-of-record at this - registrar. - - If the address-of-record in the To header field of a REGISTER request - is a SIPS URI, then any Contact header field values in the request - SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs - under a SIPS address-of-record when the security of the resource - represented by the contact address is guaranteed by other means. - This may be applicable to URIs that invoke protocols other than SIP, - or SIP devices secured by protocols other than TLS. - - Registrations do not need to update all bindings. Typically, a UA - only updates its own contact addresses. - -10.2.1.1 Setting the Expiration Interval of Contact Addresses - - When a client sends a REGISTER request, it MAY suggest an expiration - interval that indicates how long the client would like the - registration to be valid. (As described in Section 10.3, the - registrar selects the actual time interval based on its local - policy.) - - There are two ways in which a client can suggest an expiration - interval for a binding: through an Expires header field or an - "expires" Contact header parameter. The latter allows expiration - intervals to be suggested on a per-binding basis when more than one - binding is given in a single REGISTER request, whereas the former - suggests an expiration interval for all Contact header field values - that do not contain the "expires" parameter. - - - - - -Rosenberg, et. al. Standards Track [Page 60] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - If neither mechanism for expressing a suggested expiration time is - present in a REGISTER, the client is indicating its desire for the - server to choose. - -10.2.1.2 Preferences among Contact Addresses - - If more than one Contact is sent in a REGISTER request, the - registering UA intends to associate all of the URIs in these Contact - header field values with the address-of-record present in the To - field. This list can be prioritized with the "q" parameter in the - Contact header field. The "q" parameter indicates a relative - preference for the particular Contact header field value compared to - other bindings for this address-of-record. Section 16.6 describes - how a proxy server uses this preference indication. - -10.2.2 Removing Bindings - - Registrations are soft state and expire unless refreshed, but can - also be explicitly removed. A client can attempt to influence the - expiration interval selected by the registrar as described in Section - 10.2.1. A UA requests the immediate removal of a binding by - specifying an expiration interval of "0" for that contact address in - a REGISTER request. UAs SHOULD support this mechanism so that - bindings can be removed before their expiration interval has passed. - - The REGISTER-specific Contact header field value of "*" applies to - all registrations, but it MUST NOT be used unless the Expires header - field is present with a value of "0". - - Use of the "*" Contact header field value allows a registering UA - to remove all bindings associated with an address-of-record - without knowing their precise values. - -10.2.3 Fetching Bindings - - A success response to any REGISTER request contains the complete list - of existing bindings, regardless of whether the request contained a - Contact header field. If no Contact header field is present in a - REGISTER request, the list of bindings is left unchanged. - -10.2.4 Refreshing Bindings - - Each UA is responsible for refreshing the bindings that it has - previously established. A UA SHOULD NOT refresh bindings set up by - other UAs. - - - - - - -Rosenberg, et. al. Standards Track [Page 61] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The 200 (OK) response from the registrar contains a list of Contact - fields enumerating all current bindings. The UA compares each - contact address to see if it created the contact address, using - comparison rules in Section 19.1.4. If so, it updates the expiration - time interval according to the expires parameter or, if absent, the - Expires field value. The UA then issues a REGISTER request for each - of its bindings before the expiration interval has elapsed. It MAY - combine several updates into one REGISTER request. - - A UA SHOULD use the same Call-ID for all registrations during a - single boot cycle. Registration refreshes SHOULD be sent to the same - network address as the original registration, unless redirected. - -10.2.5 Setting the Internal Clock - - If the response for a REGISTER request contains a Date header field, - the client MAY use this header field to learn the current time in - order to set any internal clocks. - -10.2.6 Discovering a Registrar - - UAs can use three ways to determine the address to which to send - registrations: by configuration, using the address-of-record, and - multicast. A UA can be configured, in ways beyond the scope of this - specification, with a registrar address. If there is no configured - registrar address, the UA SHOULD use the host part of the address- - of-record as the Request-URI and address the request there, using the - normal SIP server location mechanisms [4]. For example, the UA for - the user "sip:carol@chicago.com" addresses the REGISTER request to - "sip:chicago.com". - - Finally, a UA can be configured to use multicast. Multicast - registrations are addressed to the well-known "all SIP servers" - multicast address "sip.mcast.net" (224.0.1.75 for IPv4). No well- - known IPv6 multicast address has been allocated; such an allocation - will be documented separately when needed. SIP UAs MAY listen to - that address and use it to become aware of the location of other - local users (see [33]); however, they do not respond to the request. - - Multicast registration may be inappropriate in some environments, - for example, if multiple businesses share the same local area - network. - -10.2.7 Transmitting a Request - - Once the REGISTER method has been constructed, and the destination of - the message identified, UACs follow the procedures described in - Section 8.1.2 to hand off the REGISTER to the transaction layer. - - - -Rosenberg, et. al. Standards Track [Page 62] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - If the transaction layer returns a timeout error because the REGISTER - yielded no response, the UAC SHOULD NOT immediately re-attempt a - registration to the same registrar. - - An immediate re-attempt is likely to also timeout. Waiting some - reasonable time interval for the conditions causing the timeout to - be corrected reduces unnecessary load on the network. No specific - interval is mandated. - -10.2.8 Error Responses - - If a UA receives a 423 (Interval Too Brief) response, it MAY retry - the registration after making the expiration interval of all contact - addresses in the REGISTER request equal to or greater than the - expiration interval within the Min-Expires header field of the 423 - (Interval Too Brief) response. - -10.3 Processing REGISTER Requests - - A registrar is a UAS that responds to REGISTER requests and maintains - a list of bindings that are accessible to proxy servers and redirect - servers within its administrative domain. A registrar handles - requests according to Section 8.2 and Section 17.2, but it accepts - only REGISTER requests. A registrar MUST not generate 6xx responses. - - A registrar MAY redirect REGISTER requests as appropriate. One - common usage would be for a registrar listening on a multicast - interface to redirect multicast REGISTER requests to its own unicast - interface with a 302 (Moved Temporarily) response. - - Registrars MUST ignore the Record-Route header field if it is - included in a REGISTER request. Registrars MUST NOT include a - Record-Route header field in any response to a REGISTER request. - - A registrar might receive a request that traversed a proxy which - treats REGISTER as an unknown request and which added a Record- - Route header field value. - - A registrar has to know (for example, through configuration) the set - of domain(s) for which it maintains bindings. REGISTER requests MUST - be processed by a registrar in the order that they are received. - REGISTER requests MUST also be processed atomically, meaning that a - particular REGISTER request is either processed completely or not at - all. Each REGISTER message MUST be processed independently of any - other registration or binding changes. - - - - - - -Rosenberg, et. al. Standards Track [Page 63] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - When receiving a REGISTER request, a registrar follows these steps: - - 1. The registrar inspects the Request-URI to determine whether it - has access to bindings for the domain identified in the - Request-URI. If not, and if the server also acts as a proxy - server, the server SHOULD forward the request to the addressed - domain, following the general behavior for proxying messages - described in Section 16. - - 2. To guarantee that the registrar supports any necessary - extensions, the registrar MUST process the Require header field - values as described for UASs in Section 8.2.2. - - 3. A registrar SHOULD authenticate the UAC. Mechanisms for the - authentication of SIP user agents are described in Section 22. - Registration behavior in no way overrides the generic - authentication framework for SIP. If no authentication - mechanism is available, the registrar MAY take the From address - as the asserted identity of the originator of the request. - - 4. The registrar SHOULD determine if the authenticated user is - authorized to modify registrations for this address-of-record. - For example, a registrar might consult an authorization - database that maps user names to a list of addresses-of-record - for which that user has authorization to modify bindings. If - the authenticated user is not authorized to modify bindings, - the registrar MUST return a 403 (Forbidden) and skip the - remaining steps. - - In architectures that support third-party registration, one - entity may be responsible for updating the registrations - associated with multiple addresses-of-record. - - 5. The registrar extracts the address-of-record from the To header - field of the request. If the address-of-record is not valid - for the domain in the Request-URI, the registrar MUST send a - 404 (Not Found) response and skip the remaining steps. The URI - MUST then be converted to a canonical form. To do that, all - URI parameters MUST be removed (including the user-param), and - any escaped characters MUST be converted to their unescaped - form. The result serves as an index into the list of bindings. - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 64] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - 6. The registrar checks whether the request contains the Contact - header field. If not, it skips to the last step. If the - Contact header field is present, the registrar checks if there - is one Contact field value that contains the special value "*" - and an Expires field. If the request has additional Contact - fields or an expiration time other than zero, the request is - invalid, and the server MUST return a 400 (Invalid Request) and - skip the remaining steps. If not, the registrar checks whether - the Call-ID agrees with the value stored for each binding. If - not, it MUST remove the binding. If it does agree, it MUST - remove the binding only if the CSeq in the request is higher - than the value stored for that binding. Otherwise, the update - MUST be aborted and the request fails. - - 7. The registrar now processes each contact address in the Contact - header field in turn. For each address, it determines the - expiration interval as follows: - - - If the field value has an "expires" parameter, that value - MUST be taken as the requested expiration. - - - If there is no such parameter, but the request has an - Expires header field, that value MUST be taken as the - requested expiration. - - - If there is neither, a locally-configured default value MUST - be taken as the requested expiration. - - The registrar MAY choose an expiration less than the requested - expiration interval. If and only if the requested expiration - interval is greater than zero AND smaller than one hour AND - less than a registrar-configured minimum, the registrar MAY - reject the registration with a response of 423 (Interval Too - Brief). This response MUST contain a Min-Expires header field - that states the minimum expiration interval the registrar is - willing to honor. It then skips the remaining steps. - - Allowing the registrar to set the registration interval - protects it against excessively frequent registration refreshes - while limiting the state that it needs to maintain and - decreasing the likelihood of registrations going stale. The - expiration interval of a registration is frequently used in the - creation of services. An example is a follow-me service, where - the user may only be available at a terminal for a brief - period. Therefore, registrars should accept brief - registrations; a request should only be rejected if the - interval is so short that the refreshes would degrade registrar - performance. - - - -Rosenberg, et. al. Standards Track [Page 65] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - For each address, the registrar then searches the list of - current bindings using the URI comparison rules. If the - binding does not exist, it is tentatively added. If the - binding does exist, the registrar checks the Call-ID value. If - the Call-ID value in the existing binding differs from the - Call-ID value in the request, the binding MUST be removed if - the expiration time is zero and updated otherwise. If they are - the same, the registrar compares the CSeq value. If the value - is higher than that of the existing binding, it MUST update or - remove the binding as above. If not, the update MUST be - aborted and the request fails. - - This algorithm ensures that out-of-order requests from the same - UA are ignored. - - Each binding record records the Call-ID and CSeq values from - the request. - - The binding updates MUST be committed (that is, made visible to - the proxy or redirect server) if and only if all binding - updates and additions succeed. If any one of them fails (for - example, because the back-end database commit failed), the - request MUST fail with a 500 (Server Error) response and all - tentative binding updates MUST be removed. - - 8. The registrar returns a 200 (OK) response. The response MUST - contain Contact header field values enumerating all current - bindings. Each Contact value MUST feature an "expires" - parameter indicating its expiration interval chosen by the - registrar. The response SHOULD include a Date header field. - -11 Querying for Capabilities - - The SIP method OPTIONS allows a UA to query another UA or a proxy - server as to its capabilities. This allows a client to discover - information about the supported methods, content types, extensions, - codecs, etc. without "ringing" the other party. For example, before - a client inserts a Require header field into an INVITE listing an - option that it is not certain the destination UAS supports, the - client can query the destination UAS with an OPTIONS to see if this - option is returned in a Supported header field. All UAs MUST support - the OPTIONS method. - - The target of the OPTIONS request is identified by the Request-URI, - which could identify another UA or a SIP server. If the OPTIONS is - addressed to a proxy server, the Request-URI is set without a user - part, similar to the way a Request-URI is set for a REGISTER request. - - - - -Rosenberg, et. al. Standards Track [Page 66] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Alternatively, a server receiving an OPTIONS request with a Max- - Forwards header field value of 0 MAY respond to the request - regardless of the Request-URI. - - This behavior is common with HTTP/1.1. This behavior can be used - as a "traceroute" functionality to check the capabilities of - individual hop servers by sending a series of OPTIONS requests - with incremented Max-Forwards values. - - As is the case for general UA behavior, the transaction layer can - return a timeout error if the OPTIONS yields no response. This may - indicate that the target is unreachable and hence unavailable. - - An OPTIONS request MAY be sent as part of an established dialog to - query the peer on capabilities that may be utilized later in the - dialog. - -11.1 Construction of OPTIONS Request - - An OPTIONS request is constructed using the standard rules for a SIP - request as discussed in Section 8.1.1. - - A Contact header field MAY be present in an OPTIONS. - - An Accept header field SHOULD be included to indicate the type of - message body the UAC wishes to receive in the response. Typically, - this is set to a format that is used to describe the media - capabilities of a UA, such as SDP (application/sdp). - - The response to an OPTIONS request is assumed to be scoped to the - Request-URI in the original request. However, only when an OPTIONS - is sent as part of an established dialog is it guaranteed that future - requests will be received by the server that generated the OPTIONS - response. - - Example OPTIONS request: - - OPTIONS sip:carol@chicago.com SIP/2.0 - Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 - Max-Forwards: 70 - To: - From: Alice ;tag=1928301774 - Call-ID: a84b4c76e66710 - CSeq: 63104 OPTIONS - Contact: - Accept: application/sdp - Content-Length: 0 - - - - -Rosenberg, et. al. Standards Track [Page 67] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -11.2 Processing of OPTIONS Request - - The response to an OPTIONS is constructed using the standard rules - for a SIP response as discussed in Section 8.2.6. The response code - chosen MUST be the same that would have been chosen had the request - been an INVITE. That is, a 200 (OK) would be returned if the UAS is - ready to accept a call, a 486 (Busy Here) would be returned if the - UAS is busy, etc. This allows an OPTIONS request to be used to - determine the basic state of a UAS, which can be an indication of - whether the UAS will accept an INVITE request. - - An OPTIONS request received within a dialog generates a 200 (OK) - response that is identical to one constructed outside a dialog and - does not have any impact on the dialog. - - This use of OPTIONS has limitations due to the differences in proxy - handling of OPTIONS and INVITE requests. While a forked INVITE can - result in multiple 200 (OK) responses being returned, a forked - OPTIONS will only result in a single 200 (OK) response, since it is - treated by proxies using the non-INVITE handling. See Section 16.7 - for the normative details. - - If the response to an OPTIONS is generated by a proxy server, the - proxy returns a 200 (OK), listing the capabilities of the server. - The response does not contain a message body. - - Allow, Accept, Accept-Encoding, Accept-Language, and Supported header - fields SHOULD be present in a 200 (OK) response to an OPTIONS - request. If the response is generated by a proxy, the Allow header - field SHOULD be omitted as it is ambiguous since a proxy is method - agnostic. Contact header fields MAY be present in a 200 (OK) - response and have the same semantics as in a 3xx response. That is, - they may list a set of alternative names and methods of reaching the - user. A Warning header field MAY be present. - - A message body MAY be sent, the type of which is determined by the - Accept header field in the OPTIONS request (application/sdp is the - default if the Accept header field is not present). If the types - include one that can describe media capabilities, the UAS SHOULD - include a body in the response for that purpose. Details on the - construction of such a body in the case of application/sdp are - described in [13]. - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 68] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Example OPTIONS response generated by a UAS (corresponding to the - request in Section 11.1): - - SIP/2.0 200 OK - Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 - ;received=192.0.2.4 - To: ;tag=93810874 - From: Alice ;tag=1928301774 - Call-ID: a84b4c76e66710 - CSeq: 63104 OPTIONS - Contact: - Contact: - Allow: INVITE, ACK, CANCEL, OPTIONS, BYE - Accept: application/sdp - Accept-Encoding: gzip - Accept-Language: en - Supported: foo - Content-Type: application/sdp - Content-Length: 274 - - (SDP not shown) - -12 Dialogs - - A key concept for a user agent is that of a dialog. A dialog - represents a peer-to-peer SIP relationship between two user agents - that persists for some time. The dialog facilitates sequencing of - messages between the user agents and proper routing of requests - between both of them. The dialog represents a context in which to - interpret SIP messages. Section 8 discussed method independent UA - processing for requests and responses outside of a dialog. This - section discusses how those requests and responses are used to - construct a dialog, and then how subsequent requests and responses - are sent within a dialog. - - A dialog is identified at each UA with a dialog ID, which consists of - a Call-ID value, a local tag and a remote tag. The dialog ID at each - UA involved in the dialog is not the same. Specifically, the local - tag at one UA is identical to the remote tag at the peer UA. The - tags are opaque tokens that facilitate the generation of unique - dialog IDs. - - A dialog ID is also associated with all responses and with any - request that contains a tag in the To field. The rules for computing - the dialog ID of a message depend on whether the SIP element is a UAC - or UAS. For a UAC, the Call-ID value of the dialog ID is set to the - Call-ID of the message, the remote tag is set to the tag in the To - field of the message, and the local tag is set to the tag in the From - - - -Rosenberg, et. al. Standards Track [Page 69] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - field of the message (these rules apply to both requests and - responses). As one would expect for a UAS, the Call-ID value of the - dialog ID is set to the Call-ID of the message, the remote tag is set - to the tag in the From field of the message, and the local tag is set - to the tag in the To field of the message. - - A dialog contains certain pieces of state needed for further message - transmissions within the dialog. This state consists of the dialog - ID, a local sequence number (used to order requests from the UA to - its peer), a remote sequence number (used to order requests from its - peer to the UA), a local URI, a remote URI, remote target, a boolean - flag called "secure", and a route set, which is an ordered list of - URIs. The route set is the list of servers that need to be traversed - to send a request to the peer. A dialog can also be in the "early" - state, which occurs when it is created with a provisional response, - and then transition to the "confirmed" state when a 2xx final - response arrives. For other responses, or if no response arrives at - all on that dialog, the early dialog terminates. - -12.1 Creation of a Dialog - - Dialogs are created through the generation of non-failure responses - to requests with specific methods. Within this specification, only - 2xx and 101-199 responses with a To tag, where the request was - INVITE, will establish a dialog. A dialog established by a non-final - response to a request is in the "early" state and it is called an - early dialog. Extensions MAY define other means for creating - dialogs. Section 13 gives more details that are specific to the - INVITE method. Here, we describe the process for creation of dialog - state that is not dependent on the method. - - UAs MUST assign values to the dialog ID components as described - below. - -12.1.1 UAS behavior - - When a UAS responds to a request with a response that establishes a - dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route - header field values from the request into the response (including the - URIs, URI parameters, and any Record-Route header field parameters, - whether they are known or unknown to the UAS) and MUST maintain the - order of those values. The UAS MUST add a Contact header field to - the response. The Contact header field contains an address where the - UAS would like to be contacted for subsequent requests in the dialog - (which includes the ACK for a 2xx response in the case of an INVITE). - Generally, the host portion of this URI is the IP address or FQDN of - the host. The URI provided in the Contact header field MUST be a SIP - or SIPS URI. If the request that initiated the dialog contained a - - - -Rosenberg, et. al. Standards Track [Page 70] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - SIPS URI in the Request-URI or in the top Record-Route header field - value, if there was any, or the Contact header field if there was no - Record-Route header field, the Contact header field in the response - MUST be a SIPS URI. The URI SHOULD have global scope (that is, the - same URI can be used in messages outside this dialog). The same way, - the scope of the URI in the Contact header field of the INVITE is not - limited to this dialog either. It can therefore be used in messages - to the UAC even outside this dialog. - - The UAS then constructs the state of the dialog. This state MUST be - maintained for the duration of the dialog. - - If the request arrived over TLS, and the Request-URI contained a SIPS - URI, the "secure" flag is set to TRUE. - - The route set MUST be set to the list of URIs in the Record-Route - header field from the request, taken in order and preserving all URI - parameters. If no Record-Route header field is present in the - request, the route set MUST be set to the empty set. This route set, - even if empty, overrides any pre-existing route set for future - requests in this dialog. The remote target MUST be set to the URI - from the Contact header field of the request. - - The remote sequence number MUST be set to the value of the sequence - number in the CSeq header field of the request. The local sequence - number MUST be empty. The call identifier component of the dialog ID - MUST be set to the value of the Call-ID in the request. The local - tag component of the dialog ID MUST be set to the tag in the To field - in the response to the request (which always includes a tag), and the - remote tag component of the dialog ID MUST be set to the tag from the - From field in the request. A UAS MUST be prepared to receive a - request without a tag in the From field, in which case the tag is - considered to have a value of null. - - This is to maintain backwards compatibility with RFC 2543, which - did not mandate From tags. - - The remote URI MUST be set to the URI in the From field, and the - local URI MUST be set to the URI in the To field. - -12.1.2 UAC Behavior - - When a UAC sends a request that can establish a dialog (such as an - INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e., - the same SIP URI can be used in messages outside this dialog) in the - Contact header field of the request. If the request has a Request- - URI or a topmost Route header field value with a SIPS URI, the - Contact header field MUST contain a SIPS URI. - - - -Rosenberg, et. al. Standards Track [Page 71] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - When a UAC receives a response that establishes a dialog, it - constructs the state of the dialog. This state MUST be maintained - for the duration of the dialog. - - If the request was sent over TLS, and the Request-URI contained a - SIPS URI, the "secure" flag is set to TRUE. - - The route set MUST be set to the list of URIs in the Record-Route - header field from the response, taken in reverse order and preserving - all URI parameters. If no Record-Route header field is present in - the response, the route set MUST be set to the empty set. This route - set, even if empty, overrides any pre-existing route set for future - requests in this dialog. The remote target MUST be set to the URI - from the Contact header field of the response. - - The local sequence number MUST be set to the value of the sequence - number in the CSeq header field of the request. The remote sequence - number MUST be empty (it is established when the remote UA sends a - request within the dialog). The call identifier component of the - dialog ID MUST be set to the value of the Call-ID in the request. - The local tag component of the dialog ID MUST be set to the tag in - the From field in the request, and the remote tag component of the - dialog ID MUST be set to the tag in the To field of the response. A - UAC MUST be prepared to receive a response without a tag in the To - field, in which case the tag is considered to have a value of null. - - This is to maintain backwards compatibility with RFC 2543, which - did not mandate To tags. - - The remote URI MUST be set to the URI in the To field, and the local - URI MUST be set to the URI in the From field. - -12.2 Requests within a Dialog - - Once a dialog has been established between two UAs, either of them - MAY initiate new transactions as needed within the dialog. The UA - sending the request will take the UAC role for the transaction. The - UA receiving the request will take the UAS role. Note that these may - be different roles than the UAs held during the transaction that - established the dialog. - - Requests within a dialog MAY contain Record-Route and Contact header - fields. However, these requests do not cause the dialog's route set - to be modified, although they may modify the remote target URI. - Specifically, requests that are not target refresh requests do not - modify the dialog's remote target URI, and requests that are target - refresh requests do. For dialogs that have been established with an - - - - -Rosenberg, et. al. Standards Track [Page 72] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - INVITE, the only target refresh request defined is re-INVITE (see - Section 14). Other extensions may define different target refresh - requests for dialogs established in other ways. - - Note that an ACK is NOT a target refresh request. - - Target refresh requests only update the dialog's remote target URI, - and not the route set formed from the Record-Route. Updating the - latter would introduce severe backwards compatibility problems with - RFC 2543-compliant systems. - -12.2.1 UAC Behavior - -12.2.1.1 Generating the Request - - A request within a dialog is constructed by using many of the - components of the state stored as part of the dialog. - - The URI in the To field of the request MUST be set to the remote URI - from the dialog state. The tag in the To header field of the request - MUST be set to the remote tag of the dialog ID. The From URI of the - request MUST be set to the local URI from the dialog state. The tag - in the From header field of the request MUST be set to the local tag - of the dialog ID. If the value of the remote or local tags is null, - the tag parameter MUST be omitted from the To or From header fields, - respectively. - - Usage of the URI from the To and From fields in the original - request within subsequent requests is done for backwards - compatibility with RFC 2543, which used the URI for dialog - identification. In this specification, only the tags are used for - dialog identification. It is expected that mandatory reflection - of the original To and From URI in mid-dialog requests will be - deprecated in a subsequent revision of this specification. - - The Call-ID of the request MUST be set to the Call-ID of the dialog. - Requests within a dialog MUST contain strictly monotonically - increasing and contiguous CSeq sequence numbers (increasing-by-one) - in each direction (excepting ACK and CANCEL of course, whose numbers - equal the requests being acknowledged or cancelled). Therefore, if - the local sequence number is not empty, the value of the local - sequence number MUST be incremented by one, and this value MUST be - placed into the CSeq header field. If the local sequence number is - empty, an initial value MUST be chosen using the guidelines of - Section 8.1.1.5. The method field in the CSeq header field value - MUST match the method of the request. - - - - - -Rosenberg, et. al. Standards Track [Page 73] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - With a length of 32 bits, a client could generate, within a single - call, one request a second for about 136 years before needing to - wrap around. The initial value of the sequence number is chosen - so that subsequent requests within the same call will not wrap - around. A non-zero initial value allows clients to use a time- - based initial sequence number. A client could, for example, - choose the 31 most significant bits of a 32-bit second clock as an - initial sequence number. - - The UAC uses the remote target and route set to build the Request-URI - and Route header field of the request. - - If the route set is empty, the UAC MUST place the remote target URI - into the Request-URI. The UAC MUST NOT add a Route header field to - the request. - - If the route set is not empty, and the first URI in the route set - contains the lr parameter (see Section 19.1.1), the UAC MUST place - the remote target URI into the Request-URI and MUST include a Route - header field containing the route set values in order, including all - parameters. - - If the route set is not empty, and its first URI does not contain the - lr parameter, the UAC MUST place the first URI from the route set - into the Request-URI, stripping any parameters that are not allowed - in a Request-URI. The UAC MUST add a Route header field containing - the remainder of the route set values in order, including all - parameters. The UAC MUST then place the remote target URI into the - Route header field as the last value. - - For example, if the remote target is sip:user@remoteua and the route - set contains: - - ,,, - - The request will be formed with the following Request-URI and Route - header field: - - METHOD sip:proxy1 - Route: ,,, - - If the first URI of the route set does not contain the lr - parameter, the proxy indicated does not understand the routing - mechanisms described in this document and will act as specified in - RFC 2543, replacing the Request-URI with the first Route header - field value it receives while forwarding the message. Placing the - Request-URI at the end of the Route header field preserves the - - - - -Rosenberg, et. al. Standards Track [Page 74] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - information in that Request-URI across the strict router (it will - be returned to the Request-URI when the request reaches a loose- - router). - - A UAC SHOULD include a Contact header field in any target refresh - requests within a dialog, and unless there is a need to change it, - the URI SHOULD be the same as used in previous requests within the - dialog. If the "secure" flag is true, that URI MUST be a SIPS URI. - As discussed in Section 12.2.2, a Contact header field in a target - refresh request updates the remote target URI. This allows a UA to - provide a new contact address, should its address change during the - duration of the dialog. - - However, requests that are not target refresh requests do not affect - the remote target URI for the dialog. - - The rest of the request is formed as described in Section 8.1.1. - - Once the request has been constructed, the address of the server is - computed and the request is sent, using the same procedures for - requests outside of a dialog (Section 8.1.2). - - The procedures in Section 8.1.2 will normally result in the - request being sent to the address indicated by the topmost Route - header field value or the Request-URI if no Route header field is - present. Subject to certain restrictions, they allow the request - to be sent to an alternate address (such as a default outbound - proxy not represented in the route set). - -12.2.1.2 Processing the Responses - - The UAC will receive responses to the request from the transaction - layer. If the client transaction returns a timeout, this is treated - as a 408 (Request Timeout) response. - - The behavior of a UAC that receives a 3xx response for a request sent - within a dialog is the same as if the request had been sent outside a - dialog. This behavior is described in Section 8.1.3.4. - - Note, however, that when the UAC tries alternative locations, it - still uses the route set for the dialog to build the Route header - of the request. - - When a UAC receives a 2xx response to a target refresh request, it - MUST replace the dialog's remote target URI with the URI from the - Contact header field in that response, if present. - - - - - -Rosenberg, et. al. Standards Track [Page 75] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - If the response for a request within a dialog is a 481 - (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC - SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if - no response at all is received for the request (the client - transaction would inform the TU about the timeout.) - - For INVITE initiated dialogs, terminating the dialog consists of - sending a BYE. - -12.2.2 UAS Behavior - - Requests sent within a dialog, as any other requests, are atomic. If - a particular request is accepted by the UAS, all the state changes - associated with it are performed. If the request is rejected, none - of the state changes are performed. - - Note that some requests, such as INVITEs, affect several pieces of - state. - - The UAS will receive the request from the transaction layer. If the - request has a tag in the To header field, the UAS core computes the - dialog identifier corresponding to the request and compares it with - existing dialogs. If there is a match, this is a mid-dialog request. - In that case, the UAS first applies the same processing rules for - requests outside of a dialog, discussed in Section 8.2. - - If the request has a tag in the To header field, but the dialog - identifier does not match any existing dialogs, the UAS may have - crashed and restarted, or it may have received a request for a - different (possibly failed) UAS (the UASs can construct the To tags - so that a UAS can identify that the tag was for a UAS for which it is - providing recovery). Another possibility is that the incoming - request has been simply misrouted. Based on the To tag, the UAS MAY - either accept or reject the request. Accepting the request for - acceptable To tags provides robustness, so that dialogs can persist - even through crashes. UAs wishing to support this capability must - take into consideration some issues such as choosing monotonically - increasing CSeq sequence numbers even across reboots, reconstructing - the route set, and accepting out-of-range RTP timestamps and sequence - numbers. - - If the UAS wishes to reject the request because it does not wish to - recreate the dialog, it MUST respond to the request with a 481 - (Call/Transaction Does Not Exist) status code and pass that to the - server transaction. - - - - - - -Rosenberg, et. al. Standards Track [Page 76] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Requests that do not change in any way the state of a dialog may be - received within a dialog (for example, an OPTIONS request). They are - processed as if they had been received outside the dialog. - - If the remote sequence number is empty, it MUST be set to the value - of the sequence number in the CSeq header field value in the request. - If the remote sequence number was not empty, but the sequence number - of the request is lower than the remote sequence number, the request - is out of order and MUST be rejected with a 500 (Server Internal - Error) response. If the remote sequence number was not empty, and - the sequence number of the request is greater than the remote - sequence number, the request is in order. It is possible for the - CSeq sequence number to be higher than the remote sequence number by - more than one. This is not an error condition, and a UAS SHOULD be - prepared to receive and process requests with CSeq values more than - one higher than the previous received request. The UAS MUST then set - the remote sequence number to the value of the sequence number in the - CSeq header field value in the request. - - If a proxy challenges a request generated by the UAC, the UAC has - to resubmit the request with credentials. The resubmitted request - will have a new CSeq number. The UAS will never see the first - request, and thus, it will notice a gap in the CSeq number space. - Such a gap does not represent any error condition. - - When a UAS receives a target refresh request, it MUST replace the - dialog's remote target URI with the URI from the Contact header field - in that request, if present. - -12.3 Termination of a Dialog - - Independent of the method, if a request outside of a dialog generates - a non-2xx final response, any early dialogs created through - provisional responses to that request are terminated. The mechanism - for terminating confirmed dialogs is method specific. In this - specification, the BYE method terminates a session and the dialog - associated with it. See Section 15 for details. - -13 Initiating a Session - -13.1 Overview - - When a user agent client desires to initiate a session (for example, - audio, video, or a game), it formulates an INVITE request. The - INVITE request asks a server to establish a session. This request - may be forwarded by proxies, eventually arriving at one or more UAS - that can potentially accept the invitation. These UASs will - frequently need to query the user about whether to accept the - - - -Rosenberg, et. al. Standards Track [Page 77] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - invitation. After some time, those UASs can accept the invitation - (meaning the session is to be established) by sending a 2xx response. - If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is - sent, depending on the reason for the rejection. Before sending a - final response, the UAS can also send provisional responses (1xx) to - advise the UAC of progress in contacting the called user. - - After possibly receiving one or more provisional responses, the UAC - will get one or more 2xx responses or one non-2xx final response. - Because of the protracted amount of time it can take to receive final - responses to INVITE, the reliability mechanisms for INVITE - transactions differ from those of other requests (like OPTIONS). - Once it receives a final response, the UAC needs to send an ACK for - every final response it receives. The procedure for sending this ACK - depends on the type of response. For final responses between 300 and - 699, the ACK processing is done in the transaction layer and follows - one set of rules (See Section 17). For 2xx responses, the ACK is - generated by the UAC core. - - A 2xx response to an INVITE establishes a session, and it also - creates a dialog between the UA that issued the INVITE and the UA - that generated the 2xx response. Therefore, when multiple 2xx - responses are received from different remote UAs (because the INVITE - forked), each 2xx establishes a different dialog. All these dialogs - are part of the same call. - - This section provides details on the establishment of a session using - INVITE. A UA that supports INVITE MUST also support ACK, CANCEL and - BYE. - -13.2 UAC Processing - -13.2.1 Creating the Initial INVITE - - Since the initial INVITE represents a request outside of a dialog, - its construction follows the procedures of Section 8.1.1. Additional - processing is required for the specific case of INVITE. - - An Allow header field (Section 20.5) SHOULD be present in the INVITE. - It indicates what methods can be invoked within a dialog, on the UA - sending the INVITE, for the duration of the dialog. For example, a - UA capable of receiving INFO requests within a dialog [34] SHOULD - include an Allow header field listing the INFO method. - - A Supported header field (Section 20.37) SHOULD be present in the - INVITE. It enumerates all the extensions understood by the UAC. - - - - - -Rosenberg, et. al. Standards Track [Page 78] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - An Accept (Section 20.1) header field MAY be present in the INVITE. - It indicates which Content-Types are acceptable to the UA, in both - the response received by it, and in any subsequent requests sent to - it within dialogs established by the INVITE. The Accept header field - is especially useful for indicating support of various session - description formats. - - The UAC MAY add an Expires header field (Section 20.19) to limit the - validity of the invitation. If the time indicated in the Expires - header field is reached and no final answer for the INVITE has been - received, the UAC core SHOULD generate a CANCEL request for the - INVITE, as per Section 9. - - A UAC MAY also find it useful to add, among others, Subject (Section - 20.36), Organization (Section 20.25) and User-Agent (Section 20.41) - header fields. They all contain information related to the INVITE. - - The UAC MAY choose to add a message body to the INVITE. Section - 8.1.1.10 deals with how to construct the header fields -- Content- - Type among others -- needed to describe the message body. - - There are special rules for message bodies that contain a session - description - their corresponding Content-Disposition is "session". - SIP uses an offer/answer model where one UA sends a session - description, called the offer, which contains a proposed description - of the session. The offer indicates the desired communications means - (audio, video, games), parameters of those means (such as codec - types) and addresses for receiving media from the answerer. The - other UA responds with another session description, called the - answer, which indicates which communications means are accepted, the - parameters that apply to those means, and addresses for receiving - media from the offerer. An offer/answer exchange is within the - context of a dialog, so that if a SIP INVITE results in multiple - dialogs, each is a separate offer/answer exchange. The offer/answer - model defines restrictions on when offers and answers can be made - (for example, you cannot make a new offer while one is in progress). - This results in restrictions on where the offers and answers can - appear in SIP messages. In this specification, offers and answers - can only appear in INVITE requests and responses, and ACK. The usage - of offers and answers is further restricted. For the initial INVITE - transaction, the rules are: - - o The initial offer MUST be in either an INVITE or, if not there, - in the first reliable non-failure message from the UAS back to - the UAC. In this specification, that is the final 2xx - response. - - - - - -Rosenberg, et. al. Standards Track [Page 79] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - o If the initial offer is in an INVITE, the answer MUST be in a - reliable non-failure message from UAS back to UAC which is - correlated to that INVITE. For this specification, that is - only the final 2xx response to that INVITE. That same exact - answer MAY also be placed in any provisional responses sent - prior to the answer. The UAC MUST treat the first session - description it receives as the answer, and MUST ignore any - session descriptions in subsequent responses to the initial - INVITE. - - o If the initial offer is in the first reliable non-failure - message from the UAS back to UAC, the answer MUST be in the - acknowledgement for that message (in this specification, ACK - for a 2xx response). - - o After having sent or received an answer to the first offer, the - UAC MAY generate subsequent offers in requests based on rules - specified for that method, but only if it has received answers - to any previous offers, and has not sent any offers to which it - hasn't gotten an answer. - - o Once the UAS has sent or received an answer to the initial - offer, it MUST NOT generate subsequent offers in any responses - to the initial INVITE. This means that a UAS based on this - specification alone can never generate subsequent offers until - completion of the initial transaction. - - Concretely, the above rules specify two exchanges for UAs compliant - to this specification alone - the offer is in the INVITE, and the - answer in the 2xx (and possibly in a 1xx as well, with the same - value), or the offer is in the 2xx, and the answer is in the ACK. - All user agents that support INVITE MUST support these two exchanges. - - The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be - supported by all user agents as a means to describe sessions, and its - usage for constructing offers and answers MUST follow the procedures - defined in [13]. - - The restrictions of the offer-answer model just described only apply - to bodies whose Content-Disposition header field value is "session". - Therefore, it is possible that both the INVITE and the ACK contain a - body message (for example, the INVITE carries a photo (Content- - Disposition: render) and the ACK a session description (Content- - Disposition: session)). - - If the Content-Disposition header field is missing, bodies of - Content-Type application/sdp imply the disposition "session", while - other content types imply "render". - - - -Rosenberg, et. al. Standards Track [Page 80] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Once the INVITE has been created, the UAC follows the procedures - defined for sending requests outside of a dialog (Section 8). This - results in the construction of a client transaction that will - ultimately send the request and deliver responses to the UAC. - -13.2.2 Processing INVITE Responses - - Once the INVITE has been passed to the INVITE client transaction, the - UAC waits for responses for the INVITE. If the INVITE client - transaction returns a timeout rather than a response the TU acts as - if a 408 (Request Timeout) response had been received, as described - in Section 8.1.3. - -13.2.2.1 1xx Responses - - Zero, one or multiple provisional responses may arrive before one or - more final responses are received. Provisional responses for an - INVITE request can create "early dialogs". If a provisional response - has a tag in the To field, and if the dialog ID of the response does - not match an existing dialog, one is constructed using the procedures - defined in Section 12.1.2. - - The early dialog will only be needed if the UAC needs to send a - request to its peer within the dialog before the initial INVITE - transaction completes. Header fields present in a provisional - response are applicable as long as the dialog is in the early state - (for example, an Allow header field in a provisional response - contains the methods that can be used in the dialog while this is in - the early state). - -13.2.2.2 3xx Responses - - A 3xx response may contain one or more Contact header field values - providing new addresses where the callee might be reachable. - Depending on the status code of the 3xx response (see Section 21.3), - the UAC MAY choose to try those new addresses. - -13.2.2.3 4xx, 5xx and 6xx Responses - - A single non-2xx final response may be received for the INVITE. 4xx, - 5xx and 6xx responses may contain a Contact header field value - indicating the location where additional information about the error - can be found. Subsequent final responses (which would only arrive - under error conditions) MUST be ignored. - - All early dialogs are considered terminated upon reception of the - non-2xx final response. - - - - -Rosenberg, et. al. Standards Track [Page 81] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - After having received the non-2xx final response the UAC core - considers the INVITE transaction completed. The INVITE client - transaction handles the generation of ACKs for the response (see - Section 17). - -13.2.2.4 2xx Responses - - Multiple 2xx responses may arrive at the UAC for a single INVITE - request due to a forking proxy. Each response is distinguished by - the tag parameter in the To header field, and each represents a - distinct dialog, with a distinct dialog identifier. - - If the dialog identifier in the 2xx response matches the dialog - identifier of an existing dialog, the dialog MUST be transitioned to - the "confirmed" state, and the route set for the dialog MUST be - recomputed based on the 2xx response using the procedures of Section - 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be - constructed using the procedures of Section 12.1.2. - - Note that the only piece of state that is recomputed is the route - set. Other pieces of state such as the highest sequence numbers - (remote and local) sent within the dialog are not recomputed. The - route set only is recomputed for backwards compatibility. RFC - 2543 did not mandate mirroring of the Record-Route header field in - a 1xx, only 2xx. However, we cannot update the entire state of - the dialog, since mid-dialog requests may have been sent within - the early dialog, modifying the sequence numbers, for example. - - The UAC core MUST generate an ACK request for each 2xx received from - the transaction layer. The header fields of the ACK are constructed - in the same way as for any request sent within a dialog (see Section - 12) with the exception of the CSeq and the header fields related to - authentication. The sequence number of the CSeq header field MUST be - the same as the INVITE being acknowledged, but the CSeq method MUST - be ACK. The ACK MUST contain the same credentials as the INVITE. If - the 2xx contains an offer (based on the rules above), the ACK MUST - carry an answer in its body. If the offer in the 2xx response is not - acceptable, the UAC core MUST generate a valid answer in the ACK and - then send a BYE immediately. - - Once the ACK has been constructed, the procedures of [4] are used to - determine the destination address, port and transport. However, the - request is passed to the transport layer directly for transmission, - rather than a client transaction. This is because the UAC core - handles retransmissions of the ACK, not the transaction layer. The - ACK MUST be passed to the client transport every time a - retransmission of the 2xx final response that triggered the ACK - arrives. - - - -Rosenberg, et. al. Standards Track [Page 82] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The UAC core considers the INVITE transaction completed 64*T1 seconds - after the reception of the first 2xx response. At this point all the - early dialogs that have not transitioned to established dialogs are - terminated. Once the INVITE transaction is considered completed by - the UAC core, no more new 2xx responses are expected to arrive. - - If, after acknowledging any 2xx response to an INVITE, the UAC does - not want to continue with that dialog, then the UAC MUST terminate - the dialog by sending a BYE request as described in Section 15. - -13.3 UAS Processing - -13.3.1 Processing of the INVITE - - The UAS core will receive INVITE requests from the transaction layer. - It first performs the request processing procedures of Section 8.2, - which are applied for both requests inside and outside of a dialog. - - Assuming these processing states are completed without generating a - response, the UAS core performs the additional processing steps: - - 1. If the request is an INVITE that contains an Expires header - field, the UAS core sets a timer for the number of seconds - indicated in the header field value. When the timer fires, the - invitation is considered to be expired. If the invitation - expires before the UAS has generated a final response, a 487 - (Request Terminated) response SHOULD be generated. - - 2. If the request is a mid-dialog request, the method-independent - processing described in Section 12.2.2 is first applied. It - might also modify the session; Section 14 provides details. - - 3. If the request has a tag in the To header field but the dialog - identifier does not match any of the existing dialogs, the UAS - may have crashed and restarted, or may have received a request - for a different (possibly failed) UAS. Section 12.2.2 provides - guidelines to achieve a robust behavior under such a situation. - - Processing from here forward assumes that the INVITE is outside of a - dialog, and is thus for the purposes of establishing a new session. - - The INVITE may contain a session description, in which case the UAS - is being presented with an offer for that session. It is possible - that the user is already a participant in that session, even though - the INVITE is outside of a dialog. This can happen when a user is - invited to the same multicast conference by multiple other - participants. If desired, the UAS MAY use identifiers within the - session description to detect this duplication. For example, SDP - - - -Rosenberg, et. al. Standards Track [Page 83] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - contains a session id and version number in the origin (o) field. If - the user is already a member of the session, and the session - parameters contained in the session description have not changed, the - UAS MAY silently accept the INVITE (that is, send a 2xx response - without prompting the user). - - If the INVITE does not contain a session description, the UAS is - being asked to participate in a session, and the UAC has asked that - the UAS provide the offer of the session. It MUST provide the offer - in its first non-failure reliable message back to the UAC. In this - specification, that is a 2xx response to the INVITE. - - The UAS can indicate progress, accept, redirect, or reject the - invitation. In all of these cases, it formulates a response using - the procedures described in Section 8.2.6. - -13.3.1.1 Progress - - If the UAS is not able to answer the invitation immediately, it can - choose to indicate some kind of progress to the UAC (for example, an - indication that a phone is ringing). This is accomplished with a - provisional response between 101 and 199. These provisional - responses establish early dialogs and therefore follow the procedures - of Section 12.1.1 in addition to those of Section 8.2.6. A UAS MAY - send as many provisional responses as it likes. Each of these MUST - indicate the same dialog ID. However, these will not be delivered - reliably. - - If the UAS desires an extended period of time to answer the INVITE, - it will need to ask for an "extension" in order to prevent proxies - from canceling the transaction. A proxy has the option of canceling - a transaction when there is a gap of 3 minutes between responses in a - transaction. To prevent cancellation, the UAS MUST send a non-100 - provisional response at every minute, to handle the possibility of - lost provisional responses. - - An INVITE transaction can go on for extended durations when the - user is placed on hold, or when interworking with PSTN systems - which allow communications to take place without answering the - call. The latter is common in Interactive Voice Response (IVR) - systems. - -13.3.1.2 The INVITE is Redirected - - If the UAS decides to redirect the call, a 3xx response is sent. A - 300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved - Temporarily) response SHOULD contain a Contact header field - - - - -Rosenberg, et. al. Standards Track [Page 84] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - containing one or more URIs of new addresses to be tried. The - response is passed to the INVITE server transaction, which will deal - with its retransmissions. - -13.3.1.3 The INVITE is Rejected - - A common scenario occurs when the callee is currently not willing or - able to take additional calls at this end system. A 486 (Busy Here) - SHOULD be returned in such a scenario. If the UAS knows that no - other end system will be able to accept this call, a 600 (Busy - Everywhere) response SHOULD be sent instead. However, it is unlikely - that a UAS will be able to know this in general, and thus this - response will not usually be used. The response is passed to the - INVITE server transaction, which will deal with its retransmissions. - - A UAS rejecting an offer contained in an INVITE SHOULD return a 488 - (Not Acceptable Here) response. Such a response SHOULD include a - Warning header field value explaining why the offer was rejected. - -13.3.1.4 The INVITE is Accepted - - The UAS core generates a 2xx response. This response establishes a - dialog, and therefore follows the procedures of Section 12.1.1 in - addition to those of Section 8.2.6. - - A 2xx response to an INVITE SHOULD contain the Allow header field and - the Supported header field, and MAY contain the Accept header field. - Including these header fields allows the UAC to determine the - features and extensions supported by the UAS for the duration of the - call, without probing. - - If the INVITE request contained an offer, and the UAS had not yet - sent an answer, the 2xx MUST contain an answer. If the INVITE did - not contain an offer, the 2xx MUST contain an offer if the UAS had - not yet sent an offer. - - Once the response has been constructed, it is passed to the INVITE - server transaction. Note, however, that the INVITE server - transaction will be destroyed as soon as it receives this final - response and passes it to the transport. Therefore, it is necessary - to periodically pass the response directly to the transport until the - ACK arrives. The 2xx response is passed to the transport with an - interval that starts at T1 seconds and doubles for each - retransmission until it reaches T2 seconds (T1 and T2 are defined in - Section 17). Response retransmissions cease when an ACK request for - the response is received. This is independent of whatever transport - protocols are used to send the response. - - - - -Rosenberg, et. al. Standards Track [Page 85] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Since 2xx is retransmitted end-to-end, there may be hops between - UAS and UAC that are UDP. To ensure reliable delivery across - these hops, the response is retransmitted periodically even if the - transport at the UAS is reliable. - - If the server retransmits the 2xx response for 64*T1 seconds without - receiving an ACK, the dialog is confirmed, but the session SHOULD be - terminated. This is accomplished with a BYE, as described in Section - 15. - -14 Modifying an Existing Session - - A successful INVITE request (see Section 13) establishes both a - dialog between two user agents and a session using the offer-answer - model. Section 12 explains how to modify an existing dialog using a - target refresh request (for example, changing the remote target URI - of the dialog). This section describes how to modify the actual - session. This modification can involve changing addresses or ports, - adding a media stream, deleting a media stream, and so on. This is - accomplished by sending a new INVITE request within the same dialog - that established the session. An INVITE request sent within an - existing dialog is known as a re-INVITE. - - Note that a single re-INVITE can modify the dialog and the - parameters of the session at the same time. - - Either the caller or callee can modify an existing session. - - The behavior of a UA on detection of media failure is a matter of - local policy. However, automated generation of re-INVITE or BYE is - NOT RECOMMENDED to avoid flooding the network with traffic when there - is congestion. In any case, if these messages are sent - automatically, they SHOULD be sent after some randomized interval. - - Note that the paragraph above refers to automatically generated - BYEs and re-INVITEs. If the user hangs up upon media failure, the - UA would send a BYE request as usual. - -14.1 UAC Behavior - - The same offer-answer model that applies to session descriptions in - INVITEs (Section 13.2.1) applies to re-INVITEs. As a result, a UAC - that wants to add a media stream, for example, will create a new - offer that contains this media stream, and send that in an INVITE - request to its peer. It is important to note that the full - description of the session, not just the change, is sent. This - supports stateless session processing in various elements, and - supports failover and recovery capabilities. Of course, a UAC MAY - - - -Rosenberg, et. al. Standards Track [Page 86] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - send a re-INVITE with no session description, in which case the first - reliable non-failure response to the re-INVITE will contain the offer - (in this specification, that is a 2xx response). - - If the session description format has the capability for version - numbers, the offerer SHOULD indicate that the version of the session - description has changed. - - The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set - following the same rules as for regular requests within an existing - dialog, described in Section 12. - - A UAC MAY choose not to add an Alert-Info header field or a body with - Content-Disposition "alert" to re-INVITEs because UASs do not - typically alert the user upon reception of a re-INVITE. - - Unlike an INVITE, which can fork, a re-INVITE will never fork, and - therefore, only ever generate a single final response. The reason a - re-INVITE will never fork is that the Request-URI identifies the - target as the UA instance it established the dialog with, rather than - identifying an address-of-record for the user. - - Note that a UAC MUST NOT initiate a new INVITE transaction within a - dialog while another INVITE transaction is in progress in either - direction. - - 1. If there is an ongoing INVITE client transaction, the TU MUST - wait until the transaction reaches the completed or terminated - state before initiating the new INVITE. - - 2. If there is an ongoing INVITE server transaction, the TU MUST - wait until the transaction reaches the confirmed or terminated - state before initiating the new INVITE. - - However, a UA MAY initiate a regular transaction while an INVITE - transaction is in progress. A UA MAY also initiate an INVITE - transaction while a regular transaction is in progress. - - If a UA receives a non-2xx final response to a re-INVITE, the session - parameters MUST remain unchanged, as if no re-INVITE had been issued. - Note that, as stated in Section 12.2.1.2, if the non-2xx final - response is a 481 (Call/Transaction Does Not Exist), or a 408 - (Request Timeout), or no response at all is received for the re- - INVITE (that is, a timeout is returned by the INVITE client - transaction), the UAC will terminate the dialog. - - - - - - -Rosenberg, et. al. Standards Track [Page 87] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - If a UAC receives a 491 response to a re-INVITE, it SHOULD start a - timer with a value T chosen as follows: - - 1. If the UAC is the owner of the Call-ID of the dialog ID - (meaning it generated the value), T has a randomly chosen value - between 2.1 and 4 seconds in units of 10 ms. - - 2. If the UAC is not the owner of the Call-ID of the dialog ID, T - has a randomly chosen value of between 0 and 2 seconds in units - of 10 ms. - - When the timer fires, the UAC SHOULD attempt the re-INVITE once more, - if it still desires for that session modification to take place. For - example, if the call was already hung up with a BYE, the re-INVITE - would not take place. - - The rules for transmitting a re-INVITE and for generating an ACK for - a 2xx response to re-INVITE are the same as for the initial INVITE - (Section 13.2.1). - -14.2 UAS Behavior - - Section 13.3.1 describes the procedure for distinguishing incoming - re-INVITEs from incoming initial INVITEs and handling a re-INVITE for - an existing dialog. - - A UAS that receives a second INVITE before it sends the final - response to a first INVITE with a lower CSeq sequence number on the - same dialog MUST return a 500 (Server Internal Error) response to the - second INVITE and MUST include a Retry-After header field with a - randomly chosen value of between 0 and 10 seconds. - - A UAS that receives an INVITE on a dialog while an INVITE it had sent - on that dialog is in progress MUST return a 491 (Request Pending) - response to the received INVITE. - - If a UA receives a re-INVITE for an existing dialog, it MUST check - any version identifiers in the session description or, if there are - no version identifiers, the content of the session description to see - if it has changed. If the session description has changed, the UAS - MUST adjust the session parameters accordingly, possibly after asking - the user for confirmation. - - Versioning of the session description can be used to accommodate - the capabilities of new arrivals to a conference, add or delete - media, or change from a unicast to a multicast conference. - - - - - -Rosenberg, et. al. Standards Track [Page 88] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - If the new session description is not acceptable, the UAS can reject - it by returning a 488 (Not Acceptable Here) response for the re- - INVITE. This response SHOULD include a Warning header field. - - If a UAS generates a 2xx response and never receives an ACK, it - SHOULD generate a BYE to terminate the dialog. - - A UAS MAY choose not to generate 180 (Ringing) responses for a re- - INVITE because UACs do not typically render this information to the - user. For the same reason, UASs MAY choose not to use an Alert-Info - header field or a body with Content-Disposition "alert" in responses - to a re-INVITE. - - A UAS providing an offer in a 2xx (because the INVITE did not contain - an offer) SHOULD construct the offer as if the UAS were making a - brand new call, subject to the constraints of sending an offer that - updates an existing session, as described in [13] in the case of SDP. - Specifically, this means that it SHOULD include as many media formats - and media types that the UA is willing to support. The UAS MUST - ensure that the session description overlaps with its previous - session description in media formats, transports, or other parameters - that require support from the peer. This is to avoid the need for - the peer to reject the session description. If, however, it is - unacceptable to the UAC, the UAC SHOULD generate an answer with a - valid session description, and then send a BYE to terminate the - session. - -15 Terminating a Session - - This section describes the procedures for terminating a session - established by SIP. The state of the session and the state of the - dialog are very closely related. When a session is initiated with an - INVITE, each 1xx or 2xx response from a distinct UAS creates a - dialog, and if that response completes the offer/answer exchange, it - also creates a session. As a result, each session is "associated" - with a single dialog - the one which resulted in its creation. If an - initial INVITE generates a non-2xx final response, that terminates - all sessions (if any) and all dialogs (if any) that were created - through responses to the request. By virtue of completing the - transaction, a non-2xx final response also prevents further sessions - from being created as a result of the INVITE. The BYE request is - used to terminate a specific session or attempted session. In this - case, the specific session is the one with the peer UA on the other - side of the dialog. When a BYE is received on a dialog, any session - associated with that dialog SHOULD terminate. A UA MUST NOT send a - BYE outside of a dialog. The caller's UA MAY send a BYE for either - confirmed or early dialogs, and the callee's UA MAY send a BYE on - confirmed dialogs, but MUST NOT send a BYE on early dialogs. - - - -Rosenberg, et. al. Standards Track [Page 89] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - However, the callee's UA MUST NOT send a BYE on a confirmed dialog - until it has received an ACK for its 2xx response or until the server - transaction times out. If no SIP extensions have defined other - application layer states associated with the dialog, the BYE also - terminates the dialog. - - The impact of a non-2xx final response to INVITE on dialogs and - sessions makes the use of CANCEL attractive. The CANCEL attempts to - force a non-2xx response to the INVITE (in particular, a 487). - Therefore, if a UAC wishes to give up on its call attempt entirely, - it can send a CANCEL. If the INVITE results in 2xx final response(s) - to the INVITE, this means that a UAS accepted the invitation while - the CANCEL was in progress. The UAC MAY continue with the sessions - established by any 2xx responses, or MAY terminate them with BYE. - - The notion of "hanging up" is not well defined within SIP. It is - specific to a particular, albeit common, user interface. - Typically, when the user hangs up, it indicates a desire to - terminate the attempt to establish a session, and to terminate any - sessions already created. For the caller's UA, this would imply a - CANCEL request if the initial INVITE has not generated a final - response, and a BYE to all confirmed dialogs after a final - response. For the callee's UA, it would typically imply a BYE; - presumably, when the user picked up the phone, a 2xx was - generated, and so hanging up would result in a BYE after the ACK - is received. This does not mean a user cannot hang up before - receipt of the ACK, it just means that the software in his phone - needs to maintain state for a short while in order to clean up - properly. If the particular UI allows for the user to reject a - call before its answered, a 403 (Forbidden) is a good way to - express that. As per the rules above, a BYE can't be sent. - -15.1 Terminating a Session with a BYE Request - -15.1.1 UAC Behavior - - A BYE request is constructed as would any other request within a - dialog, as described in Section 12. - - Once the BYE is constructed, the UAC core creates a new non-INVITE - client transaction, and passes it the BYE request. The UAC MUST - consider the session terminated (and therefore stop sending or - listening for media) as soon as the BYE request is passed to the - client transaction. If the response for the BYE is a 481 - (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no - - - - - - -Rosenberg, et. al. Standards Track [Page 90] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - response at all is received for the BYE (that is, a timeout is - returned by the client transaction), the UAC MUST consider the - session and the dialog terminated. - -15.1.2 UAS Behavior - - A UAS first processes the BYE request according to the general UAS - processing described in Section 8.2. A UAS core receiving a BYE - request checks if it matches an existing dialog. If the BYE does not - match an existing dialog, the UAS core SHOULD generate a 481 - (Call/Transaction Does Not Exist) response and pass that to the - server transaction. - - This rule means that a BYE sent without tags by a UAC will be - rejected. This is a change from RFC 2543, which allowed BYE - without tags. - - A UAS core receiving a BYE request for an existing dialog MUST follow - the procedures of Section 12.2.2 to process the request. Once done, - the UAS SHOULD terminate the session (and therefore stop sending and - listening for media). The only case where it can elect not to are - multicast sessions, where participation is possible even if the other - participant in the dialog has terminated its involvement in the - session. Whether or not it ends its participation on the session, - the UAS core MUST generate a 2xx response to the BYE, and MUST pass - that to the server transaction for transmission. - - The UAS MUST still respond to any pending requests received for that - dialog. It is RECOMMENDED that a 487 (Request Terminated) response - be generated to those pending requests. - -16 Proxy Behavior - -16.1 Overview - - SIP proxies are elements that route SIP requests to user agent - servers and SIP responses to user agent clients. A request may - traverse several proxies on its way to a UAS. Each will make routing - decisions, modifying the request before forwarding it to the next - element. Responses will route through the same set of proxies - traversed by the request in the reverse order. - - Being a proxy is a logical role for a SIP element. When a request - arrives, an element that can play the role of a proxy first decides - if it needs to respond to the request on its own. For instance, the - request may be malformed or the element may need credentials from the - client before acting as a proxy. The element MAY respond with any - - - - -Rosenberg, et. al. Standards Track [Page 91] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - appropriate error code. When responding directly to a request, the - element is playing the role of a UAS and MUST behave as described in - Section 8.2. - - A proxy can operate in either a stateful or stateless mode for each - new request. When stateless, a proxy acts as a simple forwarding - element. It forwards each request downstream to a single element - determined by making a targeting and routing decision based on the - request. It simply forwards every response it receives upstream. A - stateless proxy discards information about a message once the message - has been forwarded. A stateful proxy remembers information - (specifically, transaction state) about each incoming request and any - requests it sends as a result of processing the incoming request. It - uses this information to affect the processing of future messages - associated with that request. A stateful proxy MAY choose to "fork" - a request, routing it to multiple destinations. Any request that is - forwarded to more than one location MUST be handled statefully. - - In some circumstances, a proxy MAY forward requests using stateful - transports (such as TCP) without being transaction-stateful. For - instance, a proxy MAY forward a request from one TCP connection to - another transaction statelessly as long as it places enough - information in the message to be able to forward the response down - the same connection the request arrived on. Requests forwarded - between different types of transports where the proxy's TU must take - an active role in ensuring reliable delivery on one of the transports - MUST be forwarded transaction statefully. - - A stateful proxy MAY transition to stateless operation at any time - during the processing of a request, so long as it did not do anything - that would otherwise prevent it from being stateless initially - (forking, for example, or generation of a 100 response). When - performing such a transition, all state is simply discarded. The - proxy SHOULD NOT initiate a CANCEL request. - - Much of the processing involved when acting statelessly or statefully - for a request is identical. The next several subsections are written - from the point of view of a stateful proxy. The last section calls - out those places where a stateless proxy behaves differently. - -16.2 Stateful Proxy - - When stateful, a proxy is purely a SIP transaction processing engine. - Its behavior is modeled here in terms of the server and client - transactions defined in Section 17. A stateful proxy has a server - transaction associated with one or more client transactions by a - higher layer proxy processing component (see figure 3), known as a - proxy core. An incoming request is processed by a server - - - -Rosenberg, et. al. Standards Track [Page 92] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - transaction. Requests from the server transaction are passed to a - proxy core. The proxy core determines where to route the request, - choosing one or more next-hop locations. An outgoing request for - each next-hop location is processed by its own associated client - transaction. The proxy core collects the responses from the client - transactions and uses them to send responses to the server - transaction. - - A stateful proxy creates a new server transaction for each new - request received. Any retransmissions of the request will then be - handled by that server transaction per Section 17. The proxy core - MUST behave as a UAS with respect to sending an immediate provisional - on that server transaction (such as 100 Trying) as described in - Section 8.2.6. Thus, a stateful proxy SHOULD NOT generate 100 - (Trying) responses to non-INVITE requests. - - This is a model of proxy behavior, not of software. An - implementation is free to take any approach that replicates the - external behavior this model defines. - - For all new requests, including any with unknown methods, an element - intending to proxy the request MUST: - - 1. Validate the request (Section 16.3) - - 2. Preprocess routing information (Section 16.4) - - 3. Determine target(s) for the request (Section 16.5) - - +--------------------+ - | | +---+ - | | | C | - | | | T | - | | +---+ - +---+ | Proxy | +---+ CT = Client Transaction - | S | | "Higher" Layer | | C | - | T | | | | T | ST = Server Transaction - +---+ | | +---+ - | | +---+ - | | | C | - | | | T | - | | +---+ - +--------------------+ - - Figure 3: Stateful Proxy Model - - - - - - -Rosenberg, et. al. Standards Track [Page 93] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - 4. Forward the request to each target (Section 16.6) - - 5. Process all responses (Section 16.7) - -16.3 Request Validation - - Before an element can proxy a request, it MUST verify the message's - validity. A valid message must pass the following checks: - - 1. Reasonable Syntax - - 2. URI scheme - - 3. Max-Forwards - - 4. (Optional) Loop Detection - - 5. Proxy-Require - - 6. Proxy-Authorization - - If any of these checks fail, the element MUST behave as a user agent - server (see Section 8.2) and respond with an error code. - - Notice that a proxy is not required to detect merged requests and - MUST NOT treat merged requests as an error condition. The endpoints - receiving the requests will resolve the merge as described in Section - 8.2.2.2. - - 1. Reasonable syntax check - - The request MUST be well-formed enough to be handled with a server - transaction. Any components involved in the remainder of these - Request Validation steps or the Request Forwarding section MUST be - well-formed. Any other components, well-formed or not, SHOULD be - ignored and remain unchanged when the message is forwarded. For - instance, an element would not reject a request because of a - malformed Date header field. Likewise, a proxy would not remove a - malformed Date header field before forwarding a request. - - This protocol is designed to be extended. Future extensions may - define new methods and header fields at any time. An element MUST - NOT refuse to proxy a request because it contains a method or - header field it does not know about. - - - - - - - -Rosenberg, et. al. Standards Track [Page 94] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - 2. URI scheme check - - If the Request-URI has a URI whose scheme is not understood by the - proxy, the proxy SHOULD reject the request with a 416 (Unsupported - URI Scheme) response. - - 3. Max-Forwards check - - The Max-Forwards header field (Section 20.22) is used to limit the - number of elements a SIP request can traverse. - - If the request does not contain a Max-Forwards header field, this - check is passed. - - If the request contains a Max-Forwards header field with a field - value greater than zero, the check is passed. - - If the request contains a Max-Forwards header field with a field - value of zero (0), the element MUST NOT forward the request. If - the request was for OPTIONS, the element MAY act as the final - recipient and respond per Section 11. Otherwise, the element MUST - return a 483 (Too many hops) response. - - 4. Optional Loop Detection check - - An element MAY check for forwarding loops before forwarding a - request. If the request contains a Via header field with a sent- - by value that equals a value placed into previous requests by the - proxy, the request has been forwarded by this element before. The - request has either looped or is legitimately spiraling through the - element. To determine if the request has looped, the element MAY - perform the branch parameter calculation described in Step 8 of - Section 16.6 on this message and compare it to the parameter - received in that Via header field. If the parameters match, the - request has looped. If they differ, the request is spiraling, and - processing continues. If a loop is detected, the element MAY - return a 482 (Loop Detected) response. - - 5. Proxy-Require check - - Future extensions to this protocol may introduce features that - require special handling by proxies. Endpoints will include a - Proxy-Require header field in requests that use these features, - telling the proxy not to process the request unless the feature is - understood. - - - - - - -Rosenberg, et. al. Standards Track [Page 95] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - If the request contains a Proxy-Require header field (Section - 20.29) with one or more option-tags this element does not - understand, the element MUST return a 420 (Bad Extension) - response. The response MUST include an Unsupported (Section - 20.40) header field listing those option-tags the element did not - understand. - - 6. Proxy-Authorization check - - If an element requires credentials before forwarding a request, - the request MUST be inspected as described in Section 22.3. That - section also defines what the element must do if the inspection - fails. - -16.4 Route Information Preprocessing - - The proxy MUST inspect the Request-URI of the request. If the - Request-URI of the request contains a value this proxy previously - placed into a Record-Route header field (see Section 16.6 item 4), - the proxy MUST replace the Request-URI in the request with the last - value from the Route header field, and remove that value from the - Route header field. The proxy MUST then proceed as if it received - this modified request. - - This will only happen when the element sending the request to the - proxy (which may have been an endpoint) is a strict router. This - rewrite on receive is necessary to enable backwards compatibility - with those elements. It also allows elements following this - specification to preserve the Request-URI through strict-routing - proxies (see Section 12.2.1.1). - - This requirement does not obligate a proxy to keep state in order - to detect URIs it previously placed in Record-Route header fields. - Instead, a proxy need only place enough information in those URIs - to recognize them as values it provided when they later appear. - - If the Request-URI contains a maddr parameter, the proxy MUST check - to see if its value is in the set of addresses or domains the proxy - is configured to be responsible for. If the Request-URI has a maddr - parameter with a value the proxy is responsible for, and the request - was received using the port and transport indicated (explicitly or by - default) in the Request-URI, the proxy MUST strip the maddr and any - non-default port or transport parameter and continue processing as if - those values had not been present in the request. - - - - - - - -Rosenberg, et. al. Standards Track [Page 96] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - A request may arrive with a maddr matching the proxy, but on a - port or transport different from that indicated in the URI. Such - a request needs to be forwarded to the proxy using the indicated - port and transport. - - If the first value in the Route header field indicates this proxy, - the proxy MUST remove that value from the request. - -16.5 Determining Request Targets - - Next, the proxy calculates the target(s) of the request. The set of - targets will either be predetermined by the contents of the request - or will be obtained from an abstract location service. Each target - in the set is represented as a URI. - - If the Request-URI of the request contains an maddr parameter, the - Request-URI MUST be placed into the target set as the only target - URI, and the proxy MUST proceed to Section 16.6. - - If the domain of the Request-URI indicates a domain this element is - not responsible for, the Request-URI MUST be placed into the target - set as the only target, and the element MUST proceed to the task of - Request Forwarding (Section 16.6). - - There are many circumstances in which a proxy might receive a - request for a domain it is not responsible for. A firewall proxy - handling outgoing calls (the way HTTP proxies handle outgoing - requests) is an example of where this is likely to occur. - - If the target set for the request has not been predetermined as - described above, this implies that the element is responsible for the - domain in the Request-URI, and the element MAY use whatever mechanism - it desires to determine where to send the request. Any of these - mechanisms can be modeled as accessing an abstract Location Service. - This may consist of obtaining information from a location service - created by a SIP Registrar, reading a database, consulting a presence - server, utilizing other protocols, or simply performing an - algorithmic substitution on the Request-URI. When accessing the - location service constructed by a registrar, the Request-URI MUST - first be canonicalized as described in Section 10.3 before being used - as an index. The output of these mechanisms is used to construct the - target set. - - If the Request-URI does not provide sufficient information for the - proxy to determine the target set, it SHOULD return a 485 (Ambiguous) - response. This response SHOULD contain a Contact header field - containing URIs of new addresses to be tried. For example, an INVITE - - - - -Rosenberg, et. al. Standards Track [Page 97] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - to sip:John.Smith@company.com may be ambiguous at a proxy whose - location service has multiple John Smiths listed. See Section - 21.4.23 for details. - - Any information in or about the request or the current environment of - the element MAY be used in the construction of the target set. For - instance, different sets may be constructed depending on contents or - the presence of header fields and bodies, the time of day of the - request's arrival, the interface on which the request arrived, - failure of previous requests, or even the element's current level of - utilization. - - As potential targets are located through these services, their URIs - are added to the target set. Targets can only be placed in the - target set once. If a target URI is already present in the set - (based on the definition of equality for the URI type), it MUST NOT - be added again. - - A proxy MUST NOT add additional targets to the target set if the - Request-URI of the original request does not indicate a resource this - proxy is responsible for. - - A proxy can only change the Request-URI of a request during - forwarding if it is responsible for that URI. If the proxy is not - responsible for that URI, it will not recurse on 3xx or 416 - responses as described below. - - If the Request-URI of the original request indicates a resource this - proxy is responsible for, the proxy MAY continue to add targets to - the set after beginning Request Forwarding. It MAY use any - information obtained during that processing to determine new targets. - For instance, a proxy may choose to incorporate contacts obtained in - a redirect response (3xx) into the target set. If a proxy uses a - dynamic source of information while building the target set (for - instance, if it consults a SIP Registrar), it SHOULD monitor that - source for the duration of processing the request. New locations - SHOULD be added to the target set as they become available. As - above, any given URI MUST NOT be added to the set more than once. - - Allowing a URI to be added to the set only once reduces - unnecessary network traffic, and in the case of incorporating - contacts from redirect requests prevents infinite recursion. - - For example, a trivial location service is a "no-op", where the - target URI is equal to the incoming request URI. The request is sent - to a specific next hop proxy for further processing. During request - - - - - -Rosenberg, et. al. Standards Track [Page 98] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - forwarding of Section 16.6, Item 6, the identity of that next hop, - expressed as a SIP or SIPS URI, is inserted as the top-most Route - header field value into the request. - - If the Request-URI indicates a resource at this proxy that does not - exist, the proxy MUST return a 404 (Not Found) response. - - If the target set remains empty after applying all of the above, the - proxy MUST return an error response, which SHOULD be the 480 - (Temporarily Unavailable) response. - -16.6 Request Forwarding - - As soon as the target set is non-empty, a proxy MAY begin forwarding - the request. A stateful proxy MAY process the set in any order. It - MAY process multiple targets serially, allowing each client - transaction to complete before starting the next. It MAY start - client transactions with every target in parallel. It also MAY - arbitrarily divide the set into groups, processing the groups - serially and processing the targets in each group in parallel. - - A common ordering mechanism is to use the qvalue parameter of targets - obtained from Contact header fields (see Section 20.10). Targets are - processed from highest qvalue to lowest. Targets with equal qvalues - may be processed in parallel. - - A stateful proxy must have a mechanism to maintain the target set as - responses are received and associate the responses to each forwarded - request with the original request. For the purposes of this model, - this mechanism is a "response context" created by the proxy layer - before forwarding the first request. - - For each target, the proxy forwards the request following these - steps: - - 1. Make a copy of the received request - - 2. Update the Request-URI - - 3. Update the Max-Forwards header field - - 4. Optionally add a Record-route header field value - - 5. Optionally add additional header fields - - 6. Postprocess routing information - - 7. Determine the next-hop address, port, and transport - - - -Rosenberg, et. al. Standards Track [Page 99] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - 8. Add a Via header field value - - 9. Add a Content-Length header field if necessary - - 10. Forward the new request - - 11. Set timer C - - Each of these steps is detailed below: - - 1. Copy request - - The proxy starts with a copy of the received request. The copy - MUST initially contain all of the header fields from the - received request. Fields not detailed in the processing - described below MUST NOT be removed. The copy SHOULD maintain - the ordering of the header fields as in the received request. - The proxy MUST NOT reorder field values with a common field - name (See Section 7.3.1). The proxy MUST NOT add to, modify, - or remove the message body. - - An actual implementation need not perform a copy; the primary - requirement is that the processing for each next hop begin with - the same request. - - 2. Request-URI - - The Request-URI in the copy's start line MUST be replaced with - the URI for this target. If the URI contains any parameters - not allowed in a Request-URI, they MUST be removed. - - This is the essence of a proxy's role. This is the mechanism - through which a proxy routes a request toward its destination. - - In some circumstances, the received Request-URI is placed into - the target set without being modified. For that target, the - replacement above is effectively a no-op. - - 3. Max-Forwards - - If the copy contains a Max-Forwards header field, the proxy - MUST decrement its value by one (1). - - If the copy does not contain a Max-Forwards header field, the - proxy MUST add one with a field value, which SHOULD be 70. - - Some existing UAs will not provide a Max-Forwards header field - in a request. - - - -Rosenberg, et. al. Standards Track [Page 100] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - 4. Record-Route - - If this proxy wishes to remain on the path of future requests - in a dialog created by this request (assuming the request - creates a dialog), it MUST insert a Record-Route header field - value into the copy before any existing Record-Route header - field values, even if a Route header field is already present. - - Requests establishing a dialog may contain a preloaded Route - header field. - - If this request is already part of a dialog, the proxy SHOULD - insert a Record-Route header field value if it wishes to remain - on the path of future requests in the dialog. In normal - endpoint operation as described in Section 12, these Record- - Route header field values will not have any effect on the route - sets used by the endpoints. - - The proxy will remain on the path if it chooses to not insert a - Record-Route header field value into requests that are already - part of a dialog. However, it would be removed from the path - when an endpoint that has failed reconstitutes the dialog. - - A proxy MAY insert a Record-Route header field value into any - request. If the request does not initiate a dialog, the - endpoints will ignore the value. See Section 12 for details on - how endpoints use the Record-Route header field values to - construct Route header fields. - - Each proxy in the path of a request chooses whether to add a - Record-Route header field value independently - the presence of - a Record-Route header field in a request does not obligate this - proxy to add a value. - - The URI placed in the Record-Route header field value MUST be a - SIP or SIPS URI. This URI MUST contain an lr parameter (see - Section 19.1.1). This URI MAY be different for each - destination the request is forwarded to. The URI SHOULD NOT - contain the transport parameter unless the proxy has knowledge - (such as in a private network) that the next downstream element - that will be in the path of subsequent requests supports that - transport. - - The URI this proxy provides will be used by some other element - to make a routing decision. This proxy, in general, has no way - of knowing the capabilities of that element, so it must - restrict itself to the mandatory elements of a SIP - implementation: SIP URIs and either the TCP or UDP transports. - - - -Rosenberg, et. al. Standards Track [Page 101] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The URI placed in the Record-Route header field MUST resolve to - the element inserting it (or a suitable stand-in) when the - server location procedures of [4] are applied to it, so that - subsequent requests reach the same SIP element. If the - Request-URI contains a SIPS URI, or the topmost Route header - field value (after the post processing of bullet 6) contains a - SIPS URI, the URI placed into the Record-Route header field - MUST be a SIPS URI. Furthermore, if the request was not - received over TLS, the proxy MUST insert a Record-Route header - field. In a similar fashion, a proxy that receives a request - over TLS, but generates a request without a SIPS URI in the - Request-URI or topmost Route header field value (after the post - processing of bullet 6), MUST insert a Record-Route header - field that is not a SIPS URI. - - A proxy at a security perimeter must remain on the perimeter - throughout the dialog. - - If the URI placed in the Record-Route header field needs to be - rewritten when it passes back through in a response, the URI - MUST be distinct enough to locate at that time. (The request - may spiral through this proxy, resulting in more than one - Record-Route header field value being added). Item 8 of - Section 16.7 recommends a mechanism to make the URI - sufficiently distinct. - - The proxy MAY include parameters in the Record-Route header - field value. These will be echoed in some responses to the - request such as the 200 (OK) responses to INVITE. Such - parameters may be useful for keeping state in the message - rather than the proxy. - - If a proxy needs to be in the path of any type of dialog (such - as one straddling a firewall), it SHOULD add a Record-Route - header field value to every request with a method it does not - understand since that method may have dialog semantics. - - The URI a proxy places into a Record-Route header field is only - valid for the lifetime of any dialog created by the transaction - in which it occurs. A dialog-stateful proxy, for example, MAY - refuse to accept future requests with that value in the - Request-URI after the dialog has terminated. Non-dialog- - stateful proxies, of course, have no concept of when the dialog - has terminated, but they MAY encode enough information in the - value to compare it against the dialog identifier of future - requests and MAY reject requests not matching that information. - Endpoints MUST NOT use a URI obtained from a Record-Route - header field outside the dialog in which it was provided. See - - - -Rosenberg, et. al. Standards Track [Page 102] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Section 12 for more information on an endpoint's use of - Record-Route header fields. - - Record-routing may be required by certain services where the - proxy needs to observe all messages in a dialog. However, it - slows down processing and impairs scalability and thus proxies - should only record-route if required for a particular service. - - The Record-Route process is designed to work for any SIP - request that initiates a dialog. INVITE is the only such - request in this specification, but extensions to the protocol - MAY define others. - - 5. Add Additional Header Fields - - The proxy MAY add any other appropriate header fields to the - copy at this point. - - 6. Postprocess routing information - - A proxy MAY have a local policy that mandates that a request - visit a specific set of proxies before being delivered to the - destination. A proxy MUST ensure that all such proxies are - loose routers. Generally, this can only be known with - certainty if the proxies are within the same administrative - domain. This set of proxies is represented by a set of URIs - (each of which contains the lr parameter). This set MUST be - pushed into the Route header field of the copy ahead of any - existing values, if present. If the Route header field is - absent, it MUST be added, containing that list of URIs. - - If the proxy has a local policy that mandates that the request - visit one specific proxy, an alternative to pushing a Route - value into the Route header field is to bypass the forwarding - logic of item 10 below, and instead just send the request to - the address, port, and transport for that specific proxy. If - the request has a Route header field, this alternative MUST NOT - be used unless it is known that next hop proxy is a loose - router. Otherwise, this approach MAY be used, but the Route - insertion mechanism above is preferred for its robustness, - flexibility, generality and consistency of operation. - Furthermore, if the Request-URI contains a SIPS URI, TLS MUST - be used to communicate with that proxy. - - If the copy contains a Route header field, the proxy MUST - inspect the URI in its first value. If that URI does not - contain an lr parameter, the proxy MUST modify the copy as - follows: - - - -Rosenberg, et. al. Standards Track [Page 103] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - - The proxy MUST place the Request-URI into the Route header - field as the last value. - - - The proxy MUST then place the first Route header field value - into the Request-URI and remove that value from the Route - header field. - - Appending the Request-URI to the Route header field is part of - a mechanism used to pass the information in that Request-URI - through strict-routing elements. "Popping" the first Route - header field value into the Request-URI formats the message the - way a strict-routing element expects to receive it (with its - own URI in the Request-URI and the next location to visit in - the first Route header field value). - - 7. Determine Next-Hop Address, Port, and Transport - - The proxy MAY have a local policy to send the request to a - specific IP address, port, and transport, independent of the - values of the Route and Request-URI. Such a policy MUST NOT be - used if the proxy is not certain that the IP address, port, and - transport correspond to a server that is a loose router. - However, this mechanism for sending the request through a - specific next hop is NOT RECOMMENDED; instead a Route header - field should be used for that purpose as described above. - - In the absence of such an overriding mechanism, the proxy - applies the procedures listed in [4] as follows to determine - where to send the request. If the proxy has reformatted the - request to send to a strict-routing element as described in - step 6 above, the proxy MUST apply those procedures to the - Request-URI of the request. Otherwise, the proxy MUST apply - the procedures to the first value in the Route header field, if - present, else the Request-URI. The procedures will produce an - ordered set of (address, port, transport) tuples. - Independently of which URI is being used as input to the - procedures of [4], if the Request-URI specifies a SIPS - resource, the proxy MUST follow the procedures of [4] as if the - input URI were a SIPS URI. - - As described in [4], the proxy MUST attempt to deliver the - message to the first tuple in that set, and proceed through the - set in order until the delivery attempt succeeds. - - For each tuple attempted, the proxy MUST format the message as - appropriate for the tuple and send the request using a new - client transaction as detailed in steps 8 through 10. - - - - -Rosenberg, et. al. Standards Track [Page 104] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Since each attempt uses a new client transaction, it represents - a new branch. Thus, the branch parameter provided with the Via - header field inserted in step 8 MUST be different for each - attempt. - - If the client transaction reports failure to send the request - or a timeout from its state machine, the proxy continues to the - next address in that ordered set. If the ordered set is - exhausted, the request cannot be forwarded to this element in - the target set. The proxy does not need to place anything in - the response context, but otherwise acts as if this element of - the target set returned a 408 (Request Timeout) final response. - - 8. Add a Via header field value - - The proxy MUST insert a Via header field value into the copy - before the existing Via header field values. The construction - of this value follows the same guidelines of Section 8.1.1.7. - This implies that the proxy will compute its own branch - parameter, which will be globally unique for that branch, and - contain the requisite magic cookie. Note that this implies that - the branch parameter will be different for different instances - of a spiraled or looped request through a proxy. - - Proxies choosing to detect loops have an additional constraint - in the value they use for construction of the branch parameter. - A proxy choosing to detect loops SHOULD create a branch - parameter separable into two parts by the implementation. The - first part MUST satisfy the constraints of Section 8.1.1.7 as - described above. The second is used to perform loop detection - and distinguish loops from spirals. - - Loop detection is performed by verifying that, when a request - returns to a proxy, those fields having an impact on the - processing of the request have not changed. The value placed - in this part of the branch parameter SHOULD reflect all of - those fields (including any Route, Proxy-Require and Proxy- - Authorization header fields). This is to ensure that if the - request is routed back to the proxy and one of those fields - changes, it is treated as a spiral and not a loop (see Section - 16.3). A common way to create this value is to compute a - cryptographic hash of the To tag, From tag, Call-ID header - field, the Request-URI of the request received (before - translation), the topmost Via header, and the sequence number - from the CSeq header field, in addition to any Proxy-Require - and Proxy-Authorization header fields that may be present. The - - - - - -Rosenberg, et. al. Standards Track [Page 105] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - algorithm used to compute the hash is implementation-dependent, - but MD5 (RFC 1321 [35]), expressed in hexadecimal, is a - reasonable choice. (Base64 is not permissible for a token.) - - If a proxy wishes to detect loops, the "branch" parameter it - supplies MUST depend on all information affecting processing of - a request, including the incoming Request-URI and any header - fields affecting the request's admission or routing. This is - necessary to distinguish looped requests from requests whose - routing parameters have changed before returning to this - server. - - The request method MUST NOT be included in the calculation of - the branch parameter. In particular, CANCEL and ACK requests - (for non-2xx responses) MUST have the same branch value as the - corresponding request they cancel or acknowledge. The branch - parameter is used in correlating those requests at the server - handling them (see Sections 17.2.3 and 9.2). - - 9. Add a Content-Length header field if necessary - - If the request will be sent to the next hop using a stream- - based transport and the copy contains no Content-Length header - field, the proxy MUST insert one with the correct value for the - body of the request (see Section 20.14). - - 10. Forward Request - - A stateful proxy MUST create a new client transaction for this - request as described in Section 17.1 and instructs the - transaction to send the request using the address, port and - transport determined in step 7. - - 11. Set timer C - - In order to handle the case where an INVITE request never - generates a final response, the TU uses a timer which is called - timer C. Timer C MUST be set for each client transaction when - an INVITE request is proxied. The timer MUST be larger than 3 - minutes. Section 16.7 bullet 2 discusses how this timer is - updated with provisional responses, and Section 16.8 discusses - processing when it fires. - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 106] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -16.7 Response Processing - - When a response is received by an element, it first tries to locate a - client transaction (Section 17.1.3) matching the response. If none - is found, the element MUST process the response (even if it is an - informational response) as a stateless proxy (described below). If a - match is found, the response is handed to the client transaction. - - Forwarding responses for which a client transaction (or more - generally any knowledge of having sent an associated request) is - not found improves robustness. In particular, it ensures that - "late" 2xx responses to INVITE requests are forwarded properly. - - As client transactions pass responses to the proxy layer, the - following processing MUST take place: - - 1. Find the appropriate response context - - 2. Update timer C for provisional responses - - 3. Remove the topmost Via - - 4. Add the response to the response context - - 5. Check to see if this response should be forwarded immediately - - 6. When necessary, choose the best final response from the - response context - - If no final response has been forwarded after every client - transaction associated with the response context has been terminated, - the proxy must choose and forward the "best" response from those it - has seen so far. - - The following processing MUST be performed on each response that is - forwarded. It is likely that more than one response to each request - will be forwarded: at least each provisional and one final response. - - 7. Aggregate authorization header field values if necessary - - 8. Optionally rewrite Record-Route header field values - - 9. Forward the response - - 10. Generate any necessary CANCEL requests - - - - - - -Rosenberg, et. al. Standards Track [Page 107] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Each of the above steps are detailed below: - - 1. Find Context - - The proxy locates the "response context" it created before - forwarding the original request using the key described in - Section 16.6. The remaining processing steps take place in - this context. - - 2. Update timer C for provisional responses - - For an INVITE transaction, if the response is a provisional - response with status codes 101 to 199 inclusive (i.e., anything - but 100), the proxy MUST reset timer C for that client - transaction. The timer MAY be reset to a different value, but - this value MUST be greater than 3 minutes. - - 3. Via - - The proxy removes the topmost Via header field value from the - response. - - If no Via header field values remain in the response, the - response was meant for this element and MUST NOT be forwarded. - The remainder of the processing described in this section is - not performed on this message, the UAC processing rules - described in Section 8.1.3 are followed instead (transport - layer processing has already occurred). - - This will happen, for instance, when the element generates - CANCEL requests as described in Section 10. - - 4. Add response to context - - Final responses received are stored in the response context - until a final response is generated on the server transaction - associated with this context. The response may be a candidate - for the best final response to be returned on that server - transaction. Information from this response may be needed in - forming the best response, even if this response is not chosen. - - If the proxy chooses to recurse on any contacts in a 3xx - response by adding them to the target set, it MUST remove them - from the response before adding the response to the response - context. However, a proxy SHOULD NOT recurse to a non-SIPS URI - if the Request-URI of the original request was a SIPS URI. If - - - - - -Rosenberg, et. al. Standards Track [Page 108] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - the proxy recurses on all of the contacts in a 3xx response, - the proxy SHOULD NOT add the resulting contactless response to - the response context. - - Removing the contact before adding the response to the response - context prevents the next element upstream from retrying a - location this proxy has already attempted. - - 3xx responses may contain a mixture of SIP, SIPS, and non-SIP - URIs. A proxy may choose to recurse on the SIP and SIPS URIs - and place the remainder into the response context to be - returned, potentially in the final response. - - If a proxy receives a 416 (Unsupported URI Scheme) response to - a request whose Request-URI scheme was not SIP, but the scheme - in the original received request was SIP or SIPS (that is, the - proxy changed the scheme from SIP or SIPS to something else - when it proxied a request), the proxy SHOULD add a new URI to - the target set. This URI SHOULD be a SIP URI version of the - non-SIP URI that was just tried. In the case of the tel URL, - this is accomplished by placing the telephone-subscriber part - of the tel URL into the user part of the SIP URI, and setting - the hostpart to the domain where the prior request was sent. - See Section 19.1.6 for more detail on forming SIP URIs from tel - URLs. - - As with a 3xx response, if a proxy "recurses" on the 416 by - trying a SIP or SIPS URI instead, the 416 response SHOULD NOT - be added to the response context. - - 5. Check response for forwarding - - Until a final response has been sent on the server transaction, - the following responses MUST be forwarded immediately: - - - Any provisional response other than 100 (Trying) - - - Any 2xx response - - If a 6xx response is received, it is not immediately forwarded, - but the stateful proxy SHOULD cancel all client pending - transactions as described in Section 10, and it MUST NOT create - any new branches in this context. - - This is a change from RFC 2543, which mandated that the proxy - was to forward the 6xx response immediately. For an INVITE - transaction, this approach had the problem that a 2xx response - could arrive on another branch, in which case the proxy would - - - -Rosenberg, et. al. Standards Track [Page 109] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - have to forward the 2xx. The result was that the UAC could - receive a 6xx response followed by a 2xx response, which should - never be allowed to happen. Under the new rules, upon - receiving a 6xx, a proxy will issue a CANCEL request, which - will generally result in 487 responses from all outstanding - client transactions, and then at that point the 6xx is - forwarded upstream. - - After a final response has been sent on the server transaction, - the following responses MUST be forwarded immediately: - - - Any 2xx response to an INVITE request - - A stateful proxy MUST NOT immediately forward any other - responses. In particular, a stateful proxy MUST NOT forward - any 100 (Trying) response. Those responses that are candidates - for forwarding later as the "best" response have been gathered - as described in step "Add Response to Context". - - Any response chosen for immediate forwarding MUST be processed - as described in steps "Aggregate Authorization Header Field - Values" through "Record-Route". - - This step, combined with the next, ensures that a stateful - proxy will forward exactly one final response to a non-INVITE - request, and either exactly one non-2xx response or one or more - 2xx responses to an INVITE request. - - 6. Choosing the best response - - A stateful proxy MUST send a final response to a response - context's server transaction if no final responses have been - immediately forwarded by the above rules and all client - transactions in this response context have been terminated. - - The stateful proxy MUST choose the "best" final response among - those received and stored in the response context. - - If there are no final responses in the context, the proxy MUST - send a 408 (Request Timeout) response to the server - transaction. - - Otherwise, the proxy MUST forward a response from the responses - stored in the response context. It MUST choose from the 6xx - class responses if any exist in the context. If no 6xx class - responses are present, the proxy SHOULD choose from the lowest - response class stored in the response context. The proxy MAY - select any response within that chosen class. The proxy SHOULD - - - -Rosenberg, et. al. Standards Track [Page 110] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - give preference to responses that provide information affecting - resubmission of this request, such as 401, 407, 415, 420, and - 484 if the 4xx class is chosen. - - A proxy which receives a 503 (Service Unavailable) response - SHOULD NOT forward it upstream unless it can determine that any - subsequent requests it might proxy will also generate a 503. - In other words, forwarding a 503 means that the proxy knows it - cannot service any requests, not just the one for the Request- - URI in the request which generated the 503. If the only - response that was received is a 503, the proxy SHOULD generate - a 500 response and forward that upstream. - - The forwarded response MUST be processed as described in steps - "Aggregate Authorization Header Field Values" through "Record- - Route". - - For example, if a proxy forwarded a request to 4 locations, and - received 503, 407, 501, and 404 responses, it may choose to - forward the 407 (Proxy Authentication Required) response. - - 1xx and 2xx responses may be involved in the establishment of - dialogs. When a request does not contain a To tag, the To tag - in the response is used by the UAC to distinguish multiple - responses to a dialog creating request. A proxy MUST NOT - insert a tag into the To header field of a 1xx or 2xx response - if the request did not contain one. A proxy MUST NOT modify - the tag in the To header field of a 1xx or 2xx response. - - Since a proxy may not insert a tag into the To header field of - a 1xx response to a request that did not contain one, it cannot - issue non-100 provisional responses on its own. However, it - can branch the request to a UAS sharing the same element as the - proxy. This UAS can return its own provisional responses, - entering into an early dialog with the initiator of the - request. The UAS does not have to be a discreet process from - the proxy. It could be a virtual UAS implemented in the same - code space as the proxy. - - 3-6xx responses are delivered hop-by-hop. When issuing a 3-6xx - response, the element is effectively acting as a UAS, issuing - its own response, usually based on the responses received from - downstream elements. An element SHOULD preserve the To tag - when simply forwarding a 3-6xx response to a request that did - not contain a To tag. - - A proxy MUST NOT modify the To tag in any forwarded response to - a request that contains a To tag. - - - -Rosenberg, et. al. Standards Track [Page 111] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - While it makes no difference to the upstream elements if the - proxy replaced the To tag in a forwarded 3-6xx response, - preserving the original tag may assist with debugging. - - When the proxy is aggregating information from several - responses, choosing a To tag from among them is arbitrary, and - generating a new To tag may make debugging easier. This - happens, for instance, when combining 401 (Unauthorized) and - 407 (Proxy Authentication Required) challenges, or combining - Contact values from unencrypted and unauthenticated 3xx - responses. - - 7. Aggregate Authorization Header Field Values - - If the selected response is a 401 (Unauthorized) or 407 (Proxy - Authentication Required), the proxy MUST collect any WWW- - Authenticate and Proxy-Authenticate header field values from - all other 401 (Unauthorized) and 407 (Proxy Authentication - Required) responses received so far in this response context - and add them to this response without modification before - forwarding. The resulting 401 (Unauthorized) or 407 (Proxy - Authentication Required) response could have several WWW- - Authenticate AND Proxy-Authenticate header field values. - - This is necessary because any or all of the destinations the - request was forwarded to may have requested credentials. The - client needs to receive all of those challenges and supply - credentials for each of them when it retries the request. - Motivation for this behavior is provided in Section 26. - - 8. Record-Route - - If the selected response contains a Record-Route header field - value originally provided by this proxy, the proxy MAY choose - to rewrite the value before forwarding the response. This - allows the proxy to provide different URIs for itself to the - next upstream and downstream elements. A proxy may choose to - use this mechanism for any reason. For instance, it is useful - for multi-homed hosts. - - If the proxy received the request over TLS, and sent it out - over a non-TLS connection, the proxy MUST rewrite the URI in - the Record-Route header field to be a SIPS URI. If the proxy - received the request over a non-TLS connection, and sent it out - over TLS, the proxy MUST rewrite the URI in the Record-Route - header field to be a SIP URI. - - - - - -Rosenberg, et. al. Standards Track [Page 112] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The new URI provided by the proxy MUST satisfy the same - constraints on URIs placed in Record-Route header fields in - requests (see Step 4 of Section 16.6) with the following - modifications: - - The URI SHOULD NOT contain the transport parameter unless the - proxy has knowledge that the next upstream (as opposed to - downstream) element that will be in the path of subsequent - requests supports that transport. - - When a proxy does decide to modify the Record-Route header - field in the response, one of the operations it performs is - locating the Record-Route value that it had inserted. If the - request spiraled, and the proxy inserted a Record-Route value - in each iteration of the spiral, locating the correct value in - the response (which must be the proper iteration in the reverse - direction) is tricky. The rules above recommend that a proxy - wishing to rewrite Record-Route header field values insert - sufficiently distinct URIs into the Record-Route header field - so that the right one may be selected for rewriting. A - RECOMMENDED mechanism to achieve this is for the proxy to - append a unique identifier for the proxy instance to the user - portion of the URI. - - When the response arrives, the proxy modifies the first - Record-Route whose identifier matches the proxy instance. The - modification results in a URI without this piece of data - appended to the user portion of the URI. Upon the next - iteration, the same algorithm (find the topmost Record-Route - header field value with the parameter) will correctly extract - the next Record-Route header field value inserted by that - proxy. - - Not every response to a request to which a proxy adds a - Record-Route header field value will contain a Record-Route - header field. If the response does contain a Record-Route - header field, it will contain the value the proxy added. - - 9. Forward response - - After performing the processing described in steps "Aggregate - Authorization Header Field Values" through "Record-Route", the - proxy MAY perform any feature specific manipulations on the - selected response. The proxy MUST NOT add to, modify, or - remove the message body. Unless otherwise specified, the proxy - MUST NOT remove any header field values other than the Via - header field value discussed in Section 16.7 Item 3. In - particular, the proxy MUST NOT remove any "received" parameter - - - -Rosenberg, et. al. Standards Track [Page 113] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - it may have added to the next Via header field value while - processing the request associated with this response. The - proxy MUST pass the response to the server transaction - associated with the response context. This will result in the - response being sent to the location now indicated in the - topmost Via header field value. If the server transaction is - no longer available to handle the transmission, the element - MUST forward the response statelessly by sending it to the - server transport. The server transaction might indicate - failure to send the response or signal a timeout in its state - machine. These errors would be logged for diagnostic purposes - as appropriate, but the protocol requires no remedial action - from the proxy. - - The proxy MUST maintain the response context until all of its - associated transactions have been terminated, even after - forwarding a final response. - - 10. Generate CANCELs - - If the forwarded response was a final response, the proxy MUST - generate a CANCEL request for all pending client transactions - associated with this response context. A proxy SHOULD also - generate a CANCEL request for all pending client transactions - associated with this response context when it receives a 6xx - response. A pending client transaction is one that has - received a provisional response, but no final response (it is - in the proceeding state) and has not had an associated CANCEL - generated for it. Generating CANCEL requests is described in - Section 9.1. - - The requirement to CANCEL pending client transactions upon - forwarding a final response does not guarantee that an endpoint - will not receive multiple 200 (OK) responses to an INVITE. 200 - (OK) responses on more than one branch may be generated before - the CANCEL requests can be sent and processed. Further, it is - reasonable to expect that a future extension may override this - requirement to issue CANCEL requests. - -16.8 Processing Timer C - - If timer C should fire, the proxy MUST either reset the timer with - any value it chooses, or terminate the client transaction. If the - client transaction has received a provisional response, the proxy - MUST generate a CANCEL request matching that transaction. If the - client transaction has not received a provisional response, the proxy - MUST behave as if the transaction received a 408 (Request Timeout) - response. - - - -Rosenberg, et. al. Standards Track [Page 114] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Allowing the proxy to reset the timer allows the proxy to dynamically - extend the transaction's lifetime based on current conditions (such - as utilization) when the timer fires. - -16.9 Handling Transport Errors - - If the transport layer notifies a proxy of an error when it tries to - forward a request (see Section 18.4), the proxy MUST behave as if the - forwarded request received a 503 (Service Unavailable) response. - - If the proxy is notified of an error when forwarding a response, it - drops the response. The proxy SHOULD NOT cancel any outstanding - client transactions associated with this response context due to this - notification. - - If a proxy cancels its outstanding client transactions, a single - malicious or misbehaving client can cause all transactions to fail - through its Via header field. - -16.10 CANCEL Processing - - A stateful proxy MAY generate a CANCEL to any other request it has - generated at any time (subject to receiving a provisional response to - that request as described in section 9.1). A proxy MUST cancel any - pending client transactions associated with a response context when - it receives a matching CANCEL request. - - A stateful proxy MAY generate CANCEL requests for pending INVITE - client transactions based on the period specified in the INVITE's - Expires header field elapsing. However, this is generally - unnecessary since the endpoints involved will take care of signaling - the end of the transaction. - - While a CANCEL request is handled in a stateful proxy by its own - server transaction, a new response context is not created for it. - Instead, the proxy layer searches its existing response contexts for - the server transaction handling the request associated with this - CANCEL. If a matching response context is found, the element MUST - immediately return a 200 (OK) response to the CANCEL request. In - this case, the element is acting as a user agent server as defined in - Section 8.2. Furthermore, the element MUST generate CANCEL requests - for all pending client transactions in the context as described in - Section 16.7 step 10. - - If a response context is not found, the element does not have any - knowledge of the request to apply the CANCEL to. It MUST statelessly - forward the CANCEL request (it may have statelessly forwarded the - associated request previously). - - - -Rosenberg, et. al. Standards Track [Page 115] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -16.11 Stateless Proxy - - When acting statelessly, a proxy is a simple message forwarder. Much - of the processing performed when acting statelessly is the same as - when behaving statefully. The differences are detailed here. - - A stateless proxy does not have any notion of a transaction, or of - the response context used to describe stateful proxy behavior. - Instead, the stateless proxy takes messages, both requests and - responses, directly from the transport layer (See section 18). As a - result, stateless proxies do not retransmit messages on their own. - They do, however, forward all retransmissions they receive (they do - not have the ability to distinguish a retransmission from the - original message). Furthermore, when handling a request statelessly, - an element MUST NOT generate its own 100 (Trying) or any other - provisional response. - - A stateless proxy MUST validate a request as described in Section - 16.3 - - A stateless proxy MUST follow the request processing steps described - in Sections 16.4 through 16.5 with the following exception: - - o A stateless proxy MUST choose one and only one target from the - target set. This choice MUST only rely on fields in the - message and time-invariant properties of the server. In - particular, a retransmitted request MUST be forwarded to the - same destination each time it is processed. Furthermore, - CANCEL and non-Routed ACK requests MUST generate the same - choice as their associated INVITE. - - A stateless proxy MUST follow the request processing steps described - in Section 16.6 with the following exceptions: - - o The requirement for unique branch IDs across space and time - applies to stateless proxies as well. However, a stateless - proxy cannot simply use a random number generator to compute - the first component of the branch ID, as described in Section - 16.6 bullet 8. This is because retransmissions of a request - need to have the same value, and a stateless proxy cannot tell - a retransmission from the original request. Therefore, the - component of the branch parameter that makes it unique MUST be - the same each time a retransmitted request is forwarded. Thus - for a stateless proxy, the branch parameter MUST be computed as - a combinatoric function of message parameters which are - invariant on retransmission. - - - - - -Rosenberg, et. al. Standards Track [Page 116] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The stateless proxy MAY use any technique it likes to guarantee - uniqueness of its branch IDs across transactions. However, the - following procedure is RECOMMENDED. The proxy examines the - branch ID in the topmost Via header field of the received - request. If it begins with the magic cookie, the first - component of the branch ID of the outgoing request is computed - as a hash of the received branch ID. Otherwise, the first - component of the branch ID is computed as a hash of the topmost - Via, the tag in the To header field, the tag in the From header - field, the Call-ID header field, the CSeq number (but not - method), and the Request-URI from the received request. One of - these fields will always vary across two different - transactions. - - o All other message transformations specified in Section 16.6 - MUST result in the same transformation of a retransmitted - request. In particular, if the proxy inserts a Record-Route - value or pushes URIs into the Route header field, it MUST place - the same values in retransmissions of the request. As for the - Via branch parameter, this implies that the transformations - MUST be based on time-invariant configuration or - retransmission-invariant properties of the request. - - o A stateless proxy determines where to forward the request as - described for stateful proxies in Section 16.6 Item 10. The - request is sent directly to the transport layer instead of - through a client transaction. - - Since a stateless proxy must forward retransmitted requests to - the same destination and add identical branch parameters to - each of them, it can only use information from the message - itself and time-invariant configuration data for those - calculations. If the configuration state is not time-invariant - (for example, if a routing table is updated) any requests that - could be affected by the change may not be forwarded - statelessly during an interval equal to the transaction timeout - window before or after the change. The method of processing - the affected requests in that interval is an implementation - decision. A common solution is to forward them transaction - statefully. - - Stateless proxies MUST NOT perform special processing for CANCEL - requests. They are processed by the above rules as any other - requests. In particular, a stateless proxy applies the same Route - header field processing to CANCEL requests that it applies to any - other request. - - - - - -Rosenberg, et. al. Standards Track [Page 117] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Response processing as described in Section 16.7 does not apply to a - proxy behaving statelessly. When a response arrives at a stateless - proxy, the proxy MUST inspect the sent-by value in the first - (topmost) Via header field value. If that address matches the proxy, - (it equals a value this proxy has inserted into previous requests) - the proxy MUST remove that header field value from the response and - forward the result to the location indicated in the next Via header - field value. The proxy MUST NOT add to, modify, or remove the - message body. Unless specified otherwise, the proxy MUST NOT remove - any other header field values. If the address does not match the - proxy, the message MUST be silently discarded. - -16.12 Summary of Proxy Route Processing - - In the absence of local policy to the contrary, the processing a - proxy performs on a request containing a Route header field can be - summarized in the following steps. - - 1. The proxy will inspect the Request-URI. If it indicates a - resource owned by this proxy, the proxy will replace it with - the results of running a location service. Otherwise, the - proxy will not change the Request-URI. - - 2. The proxy will inspect the URI in the topmost Route header - field value. If it indicates this proxy, the proxy removes it - from the Route header field (this route node has been - reached). - - 3. The proxy will forward the request to the resource indicated - by the URI in the topmost Route header field value or in the - Request-URI if no Route header field is present. The proxy - determines the address, port and transport to use when - forwarding the request by applying the procedures in [4] to - that URI. - - If no strict-routing elements are encountered on the path of the - request, the Request-URI will always indicate the target of the - request. - -16.12.1 Examples - -16.12.1.1 Basic SIP Trapezoid - - This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with - both proxies record-routing. Here is the flow. - - - - - - -Rosenberg, et. al. Standards Track [Page 118] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - U1 sends: - - INVITE sip:callee@domain.com SIP/2.0 - Contact: sip:caller@u1.example.com - - to P1. P1 is an outbound proxy. P1 is not responsible for - domain.com, so it looks it up in DNS and sends it there. It also - adds a Record-Route header field value: - - INVITE sip:callee@domain.com SIP/2.0 - Contact: sip:caller@u1.example.com - Record-Route: - - P2 gets this. It is responsible for domain.com so it runs a location - service and rewrites the Request-URI. It also adds a Record-Route - header field value. There is no Route header field, so it resolves - the new Request-URI to determine where to send the request: - - INVITE sip:callee@u2.domain.com SIP/2.0 - Contact: sip:caller@u1.example.com - Record-Route: - Record-Route: - - The callee at u2.domain.com gets this and responds with a 200 OK: - - SIP/2.0 200 OK - Contact: sip:callee@u2.domain.com - Record-Route: - Record-Route: - - The callee at u2 also sets its dialog state's remote target URI to - sip:caller@u1.example.com and its route set to: - - (,) - - This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its - dialog state's remote target URI to sip:callee@u2.domain.com and its - route set to: - - (,) - - Since all the route set elements contain the lr parameter, U1 - constructs the following BYE request: - - BYE sip:callee@u2.domain.com SIP/2.0 - Route: , - - - - - -Rosenberg, et. al. Standards Track [Page 119] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - As any other element (including proxies) would do, it resolves the - URI in the topmost Route header field value using DNS to determine - where to send the request. This goes to P1. P1 notices that it is - not responsible for the resource indicated in the Request-URI so it - doesn't change it. It does see that it is the first value in the - Route header field, so it removes that value, and forwards the - request to P2: - - BYE sip:callee@u2.domain.com SIP/2.0 - Route: - - P2 also notices it is not responsible for the resource indicated by - the Request-URI (it is responsible for domain.com, not - u2.domain.com), so it doesn't change it. It does see itself in the - first Route header field value, so it removes it and forwards the - following to u2.domain.com based on a DNS lookup against the - Request-URI: - - BYE sip:callee@u2.domain.com SIP/2.0 - -16.12.1.2 Traversing a Strict-Routing Proxy - - In this scenario, a dialog is established across four proxies, each - of which adds Record-Route header field values. The third proxy - implements the strict-routing procedures specified in RFC 2543 and - many works in progress. - - U1->P1->P2->P3->P4->U2 - - The INVITE arriving at U2 contains: - - INVITE sip:callee@u2.domain.com SIP/2.0 - Contact: sip:caller@u1.example.com - Record-Route: - Record-Route: - Record-Route: - Record-Route: - - Which U2 responds to with a 200 OK. Later, U2 sends the following - BYE request to P4 based on the first Route header field value. - - BYE sip:caller@u1.example.com SIP/2.0 - Route: - Route: - Route: - Route: - - - - - -Rosenberg, et. al. Standards Track [Page 120] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - P4 is not responsible for the resource indicated in the Request-URI - so it will leave it alone. It notices that it is the element in the - first Route header field value so it removes it. It then prepares to - send the request based on the now first Route header field value of - sip:p3.middle.com, but it notices that this URI does not contain the - lr parameter, so before sending, it reformats the request to be: - - BYE sip:p3.middle.com SIP/2.0 - Route: - Route: - Route: - - P3 is a strict router, so it forwards the following to P2: - - BYE sip:p2.example.com;lr SIP/2.0 - Route: - Route: - - P2 sees the request-URI is a value it placed into a Record-Route - header field, so before further processing, it rewrites the request - to be: - - BYE sip:caller@u1.example.com SIP/2.0 - Route: - - P2 is not responsible for u1.example.com, so it sends the request to - P1 based on the resolution of the Route header field value. - - P1 notices itself in the topmost Route header field value, so it - removes it, resulting in: - - BYE sip:caller@u1.example.com SIP/2.0 - - Since P1 is not responsible for u1.example.com and there is no Route - header field, P1 will forward the request to u1.example.com based on - the Request-URI. - -16.12.1.3 Rewriting Record-Route Header Field Values - - In this scenario, U1 and U2 are in different private namespaces and - they enter a dialog through a proxy P1, which acts as a gateway - between the namespaces. - - U1->P1->U2 - - - - - - - -Rosenberg, et. al. Standards Track [Page 121] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - U1 sends: - - INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0 - Contact: - - P1 uses its location service and sends the following to U2: - - INVITE sip:callee@rightprivatespace.com SIP/2.0 - Contact: - Record-Route: - - U2 sends this 200 (OK) back to P1: - - SIP/2.0 200 OK - Contact: - Record-Route: - - P1 rewrites its Record-Route header parameter to provide a value that - U1 will find useful, and sends the following to U1: - - SIP/2.0 200 OK - Contact: - Record-Route: - - Later, U1 sends the following BYE request to P1: - - BYE sip:callee@u2.rightprivatespace.com SIP/2.0 - Route: - - which P1 forwards to U2 as: - - BYE sip:callee@u2.rightprivatespace.com SIP/2.0 - -17 Transactions - - SIP is a transactional protocol: interactions between components take - place in a series of independent message exchanges. Specifically, a - SIP transaction consists of a single request and any responses to - that request, which include zero or more provisional responses and - one or more final responses. In the case of a transaction where the - request was an INVITE (known as an INVITE transaction), the - transaction also includes the ACK only if the final response was not - a 2xx response. If the response was a 2xx, the ACK is not considered - part of the transaction. - - The reason for this separation is rooted in the importance of - delivering all 200 (OK) responses to an INVITE to the UAC. To - deliver them all to the UAC, the UAS alone takes responsibility - - - -Rosenberg, et. al. Standards Track [Page 122] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - for retransmitting them (see Section 13.3.1.4), and the UAC alone - takes responsibility for acknowledging them with ACK (see Section - 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is - effectively considered its own transaction. - - Transactions have a client side and a server side. The client side - is known as a client transaction and the server side as a server - transaction. The client transaction sends the request, and the - server transaction sends the response. The client and server - transactions are logical functions that are embedded in any number of - elements. Specifically, they exist within user agents and stateful - proxy servers. Consider the example in Section 4. In this example, - the UAC executes the client transaction, and its outbound proxy - executes the server transaction. The outbound proxy also executes a - client transaction, which sends the request to a server transaction - in the inbound proxy. That proxy also executes a client transaction, - which in turn sends the request to a server transaction in the UAS. - This is shown in Figure 4. - - +---------+ +---------+ +---------+ +---------+ - | +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ | - | |C||------->||S| |C||------->||S| |C||------->||S| | - | |l|| ||e| |l|| ||e| |l|| ||e| | - | |i|| ||r| |i|| ||r| |i|| ||r| | - | |e|| ||v| |e|| ||v| |e|| ||v| | - | |n|| ||e| |n|| ||e| |n|| ||e| | - | |t|| ||r| |t|| ||r| |t|| ||r| | - | | || || | | || || | | || || | | - | |T|| ||T| |T|| ||T| |T|| ||T| | - | |r|| ||r| |r|| ||r| |r|| ||r| | - | |a|| ||a| |a|| ||a| |a|| ||a| | - | |n|| ||n| |n|| ||n| |n|| ||n| | - | |s||Response||s| |s||Response||s| |s||Response||s| | - | +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ | - +---------+ +---------+ +---------+ +---------+ - UAC Outbound Inbound UAS - Proxy Proxy - - Figure 4: Transaction relationships - - A stateless proxy does not contain a client or server transaction. - The transaction exists between the UA or stateful proxy on one side, - and the UA or stateful proxy on the other side. As far as SIP - transactions are concerned, stateless proxies are effectively - transparent. The purpose of the client transaction is to receive a - request from the element in which the client is embedded (call this - element the "Transaction User" or TU; it can be a UA or a stateful - proxy), and reliably deliver the request to a server transaction. - - - -Rosenberg, et. al. Standards Track [Page 123] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The client transaction is also responsible for receiving responses - and delivering them to the TU, filtering out any response - retransmissions or disallowed responses (such as a response to ACK). - Additionally, in the case of an INVITE request, the client - transaction is responsible for generating the ACK request for any - final response accepting a 2xx response. - - Similarly, the purpose of the server transaction is to receive - requests from the transport layer and deliver them to the TU. The - server transaction filters any request retransmissions from the - network. The server transaction accepts responses from the TU and - delivers them to the transport layer for transmission over the - network. In the case of an INVITE transaction, it absorbs the ACK - request for any final response excepting a 2xx response. - - The 2xx response and its ACK receive special treatment. This - response is retransmitted only by a UAS, and its ACK generated only - by the UAC. This end-to-end treatment is needed so that a caller - knows the entire set of users that have accepted the call. Because - of this special handling, retransmissions of the 2xx response are - handled by the UA core, not the transaction layer. Similarly, - generation of the ACK for the 2xx is handled by the UA core. Each - proxy along the path merely forwards each 2xx response to INVITE and - its corresponding ACK. - -17.1 Client Transaction - - The client transaction provides its functionality through the - maintenance of a state machine. - - The TU communicates with the client transaction through a simple - interface. When the TU wishes to initiate a new transaction, it - creates a client transaction and passes it the SIP request to send - and an IP address, port, and transport to which to send it. The - client transaction begins execution of its state machine. Valid - responses are passed up to the TU from the client transaction. - - There are two types of client transaction state machines, depending - on the method of the request passed by the TU. One handles client - transactions for INVITE requests. This type of machine is referred - to as an INVITE client transaction. Another type handles client - transactions for all requests except INVITE and ACK. This is - referred to as a non-INVITE client transaction. There is no client - transaction for ACK. If the TU wishes to send an ACK, it passes one - directly to the transport layer for transmission. - - - - - - -Rosenberg, et. al. Standards Track [Page 124] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The INVITE transaction is different from those of other methods - because of its extended duration. Normally, human input is required - in order to respond to an INVITE. The long delays expected for - sending a response argue for a three-way handshake. On the other - hand, requests of other methods are expected to complete rapidly. - Because of the non-INVITE transaction's reliance on a two-way - handshake, TUs SHOULD respond immediately to non-INVITE requests. - -17.1.1 INVITE Client Transaction - -17.1.1.1 Overview of INVITE Transaction - - The INVITE transaction consists of a three-way handshake. The client - transaction sends an INVITE, the server transaction sends responses, - and the client transaction sends an ACK. For unreliable transports - (such as UDP), the client transaction retransmits requests at an - interval that starts at T1 seconds and doubles after every - retransmission. T1 is an estimate of the round-trip time (RTT), and - it defaults to 500 ms. Nearly all of the transaction timers - described here scale with T1, and changing T1 adjusts their values. - The request is not retransmitted over reliable transports. After - receiving a 1xx response, any retransmissions cease altogether, and - the client waits for further responses. The server transaction can - send additional 1xx responses, which are not transmitted reliably by - the server transaction. Eventually, the server transaction decides - to send a final response. For unreliable transports, that response - is retransmitted periodically, and for reliable transports, it is - sent once. For each final response that is received at the client - transaction, the client transaction sends an ACK, the purpose of - which is to quench retransmissions of the response. - -17.1.1.2 Formal Description - - The state machine for the INVITE client transaction is shown in - Figure 5. The initial state, "calling", MUST be entered when the TU - initiates a new client transaction with an INVITE request. The - client transaction MUST pass the request to the transport layer for - transmission (see Section 18). If an unreliable transport is being - used, the client transaction MUST start timer A with a value of T1. - If a reliable transport is being used, the client transaction SHOULD - NOT start timer A (Timer A controls request retransmissions). For - any transport, the client transaction MUST start timer B with a value - of 64*T1 seconds (Timer B controls transaction timeouts). - - When timer A fires, the client transaction MUST retransmit the - request by passing it to the transport layer, and MUST reset the - timer with a value of 2*T1. The formal definition of retransmit - - - - -Rosenberg, et. al. Standards Track [Page 125] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - within the context of the transaction layer is to take the message - previously sent to the transport layer and pass it to the transport - layer once more. - - When timer A fires 2*T1 seconds later, the request MUST be - retransmitted again (assuming the client transaction is still in this - state). This process MUST continue so that the request is - retransmitted with intervals that double after each transmission. - These retransmissions SHOULD only be done while the client - transaction is in the "calling" state. - - The default value for T1 is 500 ms. T1 is an estimate of the RTT - between the client and server transactions. Elements MAY (though it - is NOT RECOMMENDED) use smaller values of T1 within closed, private - networks that do not permit general Internet connection. T1 MAY be - chosen larger, and this is RECOMMENDED if it is known in advance - (such as on high latency access links) that the RTT is larger. - Whatever the value of T1, the exponential backoffs on retransmissions - described in this section MUST be used. - - If the client transaction is still in the "Calling" state when timer - B fires, the client transaction SHOULD inform the TU that a timeout - has occurred. The client transaction MUST NOT generate an ACK. The - value of 64*T1 is equal to the amount of time required to send seven - requests in the case of an unreliable transport. - - If the client transaction receives a provisional response while in - the "Calling" state, it transitions to the "Proceeding" state. In the - "Proceeding" state, the client transaction SHOULD NOT retransmit the - request any longer. Furthermore, the provisional response MUST be - passed to the TU. Any further provisional responses MUST be passed - up to the TU while in the "Proceeding" state. - - When in either the "Calling" or "Proceeding" states, reception of a - response with status code from 300-699 MUST cause the client - transaction to transition to "Completed". The client transaction - MUST pass the received response up to the TU, and the client - transaction MUST generate an ACK request, even if the transport is - reliable (guidelines for constructing the ACK from the response are - given in Section 17.1.1.3) and then pass the ACK to the transport - layer for transmission. The ACK MUST be sent to the same address, - port, and transport to which the original request was sent. The - client transaction SHOULD start timer D when it enters the - "Completed" state, with a value of at least 32 seconds for unreliable - transports, and a value of zero seconds for reliable transports. - Timer D reflects the amount of time that the server transaction can - remain in the "Completed" state when unreliable transports are used. - This is equal to Timer H in the INVITE server transaction, whose - - - -Rosenberg, et. al. Standards Track [Page 126] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - default is 64*T1. However, the client transaction does not know the - value of T1 in use by the server transaction, so an absolute minimum - of 32s is used instead of basing Timer D on T1. - - Any retransmissions of the final response that are received while in - the "Completed" state MUST cause the ACK to be re-passed to the - transport layer for retransmission, but the newly received response - MUST NOT be passed up to the TU. A retransmission of the response is - defined as any response which would match the same client transaction - based on the rules of Section 17.1.3. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 127] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - |INVITE from TU - Timer A fires |INVITE sent - Reset A, V Timer B fires - INVITE sent +-----------+ or Transport Err. - +---------| |---------------+inform TU - | | Calling | | - +-------->| |-------------->| - +-----------+ 2xx | - | | 2xx to TU | - | |1xx | - 300-699 +---------------+ |1xx to TU | - ACK sent | | | -resp. to TU | 1xx V | - | 1xx to TU -----------+ | - | +---------| | | - | | |Proceeding |-------------->| - | +-------->| | 2xx | - | +-----------+ 2xx to TU | - | 300-699 | | - | ACK sent, | | - | resp. to TU| | - | | | NOTE: - | 300-699 V | - | ACK sent +-----------+Transport Err. | transitions - | +---------| |Inform TU | labeled with - | | | Completed |-------------->| the event - | +-------->| | | over the action - | +-----------+ | to take - | ^ | | - | | | Timer D fires | - +--------------+ | - | - | | - V | - +-----------+ | - | | | - | Terminated|<--------------+ - | | - +-----------+ - - Figure 5: INVITE client transaction - - If timer D fires while the client transaction is in the "Completed" - state, the client transaction MUST move to the terminated state. - - When in either the "Calling" or "Proceeding" states, reception of a - 2xx response MUST cause the client transaction to enter the - "Terminated" state, and the response MUST be passed up to the TU. - The handling of this response depends on whether the TU is a proxy - - - -Rosenberg, et. al. Standards Track [Page 128] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - core or a UAC core. A UAC core will handle generation of the ACK for - this response, while a proxy core will always forward the 200 (OK) - upstream. The differing treatment of 200 (OK) between proxy and UAC - is the reason that handling of it does not take place in the - transaction layer. - - The client transaction MUST be destroyed the instant it enters the - "Terminated" state. This is actually necessary to guarantee correct - operation. The reason is that 2xx responses to an INVITE are treated - differently; each one is forwarded by proxies, and the ACK handling - in a UAC is different. Thus, each 2xx needs to be passed to a proxy - core (so that it can be forwarded) and to a UAC core (so it can be - acknowledged). No transaction layer processing takes place. - Whenever a response is received by the transport, if the transport - layer finds no matching client transaction (using the rules of - Section 17.1.3), the response is passed directly to the core. Since - the matching client transaction is destroyed by the first 2xx, - subsequent 2xx will find no match and therefore be passed to the - core. - -17.1.1.3 Construction of the ACK Request - - This section specifies the construction of ACK requests sent within - the client transaction. A UAC core that generates an ACK for 2xx - MUST instead follow the rules described in Section 13. - - The ACK request constructed by the client transaction MUST contain - values for the Call-ID, From, and Request-URI that are equal to the - values of those header fields in the request passed to the transport - by the client transaction (call this the "original request"). The To - header field in the ACK MUST equal the To header field in the - response being acknowledged, and therefore will usually differ from - the To header field in the original request by the addition of the - tag parameter. The ACK MUST contain a single Via header field, and - this MUST be equal to the top Via header field of the original - request. The CSeq header field in the ACK MUST contain the same - value for the sequence number as was present in the original request, - but the method parameter MUST be equal to "ACK". - - - - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 129] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - If the INVITE request whose response is being acknowledged had Route - header fields, those header fields MUST appear in the ACK. This is - to ensure that the ACK can be routed properly through any downstream - stateless proxies. - - Although any request MAY contain a body, a body in an ACK is special - since the request cannot be rejected if the body is not understood. - Therefore, placement of bodies in ACK for non-2xx is NOT RECOMMENDED, - but if done, the body types are restricted to any that appeared in - the INVITE, assuming that the response to the INVITE was not 415. If - it was, the body in the ACK MAY be any type listed in the Accept - header field in the 415. - - For example, consider the following request: - - INVITE sip:bob@biloxi.com SIP/2.0 - Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff - To: Bob - From: Alice ;tag=88sja8x - Max-Forwards: 70 - Call-ID: 987asjd97y7atg - CSeq: 986759 INVITE - - The ACK request for a non-2xx final response to this request would - look like this: - - ACK sip:bob@biloxi.com SIP/2.0 - Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff - To: Bob ;tag=99sa0xk - From: Alice ;tag=88sja8x - Max-Forwards: 70 - Call-ID: 987asjd97y7atg - CSeq: 986759 ACK - -17.1.2 Non-INVITE Client Transaction - -17.1.2.1 Overview of the non-INVITE Transaction - - Non-INVITE transactions do not make use of ACK. They are simple - request-response interactions. For unreliable transports, requests - are retransmitted at an interval which starts at T1 and doubles until - it hits T2. If a provisional response is received, retransmissions - continue for unreliable transports, but at an interval of T2. The - server transaction retransmits the last response it sent, which can - be a provisional or final response, only when a retransmission of the - request is received. This is why request retransmissions need to - continue even after a provisional response; they are to ensure - reliable delivery of the final response. - - - -Rosenberg, et. al. Standards Track [Page 130] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Unlike an INVITE transaction, a non-INVITE transaction has no special - handling for the 2xx response. The result is that only a single 2xx - response to a non-INVITE is ever delivered to a UAC. - -17.1.2.2 Formal Description - - The state machine for the non-INVITE client transaction is shown in - Figure 6. It is very similar to the state machine for INVITE. - - The "Trying" state is entered when the TU initiates a new client - transaction with a request. When entering this state, the client - transaction SHOULD set timer F to fire in 64*T1 seconds. The request - MUST be passed to the transport layer for transmission. If an - unreliable transport is in use, the client transaction MUST set timer - E to fire in T1 seconds. If timer E fires while still in this state, - the timer is reset, but this time with a value of MIN(2*T1, T2). - When the timer fires again, it is reset to a MIN(4*T1, T2). This - process continues so that retransmissions occur with an exponentially - increasing interval that caps at T2. The default value of T2 is 4s, - and it represents the amount of time a non-INVITE server transaction - will take to respond to a request, if it does not respond - immediately. For the default values of T1 and T2, this results in - intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc. - - If Timer F fires while the client transaction is still in the - "Trying" state, the client transaction SHOULD inform the TU about the - timeout, and then it SHOULD enter the "Terminated" state. If a - provisional response is received while in the "Trying" state, the - response MUST be passed to the TU, and then the client transaction - SHOULD move to the "Proceeding" state. If a final response (status - codes 200-699) is received while in the "Trying" state, the response - MUST be passed to the TU, and the client transaction MUST transition - to the "Completed" state. - - If Timer E fires while in the "Proceeding" state, the request MUST be - passed to the transport layer for retransmission, and Timer E MUST be - reset with a value of T2 seconds. If timer F fires while in the - "Proceeding" state, the TU MUST be informed of a timeout, and the - client transaction MUST transition to the terminated state. If a - final response (status codes 200-699) is received while in the - "Proceeding" state, the response MUST be passed to the TU, and the - client transaction MUST transition to the "Completed" state. - - Once the client transaction enters the "Completed" state, it MUST set - Timer K to fire in T4 seconds for unreliable transports, and zero - seconds for reliable transports. The "Completed" state exists to - buffer any additional response retransmissions that may be received - (which is why the client transaction remains there only for - - - -Rosenberg, et. al. Standards Track [Page 131] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - unreliable transports). T4 represents the amount of time the network - will take to clear messages between client and server transactions. - The default value of T4 is 5s. A response is a retransmission when - it matches the same transaction, using the rules specified in Section - 17.1.3. If Timer K fires while in this state, the client transaction - MUST transition to the "Terminated" state. - - Once the transaction is in the terminated state, it MUST be destroyed - immediately. - -17.1.3 Matching Responses to Client Transactions - - When the transport layer in the client receives a response, it has to - determine which client transaction will handle the response, so that - the processing of Sections 17.1.1 and 17.1.2 can take place. The - branch parameter in the top Via header field is used for this - purpose. A response matches a client transaction under two - conditions: - - 1. If the response has the same value of the branch parameter in - the top Via header field as the branch parameter in the top - Via header field of the request that created the transaction. - - 2. If the method parameter in the CSeq header field matches the - method of the request that created the transaction. The - method is needed since a CANCEL request constitutes a - different transaction, but shares the same value of the branch - parameter. - - If a request is sent via multicast, it is possible that it will - generate multiple responses from different servers. These responses - will all have the same branch parameter in the topmost Via, but vary - in the To tag. The first response received, based on the rules - above, will be used, and others will be viewed as retransmissions. - That is not an error; multicast SIP provides only a rudimentary - "single-hop-discovery-like" service that is limited to processing a - single response. See Section 18.1.1 for details. - - - - - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 132] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -17.1.4 Handling Transport Errors - - |Request from TU - |send request - Timer E V - send request +-----------+ - +---------| |-------------------+ - | | Trying | Timer F | - +-------->| | or Transport Err.| - +-----------+ inform TU | - 200-699 | | | - resp. to TU | |1xx | - +---------------+ |resp. to TU | - | | | - | Timer E V Timer F | - | send req +-----------+ or Transport Err. | - | +---------| | inform TU | - | | |Proceeding |------------------>| - | +-------->| |-----+ | - | +-----------+ |1xx | - | | ^ |resp to TU | - | 200-699 | +--------+ | - | resp. to TU | | - | | | - | V | - | +-----------+ | - | | | | - | | Completed | | - | | | | - | +-----------+ | - | ^ | | - | | | Timer K | - +--------------+ | - | - | | - V | - NOTE: +-----------+ | - | | | - transitions | Terminated|<------------------+ - labeled with | | - the event +-----------+ - over the action - to take - - Figure 6: non-INVITE client transaction - - When the client transaction sends a request to the transport layer to - be sent, the following procedures are followed if the transport layer - indicates a failure. - - - -Rosenberg, et. al. Standards Track [Page 133] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The client transaction SHOULD inform the TU that a transport failure - has occurred, and the client transaction SHOULD transition directly - to the "Terminated" state. The TU will handle the failover - mechanisms described in [4]. - -17.2 Server Transaction - - The server transaction is responsible for the delivery of requests to - the TU and the reliable transmission of responses. It accomplishes - this through a state machine. Server transactions are created by the - core when a request is received, and transaction handling is desired - for that request (this is not always the case). - - As with the client transactions, the state machine depends on whether - the received request is an INVITE request. - -17.2.1 INVITE Server Transaction - - The state diagram for the INVITE server transaction is shown in - Figure 7. - - When a server transaction is constructed for a request, it enters the - "Proceeding" state. The server transaction MUST generate a 100 - (Trying) response unless it knows that the TU will generate a - provisional or final response within 200 ms, in which case it MAY - generate a 100 (Trying) response. This provisional response is - needed to quench request retransmissions rapidly in order to avoid - network congestion. The 100 (Trying) response is constructed - according to the procedures in Section 8.2.6, except that the - insertion of tags in the To header field of the response (when none - was present in the request) is downgraded from MAY to SHOULD NOT. - The request MUST be passed to the TU. - - The TU passes any number of provisional responses to the server - transaction. So long as the server transaction is in the - "Proceeding" state, each of these MUST be passed to the transport - layer for transmission. They are not sent reliably by the - transaction layer (they are not retransmitted by it) and do not cause - a change in the state of the server transaction. If a request - retransmission is received while in the "Proceeding" state, the most - recent provisional response that was received from the TU MUST be - passed to the transport layer for retransmission. A request is a - retransmission if it matches the same server transaction based on the - rules of Section 17.2.3. - - If, while in the "Proceeding" state, the TU passes a 2xx response to - the server transaction, the server transaction MUST pass this - response to the transport layer for transmission. It is not - - - -Rosenberg, et. al. Standards Track [Page 134] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - retransmitted by the server transaction; retransmissions of 2xx - responses are handled by the TU. The server transaction MUST then - transition to the "Terminated" state. - - While in the "Proceeding" state, if the TU passes a response with - status code from 300 to 699 to the server transaction, the response - MUST be passed to the transport layer for transmission, and the state - machine MUST enter the "Completed" state. For unreliable transports, - timer G is set to fire in T1 seconds, and is not set to fire for - reliable transports. - - This is a change from RFC 2543, where responses were always - retransmitted, even over reliable transports. - - When the "Completed" state is entered, timer H MUST be set to fire in - 64*T1 seconds for all transports. Timer H determines when the server - transaction abandons retransmitting the response. Its value is - chosen to equal Timer B, the amount of time a client transaction will - continue to retry sending a request. If timer G fires, the response - is passed to the transport layer once more for retransmission, and - timer G is set to fire in MIN(2*T1, T2) seconds. From then on, when - timer G fires, the response is passed to the transport again for - transmission, and timer G is reset with a value that doubles, unless - that value exceeds T2, in which case it is reset with the value of - T2. This is identical to the retransmit behavior for requests in the - "Trying" state of the non-INVITE client transaction. Furthermore, - while in the "Completed" state, if a request retransmission is - received, the server SHOULD pass the response to the transport for - retransmission. - - If an ACK is received while the server transaction is in the - "Completed" state, the server transaction MUST transition to the - "Confirmed" state. As Timer G is ignored in this state, any - retransmissions of the response will cease. - - If timer H fires while in the "Completed" state, it implies that the - ACK was never received. In this case, the server transaction MUST - transition to the "Terminated" state, and MUST indicate to the TU - that a transaction failure has occurred. - - - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 135] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - |INVITE - |pass INV to TU - INVITE V send 100 if TU won't in 200ms - send response+-----------+ - +--------| |--------+101-199 from TU - | | Proceeding| |send response - +------->| |<-------+ - | | Transport Err. - | | Inform TU - | |--------------->+ - +-----------+ | - 300-699 from TU | |2xx from TU | - send response | |send response | - | +------------------>+ - | | - INVITE V Timer G fires | - send response+-----------+ send response | - +--------| |--------+ | - | | Completed | | | - +------->| |<-------+ | - +-----------+ | - | | | - ACK | | | - - | +------------------>+ - | Timer H fires | - V or Transport Err.| - +-----------+ Inform TU | - | | | - | Confirmed | | - | | | - +-----------+ | - | | - |Timer I fires | - |- | - | | - V | - +-----------+ | - | | | - | Terminated|<---------------+ - | | - +-----------+ - - Figure 7: INVITE server transaction - - - - - - - - -Rosenberg, et. al. Standards Track [Page 136] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The purpose of the "Confirmed" state is to absorb any additional ACK - messages that arrive, triggered from retransmissions of the final - response. When this state is entered, timer I is set to fire in T4 - seconds for unreliable transports, and zero seconds for reliable - transports. Once timer I fires, the server MUST transition to the - "Terminated" state. - - Once the transaction is in the "Terminated" state, it MUST be - destroyed immediately. As with client transactions, this is needed - to ensure reliability of the 2xx responses to INVITE. - -17.2.2 Non-INVITE Server Transaction - - The state machine for the non-INVITE server transaction is shown in - Figure 8. - - The state machine is initialized in the "Trying" state and is passed - a request other than INVITE or ACK when initialized. This request is - passed up to the TU. Once in the "Trying" state, any further request - retransmissions are discarded. A request is a retransmission if it - matches the same server transaction, using the rules specified in - Section 17.2.3. - - While in the "Trying" state, if the TU passes a provisional response - to the server transaction, the server transaction MUST enter the - "Proceeding" state. The response MUST be passed to the transport - layer for transmission. Any further provisional responses that are - received from the TU while in the "Proceeding" state MUST be passed - to the transport layer for transmission. If a retransmission of the - request is received while in the "Proceeding" state, the most - recently sent provisional response MUST be passed to the transport - layer for retransmission. If the TU passes a final response (status - codes 200-699) to the server while in the "Proceeding" state, the - transaction MUST enter the "Completed" state, and the response MUST - be passed to the transport layer for transmission. - - When the server transaction enters the "Completed" state, it MUST set - Timer J to fire in 64*T1 seconds for unreliable transports, and zero - seconds for reliable transports. While in the "Completed" state, the - server transaction MUST pass the final response to the transport - layer for retransmission whenever a retransmission of the request is - received. Any other final responses passed by the TU to the server - transaction MUST be discarded while in the "Completed" state. The - server transaction remains in this state until Timer J fires, at - which point it MUST transition to the "Terminated" state. - - The server transaction MUST be destroyed the instant it enters the - "Terminated" state. - - - -Rosenberg, et. al. Standards Track [Page 137] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -17.2.3 Matching Requests to Server Transactions - - When a request is received from the network by the server, it has to - be matched to an existing transaction. This is accomplished in the - following manner. - - The branch parameter in the topmost Via header field of the request - is examined. If it is present and begins with the magic cookie - "z9hG4bK", the request was generated by a client transaction - compliant to this specification. Therefore, the branch parameter - will be unique across all transactions sent by that client. The - request matches a transaction if: - - 1. the branch parameter in the request is equal to the one in the - top Via header field of the request that created the - transaction, and - - 2. the sent-by value in the top Via of the request is equal to the - one in the request that created the transaction, and - - 3. the method of the request matches the one that created the - transaction, except for ACK, where the method of the request - that created the transaction is INVITE. - - This matching rule applies to both INVITE and non-INVITE transactions - alike. - - The sent-by value is used as part of the matching process because - there could be accidental or malicious duplication of branch - parameters from different clients. - - If the branch parameter in the top Via header field is not present, - or does not contain the magic cookie, the following procedures are - used. These exist to handle backwards compatibility with RFC 2543 - compliant implementations. - - The INVITE request matches a transaction if the Request-URI, To tag, - From tag, Call-ID, CSeq, and top Via header field match those of the - INVITE request which created the transaction. In this case, the - INVITE is a retransmission of the original one that created the - transaction. The ACK request matches a transaction if the Request- - URI, From tag, Call-ID, CSeq number (not the method), and top Via - header field match those of the INVITE request which created the - transaction, and the To tag of the ACK matches the To tag of the - response sent by the server transaction. Matching is done based on - the matching rules defined for each of those header fields. - Inclusion of the tag in the To header field in the ACK matching - process helps disambiguate ACK for 2xx from ACK for other responses - - - -Rosenberg, et. al. Standards Track [Page 138] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - at a proxy, which may have forwarded both responses (This can occur - in unusual conditions. Specifically, when a proxy forked a request, - and then crashes, the responses may be delivered to another proxy, - which might end up forwarding multiple responses upstream). An ACK - request that matches an INVITE transaction matched by a previous ACK - is considered a retransmission of that previous ACK. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 139] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - |Request received - |pass to TU - V - +-----------+ - | | - | Trying |-------------+ - | | | - +-----------+ |200-699 from TU - | |send response - |1xx from TU | - |send response | - | | - Request V 1xx from TU | - send response+-----------+send response| - +--------| |--------+ | - | | Proceeding| | | - +------->| |<-------+ | - +<--------------| | | - |Trnsprt Err +-----------+ | - |Inform TU | | - | | | - | |200-699 from TU | - | |send response | - | Request V | - | send response+-----------+ | - | +--------| | | - | | | Completed |<------------+ - | +------->| | - +<--------------| | - |Trnsprt Err +-----------+ - |Inform TU | - | |Timer J fires - | |- - | | - | V - | +-----------+ - | | | - +-------------->| Terminated| - | | - +-----------+ - - Figure 8: non-INVITE server transaction - - For all other request methods, a request is matched to a transaction - if the Request-URI, To tag, From tag, Call-ID, CSeq (including the - method), and top Via header field match those of the request that - created the transaction. Matching is done based on the matching - - - - -Rosenberg, et. al. Standards Track [Page 140] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - rules defined for each of those header fields. When a non-INVITE - request matches an existing transaction, it is a retransmission of - the request that created that transaction. - - Because the matching rules include the Request-URI, the server cannot - match a response to a transaction. When the TU passes a response to - the server transaction, it must pass it to the specific server - transaction for which the response is targeted. - -17.2.4 Handling Transport Errors - - When the server transaction sends a response to the transport layer - to be sent, the following procedures are followed if the transport - layer indicates a failure. - - First, the procedures in [4] are followed, which attempt to deliver - the response to a backup. If those should all fail, based on the - definition of failure in [4], the server transaction SHOULD inform - the TU that a failure has occurred, and SHOULD transition to the - terminated state. - -18 Transport - - The transport layer is responsible for the actual transmission of - requests and responses over network transports. This includes - determination of the connection to use for a request or response in - the case of connection-oriented transports. - - The transport layer is responsible for managing persistent - connections for transport protocols like TCP and SCTP, or TLS over - those, including ones opened to the transport layer. This includes - connections opened by the client or server transports, so that - connections are shared between client and server transport functions. - These connections are indexed by the tuple formed from the address, - port, and transport protocol at the far end of the connection. When - a connection is opened by the transport layer, this index is set to - the destination IP, port and transport. When the connection is - accepted by the transport layer, this index is set to the source IP - address, port number, and transport. Note that, because the source - port is often ephemeral, but it cannot be known whether it is - ephemeral or selected through procedures in [4], connections accepted - by the transport layer will frequently not be reused. The result is - that two proxies in a "peering" relationship using a connection- - oriented transport frequently will have two connections in use, one - for transactions initiated in each direction. - - - - - - -Rosenberg, et. al. Standards Track [Page 141] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - It is RECOMMENDED that connections be kept open for some - implementation-defined duration after the last message was sent or - received over that connection. This duration SHOULD at least equal - the longest amount of time the element would need in order to bring a - transaction from instantiation to the terminated state. This is to - make it likely that transactions are completed over the same - connection on which they are initiated (for example, request, - response, and in the case of INVITE, ACK for non-2xx responses). - This usually means at least 64*T1 (see Section 17.1.1.1 for a - definition of T1). However, it could be larger in an element that - has a TU using a large value for timer C (bullet 11 of Section 16.6), - for example. - - All SIP elements MUST implement UDP and TCP. SIP elements MAY - implement other protocols. - - Making TCP mandatory for the UA is a substantial change from RFC - 2543. It has arisen out of the need to handle larger messages, - which MUST use TCP, as discussed below. Thus, even if an element - never sends large messages, it may receive one and needs to be - able to handle them. - -18.1 Clients - -18.1.1 Sending Requests - - The client side of the transport layer is responsible for sending the - request and receiving responses. The user of the transport layer - passes the client transport the request, an IP address, port, - transport, and possibly TTL for multicast destinations. - - If a request is within 200 bytes of the path MTU, or if it is larger - than 1300 bytes and the path MTU is unknown, the request MUST be sent - using an RFC 2914 [43] congestion controlled transport protocol, such - as TCP. If this causes a change in the transport protocol from the - one indicated in the top Via, the value in the top Via MUST be - changed. This prevents fragmentation of messages over UDP and - provides congestion control for larger messages. However, - implementations MUST be able to handle messages up to the maximum - datagram packet size. For UDP, this size is 65,535 bytes, including - IP and UDP headers. - - The 200 byte "buffer" between the message size and the MTU - accommodates the fact that the response in SIP can be larger than - the request. This happens due to the addition of Record-Route - header field values to the responses to INVITE, for example. With - the extra buffer, the response can be about 170 bytes larger than - the request, and still not be fragmented on IPv4 (about 30 bytes - - - -Rosenberg, et. al. Standards Track [Page 142] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - is consumed by IP/UDP, assuming no IPSec). 1300 is chosen when - path MTU is not known, based on the assumption of a 1500 byte - Ethernet MTU. - - If an element sends a request over TCP because of these message size - constraints, and that request would have otherwise been sent over - UDP, if the attempt to establish the connection generates either an - ICMP Protocol Not Supported, or results in a TCP reset, the element - SHOULD retry the request, using UDP. This is only to provide - backwards compatibility with RFC 2543 compliant implementations that - do not support TCP. It is anticipated that this behavior will be - deprecated in a future revision of this specification. - - A client that sends a request to a multicast address MUST add the - "maddr" parameter to its Via header field value containing the - destination multicast address, and for IPv4, SHOULD add the "ttl" - parameter with a value of 1. Usage of IPv6 multicast is not defined - in this specification, and will be a subject of future - standardization when the need arises. - - These rules result in a purposeful limitation of multicast in SIP. - Its primary function is to provide a "single-hop-discovery-like" - service, delivering a request to a group of homogeneous servers, - where it is only required to process the response from any one of - them. This functionality is most useful for registrations. In fact, - based on the transaction processing rules in Section 17.1.3, the - client transaction will accept the first response, and view any - others as retransmissions because they all contain the same Via - branch identifier. - - Before a request is sent, the client transport MUST insert a value of - the "sent-by" field into the Via header field. This field contains - an IP address or host name, and port. The usage of an FQDN is - RECOMMENDED. This field is used for sending responses under certain - conditions, described below. If the port is absent, the default - value depends on the transport. It is 5060 for UDP, TCP and SCTP, - 5061 for TLS. - - For reliable transports, the response is normally sent on the - connection on which the request was received. Therefore, the client - transport MUST be prepared to receive the response on the same - connection used to send the request. Under error conditions, the - server may attempt to open a new connection to send the response. To - handle this case, the transport layer MUST also be prepared to - receive an incoming connection on the source IP address from which - the request was sent and port number in the "sent-by" field. It also - - - - - -Rosenberg, et. al. Standards Track [Page 143] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - MUST be prepared to receive incoming connections on any address and - port that would be selected by a server based on the procedures - described in Section 5 of [4]. - - For unreliable unicast transports, the client transport MUST be - prepared to receive responses on the source IP address from which the - request is sent (as responses are sent back to the source address) - and the port number in the "sent-by" field. Furthermore, as with - reliable transports, in certain cases the response will be sent - elsewhere. The client MUST be prepared to receive responses on any - address and port that would be selected by a server based on the - procedures described in Section 5 of [4]. - - For multicast, the client transport MUST be prepared to receive - responses on the same multicast group and port to which the request - is sent (that is, it needs to be a member of the multicast group it - sent the request to.) - - If a request is destined to an IP address, port, and transport to - which an existing connection is open, it is RECOMMENDED that this - connection be used to send the request, but another connection MAY be - opened and used. - - If a request is sent using multicast, it is sent to the group - address, port, and TTL provided by the transport user. If a request - is sent using unicast unreliable transports, it is sent to the IP - address and port provided by the transport user. - -18.1.2 Receiving Responses - - When a response is received, the client transport examines the top - Via header field value. If the value of the "sent-by" parameter in - that header field value does not correspond to a value that the - client transport is configured to insert into requests, the response - MUST be silently discarded. - - If there are any client transactions in existence, the client - transport uses the matching procedures of Section 17.1.3 to attempt - to match the response to an existing transaction. If there is a - match, the response MUST be passed to that transaction. Otherwise, - the response MUST be passed to the core (whether it be stateless - proxy, stateful proxy, or UA) for further processing. Handling of - these "stray" responses is dependent on the core (a proxy will - forward them, while a UA will discard, for example). - - - - - - - -Rosenberg, et. al. Standards Track [Page 144] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -18.2 Servers - -18.2.1 Receiving Requests - - A server SHOULD be prepared to receive requests on any IP address, - port and transport combination that can be the result of a DNS lookup - on a SIP or SIPS URI [4] that is handed out for the purposes of - communicating with that server. In this context, "handing out" - includes placing a URI in a Contact header field in a REGISTER - request or a redirect response, or in a Record-Route header field in - a request or response. A URI can also be "handed out" by placing it - on a web page or business card. It is also RECOMMENDED that a server - listen for requests on the default SIP ports (5060 for TCP and UDP, - 5061 for TLS over TCP) on all public interfaces. The typical - exception would be private networks, or when multiple server - instances are running on the same host. For any port and interface - that a server listens on for UDP, it MUST listen on that same port - and interface for TCP. This is because a message may need to be sent - using TCP, rather than UDP, if it is too large. As a result, the - converse is not true. A server need not listen for UDP on a - particular address and port just because it is listening on that same - address and port for TCP. There may, of course, be other reasons why - a server needs to listen for UDP on a particular address and port. - - When the server transport receives a request over any transport, it - MUST examine the value of the "sent-by" parameter in the top Via - header field value. If the host portion of the "sent-by" parameter - contains a domain name, or if it contains an IP address that differs - from the packet source address, the server MUST add a "received" - parameter to that Via header field value. This parameter MUST - contain the source address from which the packet was received. This - is to assist the server transport layer in sending the response, - since it must be sent to the source IP address from which the request - came. - - Consider a request received by the server transport which looks like, - in part: - - INVITE sip:bob@Biloxi.com SIP/2.0 - Via: SIP/2.0/UDP bobspc.biloxi.com:5060 - - The request is received with a source IP address of 192.0.2.4. - Before passing the request up, the transport adds a "received" - parameter, so that the request would look like, in part: - - INVITE sip:bob@Biloxi.com SIP/2.0 - Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4 - - - - -Rosenberg, et. al. Standards Track [Page 145] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Next, the server transport attempts to match the request to a server - transaction. It does so using the matching rules described in - Section 17.2.3. If a matching server transaction is found, the - request is passed to that transaction for processing. If no match is - found, the request is passed to the core, which may decide to - construct a new server transaction for that request. Note that when - a UAS core sends a 2xx response to INVITE, the server transaction is - destroyed. This means that when the ACK arrives, there will be no - matching server transaction, and based on this rule, the ACK is - passed to the UAS core, where it is processed. - -18.2.2 Sending Responses - - The server transport uses the value of the top Via header field in - order to determine where to send a response. It MUST follow the - following process: - - o If the "sent-protocol" is a reliable transport protocol such as - TCP or SCTP, or TLS over those, the response MUST be sent using - the existing connection to the source of the original request - that created the transaction, if that connection is still open. - This requires the server transport to maintain an association - between server transactions and transport connections. If that - connection is no longer open, the server SHOULD open a - connection to the IP address in the "received" parameter, if - present, using the port in the "sent-by" value, or the default - port for that transport, if no port is specified. If that - connection attempt fails, the server SHOULD use the procedures - in [4] for servers in order to determine the IP address and - port to open the connection and send the response to. - - o Otherwise, if the Via header field value contains a "maddr" - parameter, the response MUST be forwarded to the address listed - there, using the port indicated in "sent-by", or port 5060 if - none is present. If the address is a multicast address, the - response SHOULD be sent using the TTL indicated in the "ttl" - parameter, or with a TTL of 1 if that parameter is not present. - - o Otherwise (for unreliable unicast transports), if the top Via - has a "received" parameter, the response MUST be sent to the - address in the "received" parameter, using the port indicated - in the "sent-by" value, or using port 5060 if none is specified - explicitly. If this fails, for example, elicits an ICMP "port - unreachable" response, the procedures of Section 5 of [4] - SHOULD be used to determine where to send the response. - - - - - - -Rosenberg, et. al. Standards Track [Page 146] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - o Otherwise, if it is not receiver-tagged, the response MUST be - sent to the address indicated by the "sent-by" value, using the - procedures in Section 5 of [4]. - -18.3 Framing - - In the case of message-oriented transports (such as UDP), if the - message has a Content-Length header field, the message body is - assumed to contain that many bytes. If there are additional bytes in - the transport packet beyond the end of the body, they MUST be - discarded. If the transport packet ends before the end of the - message body, this is considered an error. If the message is a - response, it MUST be discarded. If the message is a request, the - element SHOULD generate a 400 (Bad Request) response. If the message - has no Content-Length header field, the message body is assumed to - end at the end of the transport packet. - - In the case of stream-oriented transports such as TCP, the Content- - Length header field indicates the size of the body. The Content- - Length header field MUST be used with stream oriented transports. - -18.4 Error Handling - - Error handling is independent of whether the message was a request or - response. - - If the transport user asks for a message to be sent over an - unreliable transport, and the result is an ICMP error, the behavior - depends on the type of ICMP error. Host, network, port or protocol - unreachable errors, or parameter problem errors SHOULD cause the - transport layer to inform the transport user of a failure in sending. - Source quench and TTL exceeded ICMP errors SHOULD be ignored. - - If the transport user asks for a request to be sent over a reliable - transport, and the result is a connection failure, the transport - layer SHOULD inform the transport user of a failure in sending. - -19 Common Message Components - - There are certain components of SIP messages that appear in various - places within SIP messages (and sometimes, outside of them) that - merit separate discussion. - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 147] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -19.1 SIP and SIPS Uniform Resource Indicators - - A SIP or SIPS URI identifies a communications resource. Like all - URIs, SIP and SIPS URIs may be placed in web pages, email messages, - or printed literature. They contain sufficient information to - initiate and maintain a communication session with the resource. - - Examples of communications resources include the following: - - o a user of an online service - - o an appearance on a multi-line phone - - o a mailbox on a messaging system - - o a PSTN number at a gateway service - - o a group (such as "sales" or "helpdesk") in an organization - - A SIPS URI specifies that the resource be contacted securely. This - means, in particular, that TLS is to be used between the UAC and the - domain that owns the URI. From there, secure communications are used - to reach the user, where the specific security mechanism depends on - the policy of the domain. Any resource described by a SIP URI can be - "upgraded" to a SIPS URI by just changing the scheme, if it is - desired to communicate with that resource securely. - -19.1.1 SIP and SIPS URI Components - - The "sip:" and "sips:" schemes follow the guidelines in RFC 2396 [5]. - They use a form similar to the mailto URL, allowing the specification - of SIP request-header fields and the SIP message-body. This makes it - possible to specify the subject, media type, or urgency of sessions - initiated by using a URI on a web page or in an email message. The - formal syntax for a SIP or SIPS URI is presented in Section 25. Its - general form, in the case of a SIP URI, is: - - sip:user:password@host:port;uri-parameters?headers - - The format for a SIPS URI is the same, except that the scheme is - "sips" instead of sip. These tokens, and some of the tokens in their - expansions, have the following meanings: - - user: The identifier of a particular resource at the host being - addressed. The term "host" in this context frequently refers - to a domain. The "userinfo" of a URI consists of this user - field, the password field, and the @ sign following them. The - userinfo part of a URI is optional and MAY be absent when the - - - -Rosenberg, et. al. Standards Track [Page 148] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - destination host does not have a notion of users or when the - host itself is the resource being identified. If the @ sign is - present in a SIP or SIPS URI, the user field MUST NOT be empty. - - If the host being addressed can process telephone numbers, for - instance, an Internet telephony gateway, a telephone- - subscriber field defined in RFC 2806 [9] MAY be used to - populate the user field. There are special escaping rules for - encoding telephone-subscriber fields in SIP and SIPS URIs - described in Section 19.1.2. - - password: A password associated with the user. While the SIP and - SIPS URI syntax allows this field to be present, its use is NOT - RECOMMENDED, because the passing of authentication information - in clear text (such as URIs) has proven to be a security risk - in almost every case where it has been used. For instance, - transporting a PIN number in this field exposes the PIN. - - Note that the password field is just an extension of the user - portion. Implementations not wishing to give special - significance to the password portion of the field MAY simply - treat "user:password" as a single string. - - host: The host providing the SIP resource. The host part contains - either a fully-qualified domain name or numeric IPv4 or IPv6 - address. Using the fully-qualified domain name form is - RECOMMENDED whenever possible. - - port: The port number where the request is to be sent. - - URI parameters: Parameters affecting a request constructed from - the URI. - - URI parameters are added after the hostport component and are - separated by semi-colons. - - URI parameters take the form: - - parameter-name "=" parameter-value - - Even though an arbitrary number of URI parameters may be - included in a URI, any given parameter-name MUST NOT appear - more than once. - - This extensible mechanism includes the transport, maddr, ttl, - user, method and lr parameters. - - - - - -Rosenberg, et. al. Standards Track [Page 149] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The transport parameter determines the transport mechanism to - be used for sending SIP messages, as specified in [4]. SIP can - use any network transport protocol. Parameter names are - defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP - (RFC 2960 [16]). For a SIPS URI, the transport parameter MUST - indicate a reliable transport. - - The maddr parameter indicates the server address to be - contacted for this user, overriding any address derived from - the host field. When an maddr parameter is present, the port - and transport components of the URI apply to the address - indicated in the maddr parameter value. [4] describes the - proper interpretation of the transport, maddr, and hostport in - order to obtain the destination address, port, and transport - for sending a request. - - The maddr field has been used as a simple form of loose source - routing. It allows a URI to specify a proxy that must be - traversed en-route to the destination. Continuing to use the - maddr parameter this way is strongly discouraged (the - mechanisms that enable it are deprecated). Implementations - should instead use the Route mechanism described in this - document, establishing a pre-existing route set if necessary - (see Section 8.1.1.1). This provides a full URI to describe - the node to be traversed. - - The ttl parameter determines the time-to-live value of the UDP - multicast packet and MUST only be used if maddr is a multicast - address and the transport protocol is UDP. For example, to - specify a call to alice@atlanta.com using multicast to - 239.255.255.1 with a ttl of 15, the following URI would be - used: - - sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15 - - The set of valid telephone-subscriber strings is a subset of - valid user strings. The user URI parameter exists to - distinguish telephone numbers from user names that happen to - look like telephone numbers. If the user string contains a - telephone number formatted as a telephone-subscriber, the user - parameter value "phone" SHOULD be present. Even without this - parameter, recipients of SIP and SIPS URIs MAY interpret the - pre-@ part as a telephone number if local restrictions on the - name space for user name allow it. - - The method of the SIP request constructed from the URI can be - specified with the method parameter. - - - - -Rosenberg, et. al. Standards Track [Page 150] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The lr parameter, when present, indicates that the element - responsible for this resource implements the routing mechanisms - specified in this document. This parameter will be used in the - URIs proxies place into Record-Route header field values, and - may appear in the URIs in a pre-existing route set. - - This parameter is used to achieve backwards compatibility with - systems implementing the strict-routing mechanisms of RFC 2543 - and the rfc2543bis drafts up to bis-05. An element preparing - to send a request based on a URI not containing this parameter - can assume the receiving element implements strict-routing and - reformat the message to preserve the information in the - Request-URI. - - Since the uri-parameter mechanism is extensible, SIP elements - MUST silently ignore any uri-parameters that they do not - understand. - - Headers: Header fields to be included in a request constructed - from the URI. - - Headers fields in the SIP request can be specified with the "?" - mechanism within a URI. The header names and values are - encoded in ampersand separated hname = hvalue pairs. The - special hname "body" indicates that the associated hvalue is - the message-body of the SIP request. - - Table 1 summarizes the use of SIP and SIPS URI components based on - the context in which the URI appears. The external column describes - URIs appearing anywhere outside of a SIP message, for instance on a - web page or business card. Entries marked "m" are mandatory, those - marked "o" are optional, and those marked "-" are not allowed. - Elements processing URIs SHOULD ignore any disallowed components if - they are present. The second column indicates the default value of - an optional element if it is not present. "--" indicates that the - element is either not optional, or has no default value. - - URIs in Contact header fields have different restrictions depending - on the context in which the header field appears. One set applies to - messages that establish and maintain dialogs (INVITE and its 200 (OK) - response). The other applies to registration and redirection - messages (REGISTER, its 200 (OK) response, and 3xx class responses to - any method). - - - - - - - - -Rosenberg, et. al. Standards Track [Page 151] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -19.1.2 Character Escaping Requirements - - dialog - reg./redir. Contact/ - default Req.-URI To From Contact R-R/Route external -user -- o o o o o o -password -- o o o o o o -host -- m m m m m m -port (1) o - - o o o -user-param ip o o o o o o -method INVITE - - - - - o -maddr-param -- o - - o o o -ttl-param 1 o - - o - o -transp.-param (2) o - - o o o -lr-param -- o - - - o o -other-param -- o o o o o o -headers -- - - - o - o - - (1): The default port value is transport and scheme dependent. The - default is 5060 for sip: using UDP, TCP, or SCTP. The default is - 5061 for sip: using TLS over TCP and sips: over TCP. - - (2): The default transport is scheme dependent. For sip:, it is UDP. - For sips:, it is TCP. - - Table 1: Use and default values of URI components for SIP header - field values, Request-URI and references - - SIP follows the requirements and guidelines of RFC 2396 [5] when - defining the set of characters that must be escaped in a SIP URI, and - uses its ""%" HEX HEX" mechanism for escaping. From RFC 2396 [5]: - - The set of characters actually reserved within any given URI - component is defined by that component. In general, a character - is reserved if the semantics of the URI changes if the character - is replaced with its escaped US-ASCII encoding [5]. Excluded US- - ASCII characters (RFC 2396 [5]), such as space and control - characters and characters used as URI delimiters, also MUST be - escaped. URIs MUST NOT contain unescaped space and control - characters. - - For each component, the set of valid BNF expansions defines exactly - which characters may appear unescaped. All other characters MUST be - escaped. - - For example, "@" is not in the set of characters in the user - component, so the user "j@s0n" must have at least the @ sign encoded, - as in "j%40s0n". - - - -Rosenberg, et. al. Standards Track [Page 152] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Expanding the hname and hvalue tokens in Section 25 show that all URI - reserved characters in header field names and values MUST be escaped. - - The telephone-subscriber subset of the user component has special - escaping considerations. The set of characters not reserved in the - RFC 2806 [9] description of telephone-subscriber contains a number of - characters in various syntax elements that need to be escaped when - used in SIP URIs. Any characters occurring in a telephone-subscriber - that do not appear in an expansion of the BNF for the user rule MUST - be escaped. - - Note that character escaping is not allowed in the host component of - a SIP or SIPS URI (the % character is not valid in its expansion). - This is likely to change in the future as requirements for - Internationalized Domain Names are finalized. Current - implementations MUST NOT attempt to improve robustness by treating - received escaped characters in the host component as literally - equivalent to their unescaped counterpart. The behavior required to - meet the requirements of IDN may be significantly different. - -19.1.3 Example SIP and SIPS URIs - - sip:alice@atlanta.com - sip:alice:secretword@atlanta.com;transport=tcp - sips:alice@atlanta.com?subject=project%20x&priority=urgent - sip:+1-212-555-1212:1234@gateway.com;user=phone - sips:1212@gateway.com - sip:alice@192.0.2.4 - sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com - sip:alice;day=tuesday@atlanta.com - - The last sample URI above has a user field value of - "alice;day=tuesday". The escaping rules defined above allow a - semicolon to appear unescaped in this field. For the purposes of - this protocol, the field is opaque. The structure of that value is - only useful to the SIP element responsible for the resource. - -19.1.4 URI Comparison - - Some operations in this specification require determining whether two - SIP or SIPS URIs are equivalent. In this specification, registrars - need to compare bindings in Contact URIs in REGISTER requests (see - Section 10.3.). SIP and SIPS URIs are compared for equality - according to the following rules: - - o A SIP and SIPS URI are never equivalent. - - - - - -Rosenberg, et. al. Standards Track [Page 153] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - o Comparison of the userinfo of SIP and SIPS URIs is case- - sensitive. This includes userinfo containing passwords or - formatted as telephone-subscribers. Comparison of all other - components of the URI is case-insensitive unless explicitly - defined otherwise. - - o The ordering of parameters and header fields is not significant - in comparing SIP and SIPS URIs. - - o Characters other than those in the "reserved" set (see RFC 2396 - [5]) are equivalent to their ""%" HEX HEX" encoding. - - o An IP address that is the result of a DNS lookup of a host name - does not match that host name. - - o For two URIs to be equal, the user, password, host, and port - components must match. - - A URI omitting the user component will not match a URI that - includes one. A URI omitting the password component will not - match a URI that includes one. - - A URI omitting any component with a default value will not - match a URI explicitly containing that component with its - default value. For instance, a URI omitting the optional port - component will not match a URI explicitly declaring port 5060. - The same is true for the transport-parameter, ttl-parameter, - user-parameter, and method components. - - Defining sip:user@host to not be equivalent to - sip:user@host:5060 is a change from RFC 2543. When deriving - addresses from URIs, equivalent addresses are expected from - equivalent URIs. The URI sip:user@host:5060 will always - resolve to port 5060. The URI sip:user@host may resolve to - other ports through the DNS SRV mechanisms detailed in [4]. - - o URI uri-parameter components are compared as follows: - - - Any uri-parameter appearing in both URIs must match. - - - A user, ttl, or method uri-parameter appearing in only one - URI never matches, even if it contains the default value. - - - A URI that includes an maddr parameter will not match a URI - that contains no maddr parameter. - - - All other uri-parameters appearing in only one URI are - ignored when comparing the URIs. - - - -Rosenberg, et. al. Standards Track [Page 154] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - o URI header components are never ignored. Any present header - component MUST be present in both URIs and match for the URIs - to match. The matching rules are defined for each header field - in Section 20. - - The URIs within each of the following sets are equivalent: - - sip:%61lice@atlanta.com;transport=TCP - sip:alice@AtLanTa.CoM;Transport=tcp - - sip:carol@chicago.com - sip:carol@chicago.com;newparam=5 - sip:carol@chicago.com;security=on - - sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com - sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com - - sip:alice@atlanta.com?subject=project%20x&priority=urgent - sip:alice@atlanta.com?priority=urgent&subject=project%20x - - The URIs within each of the following sets are not equivalent: - - SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames) - sip:alice@AtLanTa.CoM;Transport=UDP - - sip:bob@biloxi.com (can resolve to different ports) - sip:bob@biloxi.com:5060 - - sip:bob@biloxi.com (can resolve to different transports) - sip:bob@biloxi.com;transport=udp - - sip:bob@biloxi.com (can resolve to different port and transports) - sip:bob@biloxi.com:6000;transport=tcp - - sip:carol@chicago.com (different header component) - sip:carol@chicago.com?Subject=next%20meeting - - sip:bob@phone21.boxesbybob.com (even though that's what - sip:bob@192.0.2.4 phone21.boxesbybob.com resolves to) - - Note that equality is not transitive: - - o sip:carol@chicago.com and sip:carol@chicago.com;security=on are - equivalent - - o sip:carol@chicago.com and sip:carol@chicago.com;security=off - are equivalent - - - - -Rosenberg, et. al. Standards Track [Page 155] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - o sip:carol@chicago.com;security=on and - sip:carol@chicago.com;security=off are not equivalent - -19.1.5 Forming Requests from a URI - - An implementation needs to take care when forming requests directly - from a URI. URIs from business cards, web pages, and even from - sources inside the protocol such as registered contacts may contain - inappropriate header fields or body parts. - - An implementation MUST include any provided transport, maddr, ttl, or - user parameter in the Request-URI of the formed request. If the URI - contains a method parameter, its value MUST be used as the method of - the request. The method parameter MUST NOT be placed in the - Request-URI. Unknown URI parameters MUST be placed in the message's - Request-URI. - - An implementation SHOULD treat the presence of any headers or body - parts in the URI as a desire to include them in the message, and - choose to honor the request on a per-component basis. - - An implementation SHOULD NOT honor these obviously dangerous header - fields: From, Call-ID, CSeq, Via, and Record-Route. - - An implementation SHOULD NOT honor any requested Route header field - values in order to not be used as an unwitting agent in malicious - attacks. - - An implementation SHOULD NOT honor requests to include header fields - that may cause it to falsely advertise its location or capabilities. - These include: Accept, Accept-Encoding, Accept-Language, Allow, - Contact (in its dialog usage), Organization, Supported, and User- - Agent. - - An implementation SHOULD verify the accuracy of any requested - descriptive header fields, including: Content-Disposition, Content- - Encoding, Content-Language, Content-Length, Content-Type, Date, - Mime-Version, and Timestamp. - - If the request formed from constructing a message from a given URI is - not a valid SIP request, the URI is invalid. An implementation MUST - NOT proceed with transmitting the request. It should instead pursue - the course of action due an invalid URI in the context it occurs. - - The constructed request can be invalid in many ways. These - include, but are not limited to, syntax error in header fields, - invalid combinations of URI parameters, or an incorrect - description of the message body. - - - -Rosenberg, et. al. Standards Track [Page 156] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Sending a request formed from a given URI may require capabilities - unavailable to the implementation. The URI might indicate use of an - unimplemented transport or extension, for example. An implementation - SHOULD refuse to send these requests rather than modifying them to - match their capabilities. An implementation MUST NOT send a request - requiring an extension that it does not support. - - For example, such a request can be formed through the presence of - a Require header parameter or a method URI parameter with an - unknown or explicitly unsupported value. - -19.1.6 Relating SIP URIs and tel URLs - - When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the - entire telephone-subscriber portion of the tel URL, including any - parameters, is placed into the userinfo part of the SIP or SIPS URI. - - Thus, tel:+358-555-1234567;postd=pp22 becomes - - sip:+358-555-1234567;postd=pp22@foo.com;user=phone - - or - sips:+358-555-1234567;postd=pp22@foo.com;user=phone - - not - sip:+358-555-1234567@foo.com;postd=pp22;user=phone - - or - - sips:+358-555-1234567@foo.com;postd=pp22;user=phone - - In general, equivalent "tel" URLs converted to SIP or SIPS URIs in - this fashion may not produce equivalent SIP or SIPS URIs. The - userinfo of SIP and SIPS URIs are compared as a case-sensitive - string. Variance in case-insensitive portions of tel URLs and - reordering of tel URL parameters does not affect tel URL equivalence, - but does affect the equivalence of SIP URIs formed from them. - - For example, - - tel:+358-555-1234567;postd=pp22 - tel:+358-555-1234567;POSTD=PP22 - - are equivalent, while - - sip:+358-555-1234567;postd=pp22@foo.com;user=phone - sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone - - - - -Rosenberg, et. al. Standards Track [Page 157] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - are not. - - Likewise, - - tel:+358-555-1234567;postd=pp22;isub=1411 - tel:+358-555-1234567;isub=1411;postd=pp22 - - are equivalent, while - - sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone - sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone - - are not. - - To mitigate this problem, elements constructing telephone-subscriber - fields to place in the userinfo part of a SIP or SIPS URI SHOULD fold - any case-insensitive portion of telephone-subscriber to lower case, - and order the telephone-subscriber parameters lexically by parameter - name, excepting isdn-subaddress and post-dial, which occur first and - in that order. (All components of a tel URL except for future- - extension parameters are defined to be compared case-insensitive.) - - Following this suggestion, both - - tel:+358-555-1234567;postd=pp22 - tel:+358-555-1234567;POSTD=PP22 - - become - - sip:+358-555-1234567;postd=pp22@foo.com;user=phone - - and both - - tel:+358-555-1234567;tsp=a.b;phone-context=5 - tel:+358-555-1234567;phone-context=5;tsp=a.b - - become - - sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone - -19.2 Option Tags - - Option tags are unique identifiers used to designate new options - (extensions) in SIP. These tags are used in Require (Section 20.32), - Proxy-Require (Section 20.29), Supported (Section 20.37) and - Unsupported (Section 20.40) header fields. Note that these options - appear as parameters in those header fields in an option-tag = token - form (see Section 25 for the definition of token). - - - -Rosenberg, et. al. Standards Track [Page 158] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Option tags are defined in standards track RFCs. This is a change - from past practice, and is instituted to ensure continuing multi- - vendor interoperability (see discussion in Section 20.32 and Section - 20.37). An IANA registry of option tags is used to ensure easy - reference. - -19.3 Tags - - The "tag" parameter is used in the To and From header fields of SIP - messages. It serves as a general mechanism to identify a dialog, - which is the combination of the Call-ID along with two tags, one from - each participant in the dialog. When a UA sends a request outside of - a dialog, it contains a From tag only, providing "half" of the dialog - ID. The dialog is completed from the response(s), each of which - contributes the second half in the To header field. The forking of - SIP requests means that multiple dialogs can be established from a - single request. This also explains the need for the two-sided dialog - identifier; without a contribution from the recipients, the - originator could not disambiguate the multiple dialogs established - from a single request. - - When a tag is generated by a UA for insertion into a request or - response, it MUST be globally unique and cryptographically random - with at least 32 bits of randomness. A property of this selection - requirement is that a UA will place a different tag into the From - header of an INVITE than it would place into the To header of the - response to the same INVITE. This is needed in order for a UA to - invite itself to a session, a common case for "hairpinning" of calls - in PSTN gateways. Similarly, two INVITEs for different calls will - have different From tags, and two responses for different calls will - have different To tags. - - Besides the requirement for global uniqueness, the algorithm for - generating a tag is implementation-specific. Tags are helpful in - fault tolerant systems, where a dialog is to be recovered on an - alternate server after a failure. A UAS can select the tag in such a - way that a backup can recognize a request as part of a dialog on the - failed server, and therefore determine that it should attempt to - recover the dialog and any other state associated with it. - -20 Header Fields - - The general syntax for header fields is covered in Section 7.3. This - section lists the full set of header fields along with notes on - syntax, meaning, and usage. Throughout this section, we use [HX.Y] - to refer to Section X.Y of the current HTTP/1.1 specification RFC - 2616 [8]. Examples of each header field are given. - - - - -Rosenberg, et. al. Standards Track [Page 159] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Information about header fields in relation to methods and proxy - processing is summarized in Tables 2 and 3. - - The "where" column describes the request and response types in which - the header field can be used. Values in this column are: - - R: header field may only appear in requests; - - r: header field may only appear in responses; - - 2xx, 4xx, etc.: A numerical value or range indicates response - codes with which the header field can be used; - - c: header field is copied from the request to the response. - - An empty entry in the "where" column indicates that the header - field may be present in all requests and responses. - - The "proxy" column describes the operations a proxy may perform on a - header field: - - a: A proxy can add or concatenate the header field if not present. - - m: A proxy can modify an existing header field value. - - d: A proxy can delete a header field value. - - r: A proxy must be able to read the header field, and thus this - header field cannot be encrypted. - - The next six columns relate to the presence of a header field in a - method: - - c: Conditional; requirements on the header field depend on the - context of the message. - - m: The header field is mandatory. - - m*: The header field SHOULD be sent, but clients/servers need to - be prepared to receive messages without that header field. - - o: The header field is optional. - - t: The header field SHOULD be sent, but clients/servers need to be - prepared to receive messages without that header field. - - If a stream-based protocol (such as TCP) is used as a - transport, then the header field MUST be sent. - - - -Rosenberg, et. al. Standards Track [Page 160] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - *: The header field is required if the message body is not empty. - See Sections 20.14, 20.15 and 7.4 for details. - - -: The header field is not applicable. - - "Optional" means that an element MAY include the header field in a - request or response, and a UA MAY ignore the header field if present - in the request or response (The exception to this rule is the Require - header field discussed in 20.32). A "mandatory" header field MUST be - present in a request, and MUST be understood by the UAS receiving the - request. A mandatory response header field MUST be present in the - response, and the header field MUST be understood by the UAC - processing the response. "Not applicable" means that the header - field MUST NOT be present in a request. If one is placed in a - request by mistake, it MUST be ignored by the UAS receiving the - request. Similarly, a header field labeled "not applicable" for a - response means that the UAS MUST NOT place the header field in the - response, and the UAC MUST ignore the header field in the response. - - A UA SHOULD ignore extension header parameters that are not - understood. - - A compact form of some common header field names is also defined for - use when overall message size is an issue. - - The Contact, From, and To header fields contain a URI. If the URI - contains a comma, question mark or semicolon, the URI MUST be - enclosed in angle brackets (< and >). Any URI parameters are - contained within these brackets. If the URI is not enclosed in angle - brackets, any semicolon-delimited parameters are header-parameters, - not URI parameters. - -20.1 Accept - - The Accept header field follows the syntax defined in [H14.1]. The - semantics are also identical, with the exception that if no Accept - header field is present, the server SHOULD assume a default value of - application/sdp. - - An empty Accept header field means that no formats are acceptable. - - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 161] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Example: - - Header field where proxy ACK BYE CAN INV OPT REG - ___________________________________________________________ - Accept R - o - o m* o - Accept 2xx - - - o m* o - Accept 415 - c - c c c - Accept-Encoding R - o - o o o - Accept-Encoding 2xx - - - o m* o - Accept-Encoding 415 - c - c c c - Accept-Language R - o - o o o - Accept-Language 2xx - - - o m* o - Accept-Language 415 - c - c c c - Alert-Info R ar - - - o - - - Alert-Info 180 ar - - - o - - - Allow R - o - o o o - Allow 2xx - o - m* m* o - Allow r - o - o o o - Allow 405 - m - m m m - Authentication-Info 2xx - o - o o o - Authorization R o o o o o o - Call-ID c r m m m m m m - Call-Info ar - - - o o o - Contact R o - - m o o - Contact 1xx - - - o - - - Contact 2xx - - - m o o - Contact 3xx d - o - o o o - Contact 485 - o - o o o - Content-Disposition o o - o o o - Content-Encoding o o - o o o - Content-Language o o - o o o - Content-Length ar t t t t t t - Content-Type * * - * * * - CSeq c r m m m m m m - Date a o o o o o o - Error-Info 300-699 a - o o o o o - Expires - - - o - o - From c r m m m m m m - In-Reply-To R - - - o - - - Max-Forwards R amr m m m m m m - Min-Expires 423 - - - - - m - MIME-Version o o - o o o - Organization ar - - - o o o - - Table 2: Summary of header fields, A--O - - - - - - -Rosenberg, et. al. Standards Track [Page 162] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Header field where proxy ACK BYE CAN INV OPT REG - ___________________________________________________________________ - Priority R ar - - - o - - - Proxy-Authenticate 407 ar - m - m m m - Proxy-Authenticate 401 ar - o o o o o - Proxy-Authorization R dr o o - o o o - Proxy-Require R ar - o - o o o - Record-Route R ar o o o o o - - Record-Route 2xx,18x mr - o o o o - - Reply-To - - - o - - - Require ar - c - c c c - Retry-After 404,413,480,486 - o o o o o - 500,503 - o o o o o - 600,603 - o o o o o - Route R adr c c c c c c - Server r - o o o o o - Subject R - - - o - - - Supported R - o o m* o o - Supported 2xx - o o m* m* o - Timestamp o o o o o o - To c(1) r m m m m m m - Unsupported 420 - m - m m m - User-Agent o o o o o o - Via R amr m m m m m m - Via rc dr m m m m m m - Warning r - o o o o o - WWW-Authenticate 401 ar - m - m m m - WWW-Authenticate 407 ar - o - o o o - - Table 3: Summary of header fields, P--Z; (1): copied with possible - addition of tag - - Accept: application/sdp;level=1, application/x-private, text/html - -20.2 Accept-Encoding - - The Accept-Encoding header field is similar to Accept, but restricts - the content-codings [H3.5] that are acceptable in the response. See - [H14.3]. The semantics in SIP are identical to those defined in - [H14.3]. - - An empty Accept-Encoding header field is permissible. It is - equivalent to Accept-Encoding: identity, that is, only the identity - encoding, meaning no encoding, is permissible. - - If no Accept-Encoding header field is present, the server SHOULD - assume a default value of identity. - - - - -Rosenberg, et. al. Standards Track [Page 163] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - This differs slightly from the HTTP definition, which indicates that - when not present, any encoding can be used, but the identity encoding - is preferred. - - Example: - - Accept-Encoding: gzip - -20.3 Accept-Language - - The Accept-Language header field is used in requests to indicate the - preferred languages for reason phrases, session descriptions, or - status responses carried as message bodies in the response. If no - Accept-Language header field is present, the server SHOULD assume all - languages are acceptable to the client. - - The Accept-Language header field follows the syntax defined in - [H14.4]. The rules for ordering the languages based on the "q" - parameter apply to SIP as well. - - Example: - - Accept-Language: da, en-gb;q=0.8, en;q=0.7 - -20.4 Alert-Info - - When present in an INVITE request, the Alert-Info header field - specifies an alternative ring tone to the UAS. When present in a 180 - (Ringing) response, the Alert-Info header field specifies an - alternative ringback tone to the UAC. A typical usage is for a proxy - to insert this header field to provide a distinctive ring feature. - - The Alert-Info header field can introduce security risks. These - risks and the ways to handle them are discussed in Section 20.9, - which discusses the Call-Info header field since the risks are - identical. - - In addition, a user SHOULD be able to disable this feature - selectively. - - This helps prevent disruptions that could result from the use of - this header field by untrusted elements. - - Example: - - Alert-Info: - - - - - -Rosenberg, et. al. Standards Track [Page 164] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -20.5 Allow - - The Allow header field lists the set of methods supported by the UA - generating the message. - - All methods, including ACK and CANCEL, understood by the UA MUST be - included in the list of methods in the Allow header field, when - present. The absence of an Allow header field MUST NOT be - interpreted to mean that the UA sending the message supports no - methods. Rather, it implies that the UA is not providing any - information on what methods it supports. - - Supplying an Allow header field in responses to methods other than - OPTIONS reduces the number of messages needed. - - Example: - - Allow: INVITE, ACK, OPTIONS, CANCEL, BYE - -20.6 Authentication-Info - - The Authentication-Info header field provides for mutual - authentication with HTTP Digest. A UAS MAY include this header field - in a 2xx response to a request that was successfully authenticated - using digest based on the Authorization header field. - - Syntax and semantics follow those specified in RFC 2617 [17]. - - Example: - - Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c" - -20.7 Authorization - - The Authorization header field contains authentication credentials of - a UA. Section 22.2 overviews the use of the Authorization header - field, and Section 22.4 describes the syntax and semantics when used - with HTTP authentication. - - This header field, along with Proxy-Authorization, breaks the general - rules about multiple header field values. Although not a comma- - separated list, this header field name may be present multiple times, - and MUST NOT be combined into a single header line using the usual - rules described in Section 7.3. - - - - - - - -Rosenberg, et. al. Standards Track [Page 165] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - In the example below, there are no quotes around the Digest - parameter: - - Authorization: Digest username="Alice", realm="atlanta.com", - nonce="84a4cc6f3082121f32b42a2187831a9e", - response="7587245234b3434cc3412213e5f113a5432" - -20.8 Call-ID - - The Call-ID header field uniquely identifies a particular invitation - or all registrations of a particular client. A single multimedia - conference can give rise to several calls with different Call-IDs, - for example, if a user invites a single individual several times to - the same (long-running) conference. Call-IDs are case-sensitive and - are simply compared byte-by-byte. - - The compact form of the Call-ID header field is i. - - Examples: - - Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com - i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4 - -20.9 Call-Info - - The Call-Info header field provides additional information about the - caller or callee, depending on whether it is found in a request or - response. The purpose of the URI is described by the "purpose" - parameter. The "icon" parameter designates an image suitable as an - iconic representation of the caller or callee. The "info" parameter - describes the caller or callee in general, for example, through a web - page. The "card" parameter provides a business card, for example, in - vCard [36] or LDIF [37] formats. Additional tokens can be registered - using IANA and the procedures in Section 27. - - Use of the Call-Info header field can pose a security risk. If a - callee fetches the URIs provided by a malicious caller, the callee - may be at risk for displaying inappropriate or offensive content, - dangerous or illegal content, and so on. Therefore, it is - RECOMMENDED that a UA only render the information in the Call-Info - header field if it can verify the authenticity of the element that - originated the header field and trusts that element. This need not - be the peer UA; a proxy can insert this header field into requests. - - Example: - - Call-Info: ;purpose=icon, - ;purpose=info - - - -Rosenberg, et. al. Standards Track [Page 166] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -20.10 Contact - - A Contact header field value provides a URI whose meaning depends on - the type of request or response it is in. - - A Contact header field value can contain a display name, a URI with - URI parameters, and header parameters. - - This document defines the Contact parameters "q" and "expires". - These parameters are only used when the Contact is present in a - REGISTER request or response, or in a 3xx response. Additional - parameters may be defined in other specifications. - - When the header field value contains a display name, the URI - including all URI parameters is enclosed in "<" and ">". If no "<" - and ">" are present, all parameters after the URI are header - parameters, not URI parameters. The display name can be tokens, or a - quoted string, if a larger character set is desired. - - Even if the "display-name" is empty, the "name-addr" form MUST be - used if the "addr-spec" contains a comma, semicolon, or question - mark. There may or may not be LWS between the display-name and the - "<". - - These rules for parsing a display name, URI and URI parameters, and - header parameters also apply for the header fields To and From. - - The Contact header field has a role similar to the Location header - field in HTTP. However, the HTTP header field only allows one - address, unquoted. Since URIs can contain commas and semicolons - as reserved characters, they can be mistaken for header or - parameter delimiters, respectively. - - The compact form of the Contact header field is m (for "moved"). - - Examples: - - Contact: "Mr. Watson" - ;q=0.7; expires=3600, - "Mr. Watson" ;q=0.1 - m: ;expires=60 - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 167] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -20.11 Content-Disposition - - The Content-Disposition header field describes how the message body - or, for multipart messages, a message body part is to be interpreted - by the UAC or UAS. This SIP header field extends the MIME Content- - Type (RFC 2183 [18]). - - Several new "disposition-types" of the Content-Disposition header are - defined by SIP. The value "session" indicates that the body part - describes a session, for either calls or early (pre-call) media. The - value "render" indicates that the body part should be displayed or - otherwise rendered to the user. Note that the value "render" is used - rather than "inline" to avoid the connotation that the MIME body is - displayed as a part of the rendering of the entire message (since the - MIME bodies of SIP messages oftentimes are not displayed to users). - For backward-compatibility, if the Content-Disposition header field - is missing, the server SHOULD assume bodies of Content-Type - application/sdp are the disposition "session", while other content - types are "render". - - The disposition type "icon" indicates that the body part contains an - image suitable as an iconic representation of the caller or callee - that could be rendered informationally by a user agent when a message - has been received, or persistently while a dialog takes place. The - value "alert" indicates that the body part contains information, such - as an audio clip, that should be rendered by the user agent in an - attempt to alert the user to the receipt of a request, generally a - request that initiates a dialog; this alerting body could for example - be rendered as a ring tone for a phone call after a 180 Ringing - provisional response has been sent. - - Any MIME body with a "disposition-type" that renders content to the - user should only be processed when a message has been properly - authenticated. - - The handling parameter, handling-param, describes how the UAS should - react if it receives a message body whose content type or disposition - type it does not understand. The parameter has defined values of - "optional" and "required". If the handling parameter is missing, the - value "required" SHOULD be assumed. The handling parameter is - described in RFC 3204 [19]. - - If this header field is missing, the MIME type determines the default - content disposition. If there is none, "render" is assumed. - - Example: - - Content-Disposition: session - - - -Rosenberg, et. al. Standards Track [Page 168] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -20.12 Content-Encoding - - The Content-Encoding header field is used as a modifier to the - "media-type". When present, its value indicates what additional - content codings have been applied to the entity-body, and thus what - decoding mechanisms MUST be applied in order to obtain the media-type - referenced by the Content-Type header field. Content-Encoding is - primarily used to allow a body to be compressed without losing the - identity of its underlying media type. - - If multiple encodings have been applied to an entity-body, the - content codings MUST be listed in the order in which they were - applied. - - All content-coding values are case-insensitive. IANA acts as a - registry for content-coding value tokens. See [H3.5] for a - definition of the syntax for content-coding. - - Clients MAY apply content encodings to the body in requests. A - server MAY apply content encodings to the bodies in responses. The - server MUST only use encodings listed in the Accept-Encoding header - field in the request. - - The compact form of the Content-Encoding header field is e. - Examples: - - Content-Encoding: gzip - e: tar - -20.13 Content-Language - - See [H14.12]. Example: - - Content-Language: fr - -20.14 Content-Length - - The Content-Length header field indicates the size of the message- - body, in decimal number of octets, sent to the recipient. - Applications SHOULD use this field to indicate the size of the - message-body to be transferred, regardless of the media type of the - entity. If a stream-based protocol (such as TCP) is used as - transport, the header field MUST be used. - - The size of the message-body does not include the CRLF separating - header fields and body. Any Content-Length greater than or equal to - zero is a valid value. If no body is present in a message, then the - Content-Length header field value MUST be set to zero. - - - -Rosenberg, et. al. Standards Track [Page 169] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The ability to omit Content-Length simplifies the creation of - cgi-like scripts that dynamically generate responses. - - The compact form of the header field is l. - - Examples: - - Content-Length: 349 - l: 173 - -20.15 Content-Type - - The Content-Type header field indicates the media type of the - message-body sent to the recipient. The "media-type" element is - defined in [H3.7]. The Content-Type header field MUST be present if - the body is not empty. If the body is empty, and a Content-Type - header field is present, it indicates that the body of the specific - type has zero length (for example, an empty audio file). - - The compact form of the header field is c. - - Examples: - - Content-Type: application/sdp - c: text/html; charset=ISO-8859-4 - -20.16 CSeq - - A CSeq header field in a request contains a single decimal sequence - number and the request method. The sequence number MUST be - expressible as a 32-bit unsigned integer. The method part of CSeq is - case-sensitive. The CSeq header field serves to order transactions - within a dialog, to provide a means to uniquely identify - transactions, and to differentiate between new requests and request - retransmissions. Two CSeq header fields are considered equal if the - sequence number and the request method are identical. Example: - - CSeq: 4711 INVITE - -20.17 Date - - The Date header field contains the date and time. Unlike HTTP/1.1, - SIP only supports the most recent RFC 1123 [20] format for dates. As - in [H3.3], SIP restricts the time zone in SIP-date to "GMT", while - RFC 1123 allows any time zone. An RFC 1123 date is case-sensitive. - - The Date header field reflects the time when the request or response - is first sent. - - - -Rosenberg, et. al. Standards Track [Page 170] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The Date header field can be used by simple end systems without a - battery-backed clock to acquire a notion of current time. - However, in its GMT form, it requires clients to know their offset - from GMT. - - Example: - - Date: Sat, 13 Nov 2010 23:29:00 GMT - -20.18 Error-Info - - The Error-Info header field provides a pointer to additional - information about the error status response. - - SIP UACs have user interface capabilities ranging from pop-up - windows and audio on PC softclients to audio-only on "black" - phones or endpoints connected via gateways. Rather than forcing a - server generating an error to choose between sending an error - status code with a detailed reason phrase and playing an audio - recording, the Error-Info header field allows both to be sent. - The UAC then has the choice of which error indicator to render to - the caller. - - A UAC MAY treat a SIP or SIPS URI in an Error-Info header field as if - it were a Contact in a redirect and generate a new INVITE, resulting - in a recorded announcement session being established. A non-SIP URI - MAY be rendered to the user. - - Examples: - - SIP/2.0 404 The number you have dialed is not in service - Error-Info: - -20.19 Expires - - The Expires header field gives the relative time after which the - message (or content) expires. - - The precise meaning of this is method dependent. - - The expiration time in an INVITE does not affect the duration of the - actual session that may result from the invitation. Session - description protocols may offer the ability to express time limits on - the session duration, however. - - The value of this field is an integral number of seconds (in decimal) - between 0 and (2**32)-1, measured from the receipt of the request. - - - - -Rosenberg, et. al. Standards Track [Page 171] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Example: - - Expires: 5 - -20.20 From - - The From header field indicates the initiator of the request. This - may be different from the initiator of the dialog. Requests sent by - the callee to the caller use the callee's address in the From header - field. - - The optional "display-name" is meant to be rendered by a human user - interface. A system SHOULD use the display name "Anonymous" if the - identity of the client is to remain hidden. Even if the "display- - name" is empty, the "name-addr" form MUST be used if the "addr-spec" - contains a comma, question mark, or semicolon. Syntax issues are - discussed in Section 7.3.1. - - Two From header fields are equivalent if their URIs match, and their - parameters match. Extension parameters in one header field, not - present in the other are ignored for the purposes of comparison. This - means that the display name and presence or absence of angle brackets - do not affect matching. - - See Section 20.10 for the rules for parsing a display name, URI and - URI parameters, and header field parameters. - - The compact form of the From header field is f. - - Examples: - - From: "A. G. Bell" ;tag=a48s - From: sip:+12125551212@server.phone2net.com;tag=887s - f: Anonymous ;tag=hyh8 - -20.21 In-Reply-To - - The In-Reply-To header field enumerates the Call-IDs that this call - references or returns. These Call-IDs may have been cached by the - client then included in this header field in a return call. - - This allows automatic call distribution systems to route return - calls to the originator of the first call. This also allows - callees to filter calls, so that only return calls for calls they - originated will be accepted. This field is not a substitute for - request authentication. - - - - - -Rosenberg, et. al. Standards Track [Page 172] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Example: - - In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com - -20.22 Max-Forwards - - The Max-Forwards header field must be used with any SIP method to - limit the number of proxies or gateways that can forward the request - to the next downstream server. This can also be useful when the - client is attempting to trace a request chain that appears to be - failing or looping in mid-chain. - - The Max-Forwards value is an integer in the range 0-255 indicating - the remaining number of times this request message is allowed to be - forwarded. This count is decremented by each server that forwards - the request. The recommended initial value is 70. - - This header field should be inserted by elements that can not - otherwise guarantee loop detection. For example, a B2BUA should - insert a Max-Forwards header field. - - Example: - - Max-Forwards: 6 - -20.23 Min-Expires - - The Min-Expires header field conveys the minimum refresh interval - supported for soft-state elements managed by that server. This - includes Contact header fields that are stored by a registrar. The - header field contains a decimal integer number of seconds from 0 to - (2**32)-1. The use of the header field in a 423 (Interval Too Brief) - response is described in Sections 10.2.8, 10.3, and 21.4.17. - - Example: - - Min-Expires: 60 - -20.24 MIME-Version - - See [H19.4.1]. - - Example: - - MIME-Version: 1.0 - - - - - - -Rosenberg, et. al. Standards Track [Page 173] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -20.25 Organization - - The Organization header field conveys the name of the organization to - which the SIP element issuing the request or response belongs. - - The field MAY be used by client software to filter calls. - - Example: - - Organization: Boxes by Bob - -20.26 Priority - - The Priority header field indicates the urgency of the request as - perceived by the client. The Priority header field describes the - priority that the SIP request should have to the receiving human or - its agent. For example, it may be factored into decisions about call - routing and acceptance. For these decisions, a message containing no - Priority header field SHOULD be treated as if it specified a Priority - of "normal". The Priority header field does not influence the use of - communications resources such as packet forwarding priority in - routers or access to circuits in PSTN gateways. The header field can - have the values "non-urgent", "normal", "urgent", and "emergency", - but additional values can be defined elsewhere. It is RECOMMENDED - that the value of "emergency" only be used when life, limb, or - property are in imminent danger. Otherwise, there are no semantics - defined for this header field. - - These are the values of RFC 2076 [38], with the addition of - "emergency". - - Examples: - - Subject: A tornado is heading our way! - Priority: emergency - - or - - Subject: Weekend plans - Priority: non-urgent - -20.27 Proxy-Authenticate - - A Proxy-Authenticate header field value contains an authentication - challenge. - - The use of this header field is defined in [H14.33]. See Section - 22.3 for further details on its usage. - - - -Rosenberg, et. al. Standards Track [Page 174] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Example: - - Proxy-Authenticate: Digest realm="atlanta.com", - domain="sip:ss1.carrier.com", qop="auth", - nonce="f84f1cec41e6cbe5aea9c8e88d359", - opaque="", stale=FALSE, algorithm=MD5 - -20.28 Proxy-Authorization - - The Proxy-Authorization header field allows the client to identify - itself (or its user) to a proxy that requires authentication. A - Proxy-Authorization field value consists of credentials containing - the authentication information of the user agent for the proxy and/or - realm of the resource being requested. - - See Section 22.3 for a definition of the usage of this header field. - - This header field, along with Authorization, breaks the general rules - about multiple header field names. Although not a comma-separated - list, this header field name may be present multiple times, and MUST - NOT be combined into a single header line using the usual rules - described in Section 7.3.1. - - Example: - - Proxy-Authorization: Digest username="Alice", realm="atlanta.com", - nonce="c60f3082ee1212b402a21831ae", - response="245f23415f11432b3434341c022" - -20.29 Proxy-Require - - The Proxy-Require header field is used to indicate proxy-sensitive - features that must be supported by the proxy. See Section 20.32 for - more details on the mechanics of this message and a usage example. - - Example: - - Proxy-Require: foo - -20.30 Record-Route - - The Record-Route header field is inserted by proxies in a request to - force future requests in the dialog to be routed through the proxy. - - Examples of its use with the Route header field are described in - Sections 16.12.1. - - - - - -Rosenberg, et. al. Standards Track [Page 175] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Example: - - Record-Route: , - - -20.31 Reply-To - - The Reply-To header field contains a logical return URI that may be - different from the From header field. For example, the URI MAY be - used to return missed calls or unestablished sessions. If the user - wished to remain anonymous, the header field SHOULD either be omitted - from the request or populated in such a way that does not reveal any - private information. - - Even if the "display-name" is empty, the "name-addr" form MUST be - used if the "addr-spec" contains a comma, question mark, or - semicolon. Syntax issues are discussed in Section 7.3.1. - - Example: - - Reply-To: Bob - -20.32 Require - - The Require header field is used by UACs to tell UASs about options - that the UAC expects the UAS to support in order to process the - request. Although an optional header field, the Require MUST NOT be - ignored if it is present. - - The Require header field contains a list of option tags, described in - Section 19.2. Each option tag defines a SIP extension that MUST be - understood to process the request. Frequently, this is used to - indicate that a specific set of extension header fields need to be - understood. A UAC compliant to this specification MUST only include - option tags corresponding to standards-track RFCs. - - Example: - - Require: 100rel - -20.33 Retry-After - - The Retry-After header field can be used with a 500 (Server Internal - Error) or 503 (Service Unavailable) response to indicate how long the - service is expected to be unavailable to the requesting client and - with a 404 (Not Found), 413 (Request Entity Too Large), 480 - (Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603 - - - - -Rosenberg, et. al. Standards Track [Page 176] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - (Decline) response to indicate when the called party anticipates - being available again. The value of this field is a positive integer - number of seconds (in decimal) after the time of the response. - - An optional comment can be used to indicate additional information - about the time of callback. An optional "duration" parameter - indicates how long the called party will be reachable starting at the - initial time of availability. If no duration parameter is given, the - service is assumed to be available indefinitely. - - Examples: - - Retry-After: 18000;duration=3600 - Retry-After: 120 (I'm in a meeting) - -20.34 Route - - The Route header field is used to force routing for a request through - the listed set of proxies. Examples of the use of the Route header - field are in Section 16.12.1. - - Example: - - Route: , - - -20.35 Server - - The Server header field contains information about the software used - by the UAS to handle the request. - - Revealing the specific software version of the server might allow the - server to become more vulnerable to attacks against software that is - known to contain security holes. Implementers SHOULD make the Server - header field a configurable option. - - Example: - - Server: HomeServer v2 - -20.36 Subject - - The Subject header field provides a summary or indicates the nature - of the call, allowing call filtering without having to parse the - session description. The session description does not have to use - the same subject indication as the invitation. - - The compact form of the Subject header field is s. - - - -Rosenberg, et. al. Standards Track [Page 177] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Example: - - Subject: Need more boxes - s: Tech Support - -20.37 Supported - - The Supported header field enumerates all the extensions supported by - the UAC or UAS. - - The Supported header field contains a list of option tags, described - in Section 19.2, that are understood by the UAC or UAS. A UA - compliant to this specification MUST only include option tags - corresponding to standards-track RFCs. If empty, it means that no - extensions are supported. - - The compact form of the Supported header field is k. - - Example: - - Supported: 100rel - -20.38 Timestamp - - The Timestamp header field describes when the UAC sent the request to - the UAS. - - See Section 8.2.6 for details on how to generate a response to a - request that contains the header field. Although there is no - normative behavior defined here that makes use of the header, it - allows for extensions or SIP applications to obtain RTT estimates. - - Example: - - Timestamp: 54 - -20.39 To - - The To header field specifies the logical recipient of the request. - - The optional "display-name" is meant to be rendered by a human-user - interface. The "tag" parameter serves as a general mechanism for - dialog identification. - - See Section 19.3 for details of the "tag" parameter. - - - - - - -Rosenberg, et. al. Standards Track [Page 178] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Comparison of To header fields for equality is identical to - comparison of From header fields. See Section 20.10 for the rules - for parsing a display name, URI and URI parameters, and header field - parameters. - - The compact form of the To header field is t. - - The following are examples of valid To header fields: - - To: The Operator ;tag=287447 - t: sip:+12125551212@server.phone2net.com - -20.40 Unsupported - - The Unsupported header field lists the features not supported by the - UAS. See Section 20.32 for motivation. - - Example: - - Unsupported: foo - -20.41 User-Agent - - The User-Agent header field contains information about the UAC - originating the request. The semantics of this header field are - defined in [H14.43]. - - Revealing the specific software version of the user agent might allow - the user agent to become more vulnerable to attacks against software - that is known to contain security holes. Implementers SHOULD make - the User-Agent header field a configurable option. - - Example: - - User-Agent: Softphone Beta1.5 - -20.42 Via - - The Via header field indicates the path taken by the request so far - and indicates the path that should be followed in routing responses. - The branch ID parameter in the Via header field values serves as a - transaction identifier, and is used by proxies to detect loops. - - A Via header field value contains the transport protocol used to send - the message, the client's host name or network address, and possibly - the port number at which it wishes to receive responses. A Via - header field value can also contain parameters such as "maddr", - "ttl", "received", and "branch", whose meaning and use are described - - - -Rosenberg, et. al. Standards Track [Page 179] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - in other sections. For implementations compliant to this - specification, the value of the branch parameter MUST start with the - magic cookie "z9hG4bK", as discussed in Section 8.1.1.7. - - Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP". - "TLS" means TLS over TCP. When a request is sent to a SIPS URI, the - protocol still indicates "SIP", and the transport protocol is TLS. - -Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7 -Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207 - ;branch=z9hG4bK77asjd - - The compact form of the Via header field is v. - - In this example, the message originated from a multi-homed host with - two addresses, 192.0.2.1 and 192.0.2.207. The sender guessed wrong - as to which network interface would be used. Erlang.bell- - telephone.com noticed the mismatch and added a parameter to the - previous hop's Via header field value, containing the address that - the packet actually came from. - - The host or network address and port number are not required to - follow the SIP URI syntax. Specifically, LWS on either side of the - ":" or "/" is allowed, as shown here: - - Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16 - ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1 - - Even though this specification mandates that the branch parameter be - present in all requests, the BNF for the header field indicates that - it is optional. This allows interoperation with RFC 2543 elements, - which did not have to insert the branch parameter. - - Two Via header fields are equal if their sent-protocol and sent-by - fields are equal, both have the same set of parameters, and the - values of all parameters are equal. - -20.43 Warning - - The Warning header field is used to carry additional information - about the status of a response. Warning header field values are sent - with responses and contain a three-digit warning code, host name, and - warning text. - - The "warn-text" should be in a natural language that is most likely - to be intelligible to the human user receiving the response. This - decision can be based on any available knowledge, such as the - location of the user, the Accept-Language field in a request, or the - - - -Rosenberg, et. al. Standards Track [Page 180] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Content-Language field in a response. The default language is i- - default [21]. - - The currently-defined "warn-code"s are listed below, with a - recommended warn-text in English and a description of their meaning. - These warnings describe failures induced by the session description. - The first digit of warning codes beginning with "3" indicates - warnings specific to SIP. Warnings 300 through 329 are reserved for - indicating problems with keywords in the session description, 330 - through 339 are warnings related to basic network services requested - in the session description, 370 through 379 are warnings related to - quantitative QoS parameters requested in the session description, and - 390 through 399 are miscellaneous warnings that do not fall into one - of the above categories. - - 300 Incompatible network protocol: One or more network protocols - contained in the session description are not available. - - 301 Incompatible network address formats: One or more network - address formats contained in the session description are not - available. - - 302 Incompatible transport protocol: One or more transport - protocols described in the session description are not - available. - - 303 Incompatible bandwidth units: One or more bandwidth - measurement units contained in the session description were - not understood. - - 304 Media type not available: One or more media types contained in - the session description are not available. - - 305 Incompatible media format: One or more media formats contained - in the session description are not available. - - 306 Attribute not understood: One or more of the media attributes - in the session description are not supported. - - 307 Session description parameter not understood: A parameter - other than those listed above was not understood. - - 330 Multicast not available: The site where the user is located - does not support multicast. - - 331 Unicast not available: The site where the user is located does - not support unicast communication (usually due to the presence - of a firewall). - - - -Rosenberg, et. al. Standards Track [Page 181] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - 370 Insufficient bandwidth: The bandwidth specified in the session - description or defined by the media exceeds that known to be - available. - - 399 Miscellaneous warning: The warning text can include arbitrary - information to be presented to a human user or logged. A - system receiving this warning MUST NOT take any automated - action. - - 1xx and 2xx have been taken by HTTP/1.1. - - Additional "warn-code"s can be defined through IANA, as defined in - Section 27.2. - - Examples: - - Warning: 307 isi.edu "Session parameter 'foo' not understood" - Warning: 301 isi.edu "Incompatible network address type 'E.164'" - -20.44 WWW-Authenticate - - A WWW-Authenticate header field value contains an authentication - challenge. See Section 22.2 for further details on its usage. - - Example: - - WWW-Authenticate: Digest realm="atlanta.com", - domain="sip:boxesbybob.com", qop="auth", - nonce="f84f1cec41e6cbe5aea9c8e88d359", - opaque="", stale=FALSE, algorithm=MD5 - -21 Response Codes - - The response codes are consistent with, and extend, HTTP/1.1 response - codes. Not all HTTP/1.1 response codes are appropriate, and only - those that are appropriate are given here. Other HTTP/1.1 response - codes SHOULD NOT be used. Also, SIP defines a new class, 6xx. - -21.1 Provisional 1xx - - Provisional responses, also known as informational responses, - indicate that the server contacted is performing some further action - and does not yet have a definitive response. A server sends a 1xx - response if it expects to take more than 200 ms to obtain a final - response. Note that 1xx responses are not transmitted reliably. - They never cause the client to send an ACK. Provisional (1xx) - responses MAY contain message bodies, including session descriptions. - - - - -Rosenberg, et. al. Standards Track [Page 182] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -21.1.1 100 Trying - - This response indicates that the request has been received by the - next-hop server and that some unspecified action is being taken on - behalf of this call (for example, a database is being consulted). - This response, like all other provisional responses, stops - retransmissions of an INVITE by a UAC. The 100 (Trying) response is - different from other provisional responses, in that it is never - forwarded upstream by a stateful proxy. - -21.1.2 180 Ringing - - The UA receiving the INVITE is trying to alert the user. This - response MAY be used to initiate local ringback. - -21.1.3 181 Call Is Being Forwarded - - A server MAY use this status code to indicate that the call is being - forwarded to a different set of destinations. - -21.1.4 182 Queued - - The called party is temporarily unavailable, but the server has - decided to queue the call rather than reject it. When the callee - becomes available, it will return the appropriate final status - response. The reason phrase MAY give further details about the - status of the call, for example, "5 calls queued; expected waiting - time is 15 minutes". The server MAY issue several 182 (Queued) - responses to update the caller about the status of the queued call. - -21.1.5 183 Session Progress - - The 183 (Session Progress) response is used to convey information - about the progress of the call that is not otherwise classified. The - Reason-Phrase, header fields, or message body MAY be used to convey - more details about the call progress. - -21.2 Successful 2xx - - The request was successful. - -21.2.1 200 OK - - The request has succeeded. The information returned with the - response depends on the method used in the request. - - - - - - -Rosenberg, et. al. Standards Track [Page 183] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -21.3 Redirection 3xx - - 3xx responses give information about the user's new location, or - about alternative services that might be able to satisfy the call. - -21.3.1 300 Multiple Choices - - The address in the request resolved to several choices, each with its - own specific location, and the user (or UA) can select a preferred - communication end point and redirect its request to that location. - - The response MAY include a message body containing a list of resource - characteristics and location(s) from which the user or UA can choose - the one most appropriate, if allowed by the Accept request header - field. However, no MIME types have been defined for this message - body. - - The choices SHOULD also be listed as Contact fields (Section 20.10). - Unlike HTTP, the SIP response MAY contain several Contact fields or a - list of addresses in a Contact field. UAs MAY use the Contact header - field value for automatic redirection or MAY ask the user to confirm - a choice. However, this specification does not define any standard - for such automatic selection. - - This status response is appropriate if the callee can be reached - at several different locations and the server cannot or prefers - not to proxy the request. - -21.3.2 301 Moved Permanently - - The user can no longer be found at the address in the Request-URI, - and the requesting client SHOULD retry at the new address given by - the Contact header field (Section 20.10). The requestor SHOULD - update any local directories, address books, and user location caches - with this new value and redirect future requests to the address(es) - listed. - -21.3.3 302 Moved Temporarily - - The requesting client SHOULD retry the request at the new address(es) - given by the Contact header field (Section 20.10). The Request-URI - of the new request uses the value of the Contact header field in the - response. - - - - - - - - -Rosenberg, et. al. Standards Track [Page 184] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The duration of the validity of the Contact URI can be indicated - through an Expires (Section 20.19) header field or an expires - parameter in the Contact header field. Both proxies and UAs MAY - cache this URI for the duration of the expiration time. If there is - no explicit expiration time, the address is only valid once for - recursing, and MUST NOT be cached for future transactions. - - If the URI cached from the Contact header field fails, the Request- - URI from the redirected request MAY be tried again a single time. - - The temporary URI may have become out-of-date sooner than the - expiration time, and a new temporary URI may be available. - -21.3.4 305 Use Proxy - - The requested resource MUST be accessed through the proxy given by - the Contact field. The Contact field gives the URI of the proxy. - The recipient is expected to repeat this single request via the - proxy. 305 (Use Proxy) responses MUST only be generated by UASs. - -21.3.5 380 Alternative Service - - The call was not successful, but alternative services are possible. - - The alternative services are described in the message body of the - response. Formats for such bodies are not defined here, and may be - the subject of future standardization. - -21.4 Request Failure 4xx - - 4xx responses are definite failure responses from a particular - server. The client SHOULD NOT retry the same request without - modification (for example, adding appropriate authorization). - However, the same request to a different server might be successful. - -21.4.1 400 Bad Request - - The request could not be understood due to malformed syntax. The - Reason-Phrase SHOULD identify the syntax problem in more detail, for - example, "Missing Call-ID header field". - -21.4.2 401 Unauthorized - - The request requires user authentication. This response is issued by - UASs and registrars, while 407 (Proxy Authentication Required) is - used by proxy servers. - - - - - -Rosenberg, et. al. Standards Track [Page 185] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -21.4.3 402 Payment Required - - Reserved for future use. - -21.4.4 403 Forbidden - - The server understood the request, but is refusing to fulfill it. - Authorization will not help, and the request SHOULD NOT be repeated. - -21.4.5 404 Not Found - - The server has definitive information that the user does not exist at - the domain specified in the Request-URI. This status is also - returned if the domain in the Request-URI does not match any of the - domains handled by the recipient of the request. - -21.4.6 405 Method Not Allowed - - The method specified in the Request-Line is understood, but not - allowed for the address identified by the Request-URI. - - The response MUST include an Allow header field containing a list of - valid methods for the indicated address. - -21.4.7 406 Not Acceptable - - The resource identified by the request is only capable of generating - response entities that have content characteristics not acceptable - according to the Accept header field sent in the request. - -21.4.8 407 Proxy Authentication Required - - This code is similar to 401 (Unauthorized), but indicates that the - client MUST first authenticate itself with the proxy. SIP access - authentication is explained in Sections 26 and 22.3. - - This status code can be used for applications where access to the - communication channel (for example, a telephony gateway) rather than - the callee requires authentication. - -21.4.9 408 Request Timeout - - The server could not produce a response within a suitable amount of - time, for example, if it could not determine the location of the user - in time. The client MAY repeat the request without modifications at - any later time. - - - - - -Rosenberg, et. al. Standards Track [Page 186] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -21.4.10 410 Gone - - The requested resource is no longer available at the server and no - forwarding address is known. This condition is expected to be - considered permanent. If the server does not know, or has no - facility to determine, whether or not the condition is permanent, the - status code 404 (Not Found) SHOULD be used instead. - -21.4.11 413 Request Entity Too Large - - The server is refusing to process a request because the request - entity-body is larger than the server is willing or able to process. - The server MAY close the connection to prevent the client from - continuing the request. - - If the condition is temporary, the server SHOULD include a Retry- - After header field to indicate that it is temporary and after what - time the client MAY try again. - -21.4.12 414 Request-URI Too Long - - The server is refusing to service the request because the Request-URI - is longer than the server is willing to interpret. - -21.4.13 415 Unsupported Media Type - - The server is refusing to service the request because the message - body of the request is in a format not supported by the server for - the requested method. The server MUST return a list of acceptable - formats using the Accept, Accept-Encoding, or Accept-Language header - field, depending on the specific problem with the content. UAC - processing of this response is described in Section 8.1.3.5. - -21.4.14 416 Unsupported URI Scheme - - The server cannot process the request because the scheme of the URI - in the Request-URI is unknown to the server. Client processing of - this response is described in Section 8.1.3.5. - -21.4.15 420 Bad Extension - - The server did not understand the protocol extension specified in a - Proxy-Require (Section 20.29) or Require (Section 20.32) header - field. The server MUST include a list of the unsupported extensions - in an Unsupported header field in the response. UAC processing of - this response is described in Section 8.1.3.5. - - - - - -Rosenberg, et. al. Standards Track [Page 187] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -21.4.16 421 Extension Required - - The UAS needs a particular extension to process the request, but this - extension is not listed in a Supported header field in the request. - Responses with this status code MUST contain a Require header field - listing the required extensions. - - A UAS SHOULD NOT use this response unless it truly cannot provide any - useful service to the client. Instead, if a desirable extension is - not listed in the Supported header field, servers SHOULD process the - request using baseline SIP capabilities and any extensions supported - by the client. - -21.4.17 423 Interval Too Brief - - The server is rejecting the request because the expiration time of - the resource refreshed by the request is too short. This response - can be used by a registrar to reject a registration whose Contact - header field expiration time was too small. The use of this response - and the related Min-Expires header field are described in Sections - 10.2.8, 10.3, and 20.23. - -21.4.18 480 Temporarily Unavailable - - The callee's end system was contacted successfully but the callee is - currently unavailable (for example, is not logged in, logged in but - in a state that precludes communication with the callee, or has - activated the "do not disturb" feature). The response MAY indicate a - better time to call in the Retry-After header field. The user could - also be available elsewhere (unbeknownst to this server). The reason - phrase SHOULD indicate a more precise cause as to why the callee is - unavailable. This value SHOULD be settable by the UA. Status 486 - (Busy Here) MAY be used to more precisely indicate a particular - reason for the call failure. - - This status is also returned by a redirect or proxy server that - recognizes the user identified by the Request-URI, but does not - currently have a valid forwarding location for that user. - -21.4.19 481 Call/Transaction Does Not Exist - - This status indicates that the UAS received a request that does not - match any existing dialog or transaction. - -21.4.20 482 Loop Detected - - The server has detected a loop (Section 16.3 Item 4). - - - - -Rosenberg, et. al. Standards Track [Page 188] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -21.4.21 483 Too Many Hops - - The server received a request that contains a Max-Forwards (Section - 20.22) header field with the value zero. - -21.4.22 484 Address Incomplete - - The server received a request with a Request-URI that was incomplete. - Additional information SHOULD be provided in the reason phrase. - - This status code allows overlapped dialing. With overlapped - dialing, the client does not know the length of the dialing - string. It sends strings of increasing lengths, prompting the - user for more input, until it no longer receives a 484 (Address - Incomplete) status response. - -21.4.23 485 Ambiguous - - The Request-URI was ambiguous. The response MAY contain a listing of - possible unambiguous addresses in Contact header fields. Revealing - alternatives can infringe on privacy of the user or the organization. - It MUST be possible to configure a server to respond with status 404 - (Not Found) or to suppress the listing of possible choices for - ambiguous Request-URIs. - - Example response to a request with the Request-URI - sip:lee@example.com: - - SIP/2.0 485 Ambiguous - Contact: Carol Lee - Contact: Ping Lee - Contact: Lee M. Foote - - Some email and voice mail systems provide this functionality. A - status code separate from 3xx is used since the semantics are - different: for 300, it is assumed that the same person or service - will be reached by the choices provided. While an automated - choice or sequential search makes sense for a 3xx response, user - intervention is required for a 485 (Ambiguous) response. - -21.4.24 486 Busy Here - - The callee's end system was contacted successfully, but the callee is - currently not willing or able to take additional calls at this end - system. The response MAY indicate a better time to call in the - Retry-After header field. The user could also be available - - - - - -Rosenberg, et. al. Standards Track [Page 189] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - elsewhere, such as through a voice mail service. Status 600 (Busy - Everywhere) SHOULD be used if the client knows that no other end - system will be able to accept this call. - -21.4.25 487 Request Terminated - - The request was terminated by a BYE or CANCEL request. This response - is never returned for a CANCEL request itself. - -21.4.26 488 Not Acceptable Here - - The response has the same meaning as 606 (Not Acceptable), but only - applies to the specific resource addressed by the Request-URI and the - request may succeed elsewhere. - - A message body containing a description of media capabilities MAY be - present in the response, which is formatted according to the Accept - header field in the INVITE (or application/sdp if not present), the - same as a message body in a 200 (OK) response to an OPTIONS request. - -21.4.27 491 Request Pending - - The request was received by a UAS that had a pending request within - the same dialog. Section 14.2 describes how such "glare" situations - are resolved. - -21.4.28 493 Undecipherable - - The request was received by a UAS that contained an encrypted MIME - body for which the recipient does not possess or will not provide an - appropriate decryption key. This response MAY have a single body - containing an appropriate public key that should be used to encrypt - MIME bodies sent to this UA. Details of the usage of this response - code can be found in Section 23.2. - -21.5 Server Failure 5xx - - 5xx responses are failure responses given when a server itself has - erred. - -21.5.1 500 Server Internal Error - - The server encountered an unexpected condition that prevented it from - fulfilling the request. The client MAY display the specific error - condition and MAY retry the request after several seconds. - - If the condition is temporary, the server MAY indicate when the - client may retry the request using the Retry-After header field. - - - -Rosenberg, et. al. Standards Track [Page 190] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -21.5.2 501 Not Implemented - - The server does not support the functionality required to fulfill the - request. This is the appropriate response when a UAS does not - recognize the request method and is not capable of supporting it for - any user. (Proxies forward all requests regardless of method.) - - Note that a 405 (Method Not Allowed) is sent when the server - recognizes the request method, but that method is not allowed or - supported. - -21.5.3 502 Bad Gateway - - The server, while acting as a gateway or proxy, received an invalid - response from the downstream server it accessed in attempting to - fulfill the request. - -21.5.4 503 Service Unavailable - - The server is temporarily unable to process the request due to a - temporary overloading or maintenance of the server. The server MAY - indicate when the client should retry the request in a Retry-After - header field. If no Retry-After is given, the client MUST act as if - it had received a 500 (Server Internal Error) response. - - A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD - attempt to forward the request to an alternate server. It SHOULD NOT - forward any other requests to that server for the duration specified - in the Retry-After header field, if present. - - Servers MAY refuse the connection or drop the request instead of - responding with 503 (Service Unavailable). - -21.5.5 504 Server Time-out - - The server did not receive a timely response from an external server - it accessed in attempting to process the request. 408 (Request - Timeout) should be used instead if there was no response within the - period specified in the Expires header field from the upstream - server. - -21.5.6 505 Version Not Supported - - The server does not support, or refuses to support, the SIP protocol - version that was used in the request. The server is indicating that - it is unable or unwilling to complete the request using the same - major version as the client, other than with this error message. - - - - -Rosenberg, et. al. Standards Track [Page 191] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -21.5.7 513 Message Too Large - - The server was unable to process the request since the message length - exceeded its capabilities. - -21.6 Global Failures 6xx - - 6xx responses indicate that a server has definitive information about - a particular user, not just the particular instance indicated in the - Request-URI. - -21.6.1 600 Busy Everywhere - - The callee's end system was contacted successfully but the callee is - busy and does not wish to take the call at this time. The response - MAY indicate a better time to call in the Retry-After header field. - If the callee does not wish to reveal the reason for declining the - call, the callee uses status code 603 (Decline) instead. This status - response is returned only if the client knows that no other end point - (such as a voice mail system) will answer the request. Otherwise, - 486 (Busy Here) should be returned. - -21.6.2 603 Decline - - The callee's machine was successfully contacted but the user - explicitly does not wish to or cannot participate. The response MAY - indicate a better time to call in the Retry-After header field. This - status response is returned only if the client knows that no other - end point will answer the request. - -21.6.3 604 Does Not Exist Anywhere - - The server has authoritative information that the user indicated in - the Request-URI does not exist anywhere. - -21.6.4 606 Not Acceptable - - The user's agent was contacted successfully but some aspects of the - session description such as the requested media, bandwidth, or - addressing style were not acceptable. - - A 606 (Not Acceptable) response means that the user wishes to - communicate, but cannot adequately support the session described. - The 606 (Not Acceptable) response MAY contain a list of reasons in a - Warning header field describing why the session described cannot be - supported. Warning reason codes are listed in Section 20.43. - - - - - -Rosenberg, et. al. Standards Track [Page 192] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - A message body containing a description of media capabilities MAY be - present in the response, which is formatted according to the Accept - header field in the INVITE (or application/sdp if not present), the - same as a message body in a 200 (OK) response to an OPTIONS request. - - It is hoped that negotiation will not frequently be needed, and when - a new user is being invited to join an already existing conference, - negotiation may not be possible. It is up to the invitation - initiator to decide whether or not to act on a 606 (Not Acceptable) - response. - - This status response is returned only if the client knows that no - other end point will answer the request. - -22 Usage of HTTP Authentication - - SIP provides a stateless, challenge-based mechanism for - authentication that is based on authentication in HTTP. Any time - that a proxy server or UA receives a request (with the exceptions - given in Section 22.1), it MAY challenge the initiator of the request - to provide assurance of its identity. Once the originator has been - identified, the recipient of the request SHOULD ascertain whether or - not this user is authorized to make the request in question. No - authorization systems are recommended or discussed in this document. - - The "Digest" authentication mechanism described in this section - provides message authentication and replay protection only, without - message integrity or confidentiality. Protective measures above and - beyond those provided by Digest need to be taken to prevent active - attackers from modifying SIP requests and responses. - - Note that due to its weak security, the usage of "Basic" - authentication has been deprecated. Servers MUST NOT accept - credentials using the "Basic" authorization scheme, and servers also - MUST NOT challenge with "Basic". This is a change from RFC 2543. - -22.1 Framework - - The framework for SIP authentication closely parallels that of HTTP - (RFC 2617 [17]). In particular, the BNF for auth-scheme, auth-param, - challenge, realm, realm-value, and credentials is identical (although - the usage of "Basic" as a scheme is not permitted). In SIP, a UAS - uses the 401 (Unauthorized) response to challenge the identity of a - UAC. Additionally, registrars and redirect servers MAY make use of - 401 (Unauthorized) responses for authentication, but proxies MUST - NOT, and instead MAY use the 407 (Proxy Authentication Required) - - - - - -Rosenberg, et. al. Standards Track [Page 193] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - response. The requirements for inclusion of the Proxy-Authenticate, - Proxy-Authorization, WWW-Authenticate, and Authorization in the - various messages are identical to those described in RFC 2617 [17]. - - Since SIP does not have the concept of a canonical root URL, the - notion of protection spaces is interpreted differently in SIP. The - realm string alone defines the protection domain. This is a change - from RFC 2543, in which the Request-URI and the realm together - defined the protection domain. - - This previous definition of protection domain caused some amount - of confusion since the Request-URI sent by the UAC and the - Request-URI received by the challenging server might be different, - and indeed the final form of the Request-URI might not be known to - the UAC. Also, the previous definition depended on the presence - of a SIP URI in the Request-URI and seemed to rule out alternative - URI schemes (for example, the tel URL). - - Operators of user agents or proxy servers that will authenticate - received requests MUST adhere to the following guidelines for - creation of a realm string for their server: - - o Realm strings MUST be globally unique. It is RECOMMENDED that - a realm string contain a hostname or domain name, following the - recommendation in Section 3.2.1 of RFC 2617 [17]. - - o Realm strings SHOULD present a human-readable identifier that - can be rendered to a user. - - For example: - - INVITE sip:bob@biloxi.com SIP/2.0 - Authorization: Digest realm="biloxi.com", <...> - - Generally, SIP authentication is meaningful for a specific realm, a - protection domain. Thus, for Digest authentication, each such - protection domain has its own set of usernames and passwords. If a - server does not require authentication for a particular request, it - MAY accept a default username, "anonymous", which has no password - (password of ""). Similarly, UACs representing many users, such as - PSTN gateways, MAY have their own device-specific username and - password, rather than accounts for particular users, for their realm. - - While a server can legitimately challenge most SIP requests, there - are two requests defined by this document that require special - handling for authentication: ACK and CANCEL. - - - - - -Rosenberg, et. al. Standards Track [Page 194] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Under an authentication scheme that uses responses to carry values - used to compute nonces (such as Digest), some problems come up for - any requests that take no response, including ACK. For this reason, - any credentials in the INVITE that were accepted by a server MUST be - accepted by that server for the ACK. UACs creating an ACK message - will duplicate all of the Authorization and Proxy-Authorization - header field values that appeared in the INVITE to which the ACK - corresponds. Servers MUST NOT attempt to challenge an ACK. - - Although the CANCEL method does take a response (a 2xx), servers MUST - NOT attempt to challenge CANCEL requests since these requests cannot - be resubmitted. Generally, a CANCEL request SHOULD be accepted by a - server if it comes from the same hop that sent the request being - canceled (provided that some sort of transport or network layer - security association, as described in Section 26.2.1, is in place). - - When a UAC receives a challenge, it SHOULD render to the user the - contents of the "realm" parameter in the challenge (which appears in - either a WWW-Authenticate header field or Proxy-Authenticate header - field) if the UAC device does not already know of a credential for - the realm in question. A service provider that pre-configures UAs - with credentials for its realm should be aware that users will not - have the opportunity to present their own credentials for this realm - when challenged at a pre-configured device. - - Finally, note that even if a UAC can locate credentials that are - associated with the proper realm, the potential exists that these - credentials may no longer be valid or that the challenging server - will not accept these credentials for whatever reason (especially - when "anonymous" with no password is submitted). In this instance a - server may repeat its challenge, or it may respond with a 403 - Forbidden. A UAC MUST NOT re-attempt requests with the credentials - that have just been rejected (though the request may be retried if - the nonce was stale). - -22.2 User-to-User Authentication - - When a UAS receives a request from a UAC, the UAS MAY authenticate - the originator before the request is processed. If no credentials - (in the Authorization header field) are provided in the request, the - UAS can challenge the originator to provide credentials by rejecting - the request with a 401 (Unauthorized) status code. - - The WWW-Authenticate response-header field MUST be included in 401 - (Unauthorized) response messages. The field value consists of at - least one challenge that indicates the authentication scheme(s) and - parameters applicable to the realm. - - - - -Rosenberg, et. al. Standards Track [Page 195] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - An example of the WWW-Authenticate header field in a 401 challenge - is: - - WWW-Authenticate: Digest - realm="biloxi.com", - qop="auth,auth-int", - nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", - opaque="5ccc069c403ebaf9f0171e9517f40e41" - - When the originating UAC receives the 401 (Unauthorized), it SHOULD, - if it is able, re-originate the request with the proper credentials. - The UAC may require input from the originating user before - proceeding. Once authentication credentials have been supplied - (either directly by the user, or discovered in an internal keyring), - UAs SHOULD cache the credentials for a given value of the To header - field and "realm" and attempt to re-use these values on the next - request for that destination. UAs MAY cache credentials in any way - they would like. - - If no credentials for a realm can be located, UACs MAY attempt to - retry the request with a username of "anonymous" and no password (a - password of ""). - - Once credentials have been located, any UA that wishes to - authenticate itself with a UAS or registrar -- usually, but not - necessarily, after receiving a 401 (Unauthorized) response -- MAY do - so by including an Authorization header field with the request. The - Authorization field value consists of credentials containing the - authentication information of the UA for the realm of the resource - being requested as well as parameters required in support of - authentication and replay protection. - - An example of the Authorization header field is: - - Authorization: Digest username="bob", - realm="biloxi.com", - nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", - uri="sip:bob@biloxi.com", - qop=auth, - nc=00000001, - cnonce="0a4f113b", - response="6629fae49393a05397450978507c4ef1", - opaque="5ccc069c403ebaf9f0171e9517f40e41" - - When a UAC resubmits a request with its credentials after receiving a - 401 (Unauthorized) or 407 (Proxy Authentication Required) response, - it MUST increment the CSeq header field value as it would normally - when sending an updated request. - - - -Rosenberg, et. al. Standards Track [Page 196] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -22.3 Proxy-to-User Authentication - - Similarly, when a UAC sends a request to a proxy server, the proxy - server MAY authenticate the originator before the request is - processed. If no credentials (in the Proxy-Authorization header - field) are provided in the request, the proxy can challenge the - originator to provide credentials by rejecting the request with a 407 - (Proxy Authentication Required) status code. The proxy MUST populate - the 407 (Proxy Authentication Required) message with a Proxy- - Authenticate header field value applicable to the proxy for the - requested resource. - - The use of Proxy-Authenticate and Proxy-Authorization parallel that - described in [17], with one difference. Proxies MUST NOT add values - to the Proxy-Authorization header field. All 407 (Proxy - Authentication Required) responses MUST be forwarded upstream toward - the UAC following the procedures for any other response. It is the - UAC's responsibility to add the Proxy-Authorization header field - value containing credentials for the realm of the proxy that has - asked for authentication. - - If a proxy were to resubmit a request adding a Proxy-Authorization - header field value, it would need to increment the CSeq in the new - request. However, this would cause the UAC that submitted the - original request to discard a response from the UAS, as the CSeq - value would be different. - - When the originating UAC receives the 407 (Proxy Authentication - Required) it SHOULD, if it is able, re-originate the request with the - proper credentials. It should follow the same procedures for the - display of the "realm" parameter that are given above for responding - to 401. - - If no credentials for a realm can be located, UACs MAY attempt to - retry the request with a username of "anonymous" and no password (a - password of ""). - - The UAC SHOULD also cache the credentials used in the re-originated - request. - - The following rule is RECOMMENDED for proxy credential caching: - - If a UA receives a Proxy-Authenticate header field value in a 401/407 - response to a request with a particular Call-ID, it should - incorporate credentials for that realm in all subsequent requests - that contain the same Call-ID. These credentials MUST NOT be cached - across dialogs; however, if a UA is configured with the realm of its - local outbound proxy, when one exists, then the UA MAY cache - - - -Rosenberg, et. al. Standards Track [Page 197] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - credentials for that realm across dialogs. Note that this does mean - a future request in a dialog could contain credentials that are not - needed by any proxy along the Route header path. - - Any UA that wishes to authenticate itself to a proxy server -- - usually, but not necessarily, after receiving a 407 (Proxy - Authentication Required) response -- MAY do so by including a Proxy- - Authorization header field value with the request. The Proxy- - Authorization request-header field allows the client to identify - itself (or its user) to a proxy that requires authentication. The - Proxy-Authorization header field value consists of credentials - containing the authentication information of the UA for the proxy - and/or realm of the resource being requested. - - A Proxy-Authorization header field value applies only to the proxy - whose realm is identified in the "realm" parameter (this proxy may - previously have demanded authentication using the Proxy-Authenticate - field). When multiple proxies are used in a chain, a Proxy- - Authorization header field value MUST NOT be consumed by any proxy - whose realm does not match the "realm" parameter specified in that - value. - - Note that if an authentication scheme that does not support realms is - used in the Proxy-Authorization header field, a proxy server MUST - attempt to parse all Proxy-Authorization header field values to - determine whether one of them has what the proxy server considers to - be valid credentials. Because this is potentially very time- - consuming in large networks, proxy servers SHOULD use an - authentication scheme that supports realms in the Proxy-Authorization - header field. - - If a request is forked (as described in Section 16.7), various proxy - servers and/or UAs may wish to challenge the UAC. In this case, the - forking proxy server is responsible for aggregating these challenges - into a single response. Each WWW-Authenticate and Proxy-Authenticate - value received in responses to the forked request MUST be placed into - the single response that is sent by the forking proxy to the UA; the - ordering of these header field values is not significant. - - When a proxy server issues a challenge in response to a request, - it will not proxy the request until the UAC has retried the - request with valid credentials. A forking proxy may forward a - request simultaneously to multiple proxy servers that require - authentication, each of which in turn will not forward the request - until the originating UAC has authenticated itself in their - respective realm. If the UAC does not provide credentials for - - - - - -Rosenberg, et. al. Standards Track [Page 198] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - each challenge, the proxy servers that issued the challenges will - not forward requests to the UA where the destination user might be - located, and therefore, the virtues of forking are largely lost. - - When resubmitting its request in response to a 401 (Unauthorized) or - 407 (Proxy Authentication Required) that contains multiple - challenges, a UAC MAY include an Authorization value for each WWW- - Authenticate value and a Proxy-Authorization value for each Proxy- - Authenticate value for which the UAC wishes to supply a credential. - As noted above, multiple credentials in a request SHOULD be - differentiated by the "realm" parameter. - - It is possible for multiple challenges associated with the same realm - to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication - Required). This can occur, for example, when multiple proxies within - the same administrative domain, which use a common realm, are reached - by a forking request. When it retries a request, a UAC MAY therefore - supply multiple credentials in Authorization or Proxy-Authorization - header fields with the same "realm" parameter value. The same - credentials SHOULD be used for the same realm. - -22.4 The Digest Authentication Scheme - - This section describes the modifications and clarifications required - to apply the HTTP Digest authentication scheme to SIP. The SIP - scheme usage is almost completely identical to that for HTTP [17]. - - Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [39], - SIP servers supporting RFC 2617 MUST ensure they are backwards - compatible with RFC 2069. Procedures for this backwards - compatibility are specified in RFC 2617. Note, however, that SIP - servers MUST NOT accept or request Basic authentication. - - The rules for Digest authentication follow those defined in [17], - with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following - differences: - - 1. The URI included in the challenge has the following BNF: - - URI = SIP-URI / SIPS-URI - - 2. The BNF in RFC 2617 has an error in that the 'uri' parameter - of the Authorization header field for HTTP Digest - - - - - - - - -Rosenberg, et. al. Standards Track [Page 199] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - authentication is not enclosed in quotation marks. (The - example in Section 3.5 of RFC 2617 is correct.) For SIP, the - 'uri' MUST be enclosed in quotation marks. - - 3. The BNF for digest-uri-value is: - - digest-uri-value = Request-URI ; as defined in Section 25 - - 4. The example procedure for choosing a nonce based on Etag does - not work for SIP. - - 5. The text in RFC 2617 [17] regarding cache operation does not - apply to SIP. - - 6. RFC 2617 [17] requires that a server check that the URI in the - request line and the URI included in the Authorization header - field point to the same resource. In a SIP context, these two - URIs may refer to different users, due to forwarding at some - proxy. Therefore, in SIP, a server MAY check that the - Request-URI in the Authorization header field value - corresponds to a user for whom the server is willing to accept - forwarded or direct requests, but it is not necessarily a - failure if the two fields are not equivalent. - - 7. As a clarification to the calculation of the A2 value for - message integrity assurance in the Digest authentication - scheme, implementers should assume, when the entity-body is - empty (that is, when SIP messages have no body) that the hash - of the entity-body resolves to the MD5 hash of an empty - string, or: - - H(entity-body) = MD5("") = - "d41d8cd98f00b204e9800998ecf8427e" - - 8. RFC 2617 notes that a cnonce value MUST NOT be sent in an - Authorization (and by extension Proxy-Authorization) header - field if no qop directive has been sent. Therefore, any - algorithms that have a dependency on the cnonce (including - "MD5-Sess") require that the qop directive be sent. Use of - the "qop" parameter is optional in RFC 2617 for the purposes - of backwards compatibility with RFC 2069; since RFC 2543 was - based on RFC 2069, the "qop" parameter must unfortunately - remain optional for clients and servers to receive. However, - servers MUST always send a "qop" parameter in WWW-Authenticate - and Proxy-Authenticate header field values. If a client - receives a "qop" parameter in a challenge header field, it - MUST send the "qop" parameter in any resulting authorization - header field. - - - -Rosenberg, et. al. Standards Track [Page 200] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - RFC 2543 did not allow usage of the Authentication-Info header field - (it effectively used RFC 2069). However, we now allow usage of this - header field, since it provides integrity checks over the bodies and - provides mutual authentication. RFC 2617 [17] defines mechanisms for - backwards compatibility using the qop attribute in the request. - These mechanisms MUST be used by a server to determine if the client - supports the new mechanisms in RFC 2617 that were not specified in - RFC 2069. - -23 S/MIME - - SIP messages carry MIME bodies and the MIME standard includes - mechanisms for securing MIME contents to ensure both integrity and - confidentiality (including the 'multipart/signed' and - 'application/pkcs7-mime' MIME types, see RFC 1847 [22], RFC 2630 [23] - and RFC 2633 [24]). Implementers should note, however, that there - may be rare network intermediaries (not typical proxy servers) that - rely on viewing or modifying the bodies of SIP messages (especially - SDP), and that secure MIME may prevent these sorts of intermediaries - from functioning. - - This applies particularly to certain types of firewalls. - - The PGP mechanism for encrypting the header fields and bodies of - SIP messages described in RFC 2543 has been deprecated. - -23.1 S/MIME Certificates - - The certificates that are used to identify an end-user for the - purposes of S/MIME differ from those used by servers in one important - respect - rather than asserting that the identity of the holder - corresponds to a particular hostname, these certificates assert that - the holder is identified by an end-user address. This address is - composed of the concatenation of the "userinfo" "@" and "domainname" - portions of a SIP or SIPS URI (in other words, an email address of - the form "bob@biloxi.com"), most commonly corresponding to a user's - address-of-record. - - These certificates are also associated with keys that are used to - sign or encrypt bodies of SIP messages. Bodies are signed with the - private key of the sender (who may include their public key with the - message as appropriate), but bodies are encrypted with the public key - of the intended recipient. Obviously, senders must have - foreknowledge of the public key of recipients in order to encrypt - message bodies. Public keys can be stored within a UA on a virtual - keyring. - - - - - -Rosenberg, et. al. Standards Track [Page 201] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Each user agent that supports S/MIME MUST contain a keyring - specifically for end-users' certificates. This keyring should map - between addresses of record and corresponding certificates. Over - time, users SHOULD use the same certificate when they populate the - originating URI of signaling (the From header field) with the same - address-of-record. - - Any mechanisms depending on the existence of end-user certificates - are seriously limited in that there is virtually no consolidated - authority today that provides certificates for end-user applications. - However, users SHOULD acquire certificates from known public - certificate authorities. As an alternative, users MAY create self- - signed certificates. The implications of self-signed certificates - are explored further in Section 26.4.2. Implementations may also use - pre-configured certificates in deployments in which a previous trust - relationship exists between all SIP entities. - - Above and beyond the problem of acquiring an end-user certificate, - there are few well-known centralized directories that distribute - end-user certificates. However, the holder of a certificate SHOULD - publish their certificate in any public directories as appropriate. - Similarly, UACs SHOULD support a mechanism for importing (manually or - automatically) certificates discovered in public directories - corresponding to the target URIs of SIP requests. - -23.2 S/MIME Key Exchange - - SIP itself can also be used as a means to distribute public keys in - the following manner. - - Whenever the CMS SignedData message is used in S/MIME for SIP, it - MUST contain the certificate bearing the public key necessary to - verify the signature. - - When a UAC sends a request containing an S/MIME body that initiates a - dialog, or sends a non-INVITE request outside the context of a - dialog, the UAC SHOULD structure the body as an S/MIME - 'multipart/signed' CMS SignedData body. If the desired CMS service - is EnvelopedData (and the public key of the target user is known), - the UAC SHOULD send the EnvelopedData message encapsulated within a - SignedData message. - - When a UAS receives a request containing an S/MIME CMS body that - includes a certificate, the UAS SHOULD first validate the - certificate, if possible, with any available root certificates for - certificate authorities. The UAS SHOULD also determine the subject - of the certificate (for S/MIME, the SubjectAltName will contain the - appropriate identity) and compare this value to the From header field - - - -Rosenberg, et. al. Standards Track [Page 202] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - of the request. If the certificate cannot be verified, because it is - self-signed, or signed by no known authority, or if it is verifiable - but its subject does not correspond to the From header field of - request, the UAS MUST notify its user of the status of the - certificate (including the subject of the certificate, its signer, - and any key fingerprint information) and request explicit permission - before proceeding. If the certificate was successfully verified and - the subject of the certificate corresponds to the From header field - of the SIP request, or if the user (after notification) explicitly - authorizes the use of the certificate, the UAS SHOULD add this - certificate to a local keyring, indexed by the address-of-record of - the holder of the certificate. - - When a UAS sends a response containing an S/MIME body that answers - the first request in a dialog, or a response to a non-INVITE request - outside the context of a dialog, the UAS SHOULD structure the body as - an S/MIME 'multipart/signed' CMS SignedData body. If the desired CMS - service is EnvelopedData, the UAS SHOULD send the EnvelopedData - message encapsulated within a SignedData message. - - When a UAC receives a response containing an S/MIME CMS body that - includes a certificate, the UAC SHOULD first validate the - certificate, if possible, with any appropriate root certificate. The - UAC SHOULD also determine the subject of the certificate and compare - this value to the To field of the response; although the two may very - well be different, and this is not necessarily indicative of a - security breach. If the certificate cannot be verified because it is - self-signed, or signed by no known authority, the UAC MUST notify its - user of the status of the certificate (including the subject of the - certificate, its signator, and any key fingerprint information) and - request explicit permission before proceeding. If the certificate - was successfully verified, and the subject of the certificate - corresponds to the To header field in the response, or if the user - (after notification) explicitly authorizes the use of the - certificate, the UAC SHOULD add this certificate to a local keyring, - indexed by the address-of-record of the holder of the certificate. - If the UAC had not transmitted its own certificate to the UAS in any - previous transaction, it SHOULD use a CMS SignedData body for its - next request or response. - - On future occasions, when the UA receives requests or responses that - contain a From header field corresponding to a value in its keyring, - the UA SHOULD compare the certificate offered in these messages with - the existing certificate in its keyring. If there is a discrepancy, - the UA MUST notify its user of a change of the certificate - (preferably in terms that indicate that this is a potential security - breach) and acquire the user's permission before continuing to - - - - -Rosenberg, et. al. Standards Track [Page 203] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - process the signaling. If the user authorizes this certificate, it - SHOULD be added to the keyring alongside any previous value(s) for - this address-of-record. - - Note well however, that this key exchange mechanism does not - guarantee the secure exchange of keys when self-signed certificates, - or certificates signed by an obscure authority, are used - it is - vulnerable to well-known attacks. In the opinion of the authors, - however, the security it provides is proverbially better than - nothing; it is in fact comparable to the widely used SSH application. - These limitations are explored in greater detail in Section 26.4.2. - - If a UA receives an S/MIME body that has been encrypted with a public - key unknown to the recipient, it MUST reject the request with a 493 - (Undecipherable) response. This response SHOULD contain a valid - certificate for the respondent (corresponding, if possible, to any - address of record given in the To header field of the rejected - request) within a MIME body with a 'certs-only' "smime-type" - parameter. - - A 493 (Undecipherable) sent without any certificate indicates that - the respondent cannot or will not utilize S/MIME encrypted messages, - though they may still support S/MIME signatures. - - Note that a user agent that receives a request containing an S/MIME - body that is not optional (with a Content-Disposition header - "handling" parameter of "required") MUST reject the request with a - 415 Unsupported Media Type response if the MIME type is not - understood. A user agent that receives such a response when S/MIME - is sent SHOULD notify its user that the remote device does not - support S/MIME, and it MAY subsequently resend the request without - S/MIME, if appropriate; however, this 415 response may constitute a - downgrade attack. - - If a user agent sends an S/MIME body in a request, but receives a - response that contains a MIME body that is not secured, the UAC - SHOULD notify its user that the session could not be secured. - However, if a user agent that supports S/MIME receives a request with - an unsecured body, it SHOULD NOT respond with a secured body, but if - it expects S/MIME from the sender (for example, because the sender's - From header field value corresponds to an identity on its keychain), - the UAS SHOULD notify its user that the session could not be secured. - - A number of conditions that arise in the previous text call for the - notification of the user when an anomalous certificate-management - event occurs. Users might well ask what they should do under these - circumstances. First and foremost, an unexpected change in a - certificate, or an absence of security when security is expected, are - - - -Rosenberg, et. al. Standards Track [Page 204] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - causes for caution but not necessarily indications that an attack is - in progress. Users might abort any connection attempt or refuse a - connection request they have received; in telephony parlance, they - could hang up and call back. Users may wish to find an alternate - means to contact the other party and confirm that their key has - legitimately changed. Note that users are sometimes compelled to - change their certificates, for example when they suspect that the - secrecy of their private key has been compromised. When their - private key is no longer private, users must legitimately generate a - new key and re-establish trust with any users that held their old - key. - - Finally, if during the course of a dialog a UA receives a certificate - in a CMS SignedData message that does not correspond with the - certificates previously exchanged during a dialog, the UA MUST notify - its user of the change, preferably in terms that indicate that this - is a potential security breach. - -23.3 Securing MIME bodies - - There are two types of secure MIME bodies that are of interest to - SIP: use of these bodies should follow the S/MIME specification [24] - with a few variations. - - o "multipart/signed" MUST be used only with CMS detached - signatures. - - This allows backwards compatibility with non-S/MIME- - compliant recipients. - - o S/MIME bodies SHOULD have a Content-Disposition header field, - and the value of the "handling" parameter SHOULD be "required." - - o If a UAC has no certificate on its keyring associated with the - address-of-record to which it wants to send a request, it - cannot send an encrypted "application/pkcs7-mime" MIME message. - UACs MAY send an initial request such as an OPTIONS message - with a CMS detached signature in order to solicit the - certificate of the remote side (the signature SHOULD be over a - "message/sip" body of the type described in Section 23.4). - - Note that future standardization work on S/MIME may define - non-certificate based keys. - - o Senders of S/MIME bodies SHOULD use the "SMIMECapabilities" - (see Section 2.5.2 of [24]) attribute to express their - capabilities and preferences for further communications. Note - especially that senders MAY use the "preferSignedData" - - - -Rosenberg, et. al. Standards Track [Page 205] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - capability to encourage receivers to respond with CMS - SignedData messages (for example, when sending an OPTIONS - request as described above). - - o S/MIME implementations MUST at a minimum support SHA1 as a - digital signature algorithm, and 3DES as an encryption - algorithm. All other signature and encryption algorithms MAY - be supported. Implementations can negotiate support for these - algorithms with the "SMIMECapabilities" attribute. - - o Each S/MIME body in a SIP message SHOULD be signed with only - one certificate. If a UA receives a message with multiple - signatures, the outermost signature should be treated as the - single certificate for this body. Parallel signatures SHOULD - NOT be used. - - The following is an example of an encrypted S/MIME SDP body - within a SIP message: - - INVITE sip:bob@biloxi.com SIP/2.0 - Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 - To: Bob - From: Alice ;tag=1928301774 - Call-ID: a84b4c76e66710 - CSeq: 314159 INVITE - Max-Forwards: 70 - Contact: - Content-Type: application/pkcs7-mime; smime-type=enveloped-data; - name=smime.p7m - Content-Disposition: attachment; filename=smime.p7m - handling=required - - ******************************************************* - * Content-Type: application/sdp * - * * - * v=0 * - * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * - * s=- * - * t=0 0 * - * c=IN IP4 pc33.atlanta.com * - * m=audio 3456 RTP/AVP 0 1 3 99 * - * a=rtpmap:0 PCMU/8000 * - ******************************************************* - - - - - - - - -Rosenberg, et. al. Standards Track [Page 206] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP - - As a means of providing some degree of end-to-end authentication, - integrity or confidentiality for SIP header fields, S/MIME can - encapsulate entire SIP messages within MIME bodies of type - "message/sip" and then apply MIME security to these bodies in the - same manner as typical SIP bodies. These encapsulated SIP requests - and responses do not constitute a separate dialog or transaction, - they are a copy of the "outer" message that is used to verify - integrity or to supply additional information. - - If a UAS receives a request that contains a tunneled "message/sip" - S/MIME body, it SHOULD include a tunneled "message/sip" body in the - response with the same smime-type. - - Any traditional MIME bodies (such as SDP) SHOULD be attached to the - "inner" message so that they can also benefit from S/MIME security. - Note that "message/sip" bodies can be sent as a part of a MIME - "multipart/mixed" body if any unsecured MIME types should also be - transmitted in a request. - -23.4.1 Integrity and Confidentiality Properties of SIP Headers - - When the S/MIME integrity or confidentiality mechanisms are used, - there may be discrepancies between the values in the "inner" message - and values in the "outer" message. The rules for handling any such - differences for all of the header fields described in this document - are given in this section. - - Note that for the purposes of loose timestamping, all SIP messages - that tunnel "message/sip" SHOULD contain a Date header in both the - "inner" and "outer" headers. - -23.4.1.1 Integrity - - Whenever integrity checks are performed, the integrity of a header - field should be determined by matching the value of the header field - in the signed body with that in the "outer" messages using the - comparison rules of SIP as described in 20. - - Header fields that can be legitimately modified by proxy servers are: - Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy- - Authorization. If these header fields are not intact end-to-end, - implementations SHOULD NOT consider this a breach of security. - Changes to any other header fields defined in this document - constitute an integrity violation; users MUST be notified of a - discrepancy. - - - - -Rosenberg, et. al. Standards Track [Page 207] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -23.4.1.2 Confidentiality - - When messages are encrypted, header fields may be included in the - encrypted body that are not present in the "outer" message. - - Some header fields must always have a plaintext version because they - are required header fields in requests and responses - these include: - - To, From, Call-ID, CSeq, Contact. While it is probably not useful to - provide an encrypted alternative for the Call-ID, CSeq, or Contact, - providing an alternative to the information in the "outer" To or From - is permitted. Note that the values in an encrypted body are not used - for the purposes of identifying transactions or dialogs - they are - merely informational. If the From header field in an encrypted body - differs from the value in the "outer" message, the value within the - encrypted body SHOULD be displayed to the user, but MUST NOT be used - in the "outer" header fields of any future messages. - - Primarily, a user agent will want to encrypt header fields that have - an end-to-end semantic, including: Subject, Reply-To, Organization, - Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info, - Authentication-Info, Expires, In-Reply-To, Require, Supported, - Unsupported, Retry-After, User-Agent, Server, and Warning. If any of - these header fields are present in an encrypted body, they should be - used instead of any "outer" header fields, whether this entails - displaying the header field values to users or setting internal - states in the UA. They SHOULD NOT however be used in the "outer" - headers of any future messages. - - If present, the Date header field MUST always be the same in the - "inner" and "outer" headers. - - Since MIME bodies are attached to the "inner" message, - implementations will usually encrypt MIME-specific header fields, - including: MIME-Version, Content-Type, Content-Length, Content- - Language, Content-Encoding and Content-Disposition. The "outer" - message will have the proper MIME header fields for S/MIME bodies. - These header fields (and any MIME bodies they preface) should be - treated as normal MIME header fields and bodies received in a SIP - message. - - It is not particularly useful to encrypt the following header fields: - Min-Expires, Timestamp, Authorization, Priority, and WWW- - Authenticate. This category also includes those header fields that - can be changed by proxy servers (described in the preceding section). - UAs SHOULD never include these in an "inner" message if they are not - - - - - -Rosenberg, et. al. Standards Track [Page 208] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - included in the "outer" message. UAs that receive any of these - header fields in an encrypted body SHOULD ignore the encrypted - values. - - Note that extensions to SIP may define additional header fields; the - authors of these extensions should describe the integrity and - confidentiality properties of such header fields. If a SIP UA - encounters an unknown header field with an integrity violation, it - MUST ignore the header field. - -23.4.2 Tunneling Integrity and Authentication - - Tunneling SIP messages within S/MIME bodies can provide integrity for - SIP header fields if the header fields that the sender wishes to - secure are replicated in a "message/sip" MIME body signed with a CMS - detached signature. - - Provided that the "message/sip" body contains at least the - fundamental dialog identifiers (To, From, Call-ID, CSeq), then a - signed MIME body can provide limited authentication. At the very - least, if the certificate used to sign the body is unknown to the - recipient and cannot be verified, the signature can be used to - ascertain that a later request in a dialog was transmitted by the - same certificate-holder that initiated the dialog. If the recipient - of the signed MIME body has some stronger incentive to trust the - certificate (they were able to validate it, they acquired it from a - trusted repository, or they have used it frequently) then the - signature can be taken as a stronger assertion of the identity of the - subject of the certificate. - - In order to eliminate possible confusions about the addition or - subtraction of entire header fields, senders SHOULD replicate all - header fields from the request within the signed body. Any message - bodies that require integrity protection MUST be attached to the - "inner" message. - - If a Date header is present in a message with a signed body, the - recipient SHOULD compare the header field value with its own internal - clock, if applicable. If a significant time discrepancy is detected - (on the order of an hour or more), the user agent SHOULD alert the - user to the anomaly, and note that it is a potential security breach. - - If an integrity violation in a message is detected by its recipient, - the message MAY be rejected with a 403 (Forbidden) response if it is - a request, or any existing dialog MAY be terminated. UAs SHOULD - notify users of this circumstance and request explicit guidance on - how to proceed. - - - - -Rosenberg, et. al. Standards Track [Page 209] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The following is an example of the use of a tunneled "message/sip" - body: - - INVITE sip:bob@biloxi.com SIP/2.0 - Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 - To: Bob - From: Alice ;tag=1928301774 - Call-ID: a84b4c76e66710 - CSeq: 314159 INVITE - Max-Forwards: 70 - Date: Thu, 21 Feb 2002 13:02:03 GMT - Contact: - Content-Type: multipart/signed; - protocol="application/pkcs7-signature"; - micalg=sha1; boundary=boundary42 - Content-Length: 568 - - --boundary42 - Content-Type: message/sip - - INVITE sip:bob@biloxi.com SIP/2.0 - Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 - To: Bob - From: Alice ;tag=1928301774 - Call-ID: a84b4c76e66710 - CSeq: 314159 INVITE - Max-Forwards: 70 - Date: Thu, 21 Feb 2002 13:02:03 GMT - Contact: - Content-Type: application/sdp - Content-Length: 147 - - v=0 - o=UserA 2890844526 2890844526 IN IP4 here.com - s=Session SDP - c=IN IP4 pc33.atlanta.com - t=0 0 - m=audio 49172 RTP/AVP 0 - a=rtpmap:0 PCMU/8000 - - --boundary42 - Content-Type: application/pkcs7-signature; name=smime.p7s - Content-Transfer-Encoding: base64 - Content-Disposition: attachment; filename=smime.p7s; - handling=required - - - - - - -Rosenberg, et. al. Standards Track [Page 210] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 - 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj - n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 - 7GhIGfHfYT64VQbnj756 - - --boundary42- - -23.4.3 Tunneling Encryption - - It may also be desirable to use this mechanism to encrypt a - "message/sip" MIME body within a CMS EnvelopedData message S/MIME - body, but in practice, most header fields are of at least some use to - the network; the general use of encryption with S/MIME is to secure - message bodies like SDP rather than message headers. Some - informational header fields, such as the Subject or Organization - could perhaps warrant end-to-end security. Headers defined by future - SIP applications might also require obfuscation. - - Another possible application of encrypting header fields is selective - anonymity. A request could be constructed with a From header field - that contains no personal information (for example, - sip:anonymous@anonymizer.invalid). However, a second From header - field containing the genuine address-of-record of the originator - could be encrypted within a "message/sip" MIME body where it will - only be visible to the endpoints of a dialog. - - Note that if this mechanism is used for anonymity, the From header - field will no longer be usable by the recipient of a message as an - index to their certificate keychain for retrieving the proper - S/MIME key to associated with the sender. The message must first - be decrypted, and the "inner" From header field MUST be used as an - index. - - In order to provide end-to-end integrity, encrypted "message/sip" - MIME bodies SHOULD be signed by the sender. This creates a - "multipart/signed" MIME body that contains an encrypted body and a - signature, both of type "application/pkcs7-mime". - - - - - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 211] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - In the following example, of an encrypted and signed message, the - text boxed in asterisks ("*") is encrypted: - - INVITE sip:bob@biloxi.com SIP/2.0 - Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 - To: Bob - From: Anonymous ;tag=1928301774 - Call-ID: a84b4c76e66710 - CSeq: 314159 INVITE - Max-Forwards: 70 - Date: Thu, 21 Feb 2002 13:02:03 GMT - Contact: - Content-Type: multipart/signed; - protocol="application/pkcs7-signature"; - micalg=sha1; boundary=boundary42 - Content-Length: 568 - - --boundary42 - Content-Type: application/pkcs7-mime; smime-type=enveloped-data; - name=smime.p7m - Content-Transfer-Encoding: base64 - Content-Disposition: attachment; filename=smime.p7m - handling=required - Content-Length: 231 - - *********************************************************** - * Content-Type: message/sip * - * * - * INVITE sip:bob@biloxi.com SIP/2.0 * - * Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 * - * To: Bob * - * From: Alice ;tag=1928301774 * - * Call-ID: a84b4c76e66710 * - * CSeq: 314159 INVITE * - * Max-Forwards: 70 * - * Date: Thu, 21 Feb 2002 13:02:03 GMT * - * Contact: * - * * - * Content-Type: application/sdp * - * * - * v=0 * - * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * - * s=Session SDP * - * t=0 0 * - * c=IN IP4 pc33.atlanta.com * - * m=audio 3456 RTP/AVP 0 1 3 99 * - * a=rtpmap:0 PCMU/8000 * - *********************************************************** - - - -Rosenberg, et. al. Standards Track [Page 212] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - --boundary42 - Content-Type: application/pkcs7-signature; name=smime.p7s - Content-Transfer-Encoding: base64 - Content-Disposition: attachment; filename=smime.p7s; - handling=required - - ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 - 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj - n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 - 7GhIGfHfYT64VQbnj756 - - --boundary42- - -24 Examples - - In the following examples, we often omit the message body and the - corresponding Content-Length and Content-Type header fields for - brevity. - -24.1 Registration - - Bob registers on start-up. The message flow is shown in Figure 9. - Note that the authentication usually required for registration is not - shown for simplicity. - - biloxi.com Bob's - registrar softphone - | | - | REGISTER F1 | - |<---------------| - | 200 OK F2 | - |--------------->| - - Figure 9: SIP Registration Example - - F1 REGISTER Bob -> Registrar - - REGISTER sip:registrar.biloxi.com SIP/2.0 - Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 - Max-Forwards: 70 - To: Bob - From: Bob ;tag=456248 - Call-ID: 843817637684230@998sdasdh09 - CSeq: 1826 REGISTER - Contact: - Expires: 7200 - Content-Length: 0 - - - - -Rosenberg, et. al. Standards Track [Page 213] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The registration expires after two hours. The registrar responds - with a 200 OK: - - F2 200 OK Registrar -> Bob - - SIP/2.0 200 OK - Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 - ;received=192.0.2.4 - To: Bob ;tag=2493k59kd - From: Bob ;tag=456248 - Call-ID: 843817637684230@998sdasdh09 - CSeq: 1826 REGISTER - Contact: - Expires: 7200 - Content-Length: 0 - -24.2 Session Setup - - This example contains the full details of the example session setup - in Section 4. The message flow is shown in Figure 1. Note that - these flows show the minimum required set of header fields - some - other header fields such as Allow and Supported would normally be - present. - -F1 INVITE Alice -> atlanta.com proxy - -INVITE sip:bob@biloxi.com SIP/2.0 -Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 -Max-Forwards: 70 -To: Bob -From: Alice ;tag=1928301774 -Call-ID: a84b4c76e66710 -CSeq: 314159 INVITE -Contact: -Content-Type: application/sdp -Content-Length: 142 - -(Alice's SDP not shown) - - - - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 214] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -F2 100 Trying atlanta.com proxy -> Alice - -SIP/2.0 100 Trying -Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 - ;received=192.0.2.1 -To: Bob -From: Alice ;tag=1928301774 -Call-ID: a84b4c76e66710 -CSeq: 314159 INVITE -Content-Length: 0 - -F3 INVITE atlanta.com proxy -> biloxi.com proxy - -INVITE sip:bob@biloxi.com SIP/2.0 -Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 -Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 - ;received=192.0.2.1 -Max-Forwards: 69 -To: Bob -From: Alice ;tag=1928301774 -Call-ID: a84b4c76e66710 -CSeq: 314159 INVITE -Contact: -Content-Type: application/sdp -Content-Length: 142 - -(Alice's SDP not shown) - -F4 100 Trying biloxi.com proxy -> atlanta.com proxy - -SIP/2.0 100 Trying -Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 - ;received=192.0.2.2 -Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 - ;received=192.0.2.1 -To: Bob -From: Alice ;tag=1928301774 -Call-ID: a84b4c76e66710 -CSeq: 314159 INVITE -Content-Length: 0 - - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 215] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -F5 INVITE biloxi.com proxy -> Bob - -INVITE sip:bob@192.0.2.4 SIP/2.0 -Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 -Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 - ;received=192.0.2.2 -Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 - ;received=192.0.2.1 -Max-Forwards: 68 -To: Bob -From: Alice ;tag=1928301774 -Call-ID: a84b4c76e66710 -CSeq: 314159 INVITE -Contact: -Content-Type: application/sdp -Content-Length: 142 - -(Alice's SDP not shown) - -F6 180 Ringing Bob -> biloxi.com proxy - -SIP/2.0 180 Ringing -Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 - ;received=192.0.2.3 -Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 - ;received=192.0.2.2 -Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 - ;received=192.0.2.1 -To: Bob ;tag=a6c85cf -From: Alice ;tag=1928301774 -Call-ID: a84b4c76e66710 -Contact: -CSeq: 314159 INVITE -Content-Length: 0 - -F7 180 Ringing biloxi.com proxy -> atlanta.com proxy - -SIP/2.0 180 Ringing -Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 - ;received=192.0.2.2 -Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 - ;received=192.0.2.1 -To: Bob ;tag=a6c85cf -From: Alice ;tag=1928301774 -Call-ID: a84b4c76e66710 -Contact: -CSeq: 314159 INVITE -Content-Length: 0 - - - -Rosenberg, et. al. Standards Track [Page 216] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -F8 180 Ringing atlanta.com proxy -> Alice - -SIP/2.0 180 Ringing -Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 - ;received=192.0.2.1 -To: Bob ;tag=a6c85cf -From: Alice ;tag=1928301774 -Call-ID: a84b4c76e66710 -Contact: -CSeq: 314159 INVITE -Content-Length: 0 - -F9 200 OK Bob -> biloxi.com proxy - -SIP/2.0 200 OK -Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 - ;received=192.0.2.3 -Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 - ;received=192.0.2.2 -Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 - ;received=192.0.2.1 -To: Bob ;tag=a6c85cf -From: Alice ;tag=1928301774 -Call-ID: a84b4c76e66710 -CSeq: 314159 INVITE -Contact: -Content-Type: application/sdp -Content-Length: 131 - -(Bob's SDP not shown) - -F10 200 OK biloxi.com proxy -> atlanta.com proxy - -SIP/2.0 200 OK -Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 - ;received=192.0.2.2 -Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 - ;received=192.0.2.1 -To: Bob ;tag=a6c85cf -From: Alice ;tag=1928301774 -Call-ID: a84b4c76e66710 -CSeq: 314159 INVITE -Contact: -Content-Type: application/sdp -Content-Length: 131 - -(Bob's SDP not shown) - - - - -Rosenberg, et. al. Standards Track [Page 217] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -F11 200 OK atlanta.com proxy -> Alice - -SIP/2.0 200 OK -Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 - ;received=192.0.2.1 -To: Bob ;tag=a6c85cf -From: Alice ;tag=1928301774 -Call-ID: a84b4c76e66710 -CSeq: 314159 INVITE -Contact: -Content-Type: application/sdp -Content-Length: 131 - -(Bob's SDP not shown) - -F12 ACK Alice -> Bob - -ACK sip:bob@192.0.2.4 SIP/2.0 -Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 -Max-Forwards: 70 -To: Bob ;tag=a6c85cf -From: Alice ;tag=1928301774 -Call-ID: a84b4c76e66710 -CSeq: 314159 ACK -Content-Length: 0 - - The media session between Alice and Bob is now established. - - Bob hangs up first. Note that Bob's SIP phone maintains its own CSeq - numbering space, which, in this example, begins with 231. Since Bob - is making the request, the To and From URIs and tags have been - swapped. - -F13 BYE Bob -> Alice - -BYE sip:alice@pc33.atlanta.com SIP/2.0 -Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 -Max-Forwards: 70 -From: Bob ;tag=a6c85cf -To: Alice ;tag=1928301774 -Call-ID: a84b4c76e66710 -CSeq: 231 BYE -Content-Length: 0 - - - - - - - - -Rosenberg, et. al. Standards Track [Page 218] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -F14 200 OK Alice -> Bob - -SIP/2.0 200 OK -Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 -From: Bob ;tag=a6c85cf -To: Alice ;tag=1928301774 -Call-ID: a84b4c76e66710 -CSeq: 231 BYE -Content-Length: 0 - - The SIP Call Flows document [40] contains further examples of SIP - messages. - -25 Augmented BNF for the SIP Protocol - - All of the mechanisms specified in this document are described in - both prose and an augmented Backus-Naur Form (BNF) defined in RFC - 2234 [10]. Section 6.1 of RFC 2234 defines a set of core rules that - are used by this specification, and not repeated here. Implementers - need to be familiar with the notation and content of RFC 2234 in - order to understand this specification. Certain basic rules are in - uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle - brackets are used within definitions to clarify the use of rule - names. - - The use of square brackets is redundant syntactically. It is used as - a semantic hint that the specific parameter is optional to use. - -25.1 Basic Rules - - The following rules are used throughout this specification to - describe basic parsing constructs. The US-ASCII coded character set - is defined by ANSI X3.4-1986. - - alphanum = ALPHA / DIGIT - - - - - - - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 219] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Several rules are incorporated from RFC 2396 [5] but are updated to - make them compliant with RFC 2234 [10]. These include: - - reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" - / "$" / "," - unreserved = alphanum / mark - mark = "-" / "_" / "." / "!" / "~" / "*" / "'" - / "(" / ")" - escaped = "%" HEXDIG HEXDIG - - SIP header field values can be folded onto multiple lines if the - continuation line begins with a space or horizontal tab. All linear - white space, including folding, has the same semantics as SP. A - recipient MAY replace any linear white space with a single SP before - interpreting the field value or forwarding the message downstream. - This is intended to behave exactly as HTTP/1.1 as described in RFC - 2616 [8]. The SWS construct is used when linear white space is - optional, generally between tokens and separators. - - LWS = [*WSP CRLF] 1*WSP ; linear whitespace - SWS = [LWS] ; sep whitespace - - To separate the header name from the rest of value, a colon is used, - which, by the above rule, allows whitespace before, but no line - break, and whitespace after, including a linebreak. The HCOLON - defines this construct. - - HCOLON = *( SP / HTAB ) ":" SWS - - The TEXT-UTF8 rule is only used for descriptive field contents and - values that are not intended to be interpreted by the message parser. - Words of *TEXT-UTF8 contain characters from the UTF-8 charset (RFC - 2279 [7]). The TEXT-UTF8-TRIM rule is used for descriptive field - contents that are n t quoted strings, where leading and trailing LWS - is not meaningful. In this regard, SIP differs from HTTP, which uses - the ISO 8859-1 character set. - - TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char) - TEXT-UTF8char = %x21-7E / UTF8-NONASCII - UTF8-NONASCII = %xC0-DF 1UTF8-CONT - / %xE0-EF 2UTF8-CONT - / %xF0-F7 3UTF8-CONT - / %xF8-Fb 4UTF8-CONT - / %xFC-FD 5UTF8-CONT - UTF8-CONT = %x80-BF - - - - - - -Rosenberg, et. al. Standards Track [Page 220] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - A CRLF is allowed in the definition of TEXT-UTF8-TRIM only as part of - a header field continuation. It is expected that the folding LWS - will be replaced with a single SP before interpretation of the TEXT- - UTF8-TRIM value. - - Hexadecimal numeric characters are used in several protocol elements. - Some elements (authentication) force hex alphas to be lower case. - - LHEX = DIGIT / %x61-66 ;lowercase a-f - - Many SIP header field values consist of words separated by LWS or - special characters. Unless otherwise stated, tokens are case- - insensitive. These special characters MUST be in a quoted string to - be used within a parameter value. The word construct is used in - Call-ID to allow most separators to be used. - - token = 1*(alphanum / "-" / "." / "!" / "%" / "*" - / "_" / "+" / "`" / "'" / "~" ) - separators = "(" / ")" / "<" / ">" / "@" / - "," / ";" / ":" / "\" / DQUOTE / - "/" / "[" / "]" / "?" / "=" / - "{" / "}" / SP / HTAB - word = 1*(alphanum / "-" / "." / "!" / "%" / "*" / - "_" / "+" / "`" / "'" / "~" / - "(" / ")" / "<" / ">" / - ":" / "\" / DQUOTE / - "/" / "[" / "]" / "?" / - "{" / "}" ) - - When tokens are used or separators are used between elements, - whitespace is often allowed before or after these characters: - - STAR = SWS "*" SWS ; asterisk - SLASH = SWS "/" SWS ; slash - EQUAL = SWS "=" SWS ; equal - LPAREN = SWS "(" SWS ; left parenthesis - RPAREN = SWS ")" SWS ; right parenthesis - RAQUOT = ">" SWS ; right angle quote - LAQUOT = SWS "<"; left angle quote - COMMA = SWS "," SWS ; comma - SEMI = SWS ";" SWS ; semicolon - COLON = SWS ":" SWS ; colon - LDQUOT = SWS DQUOTE; open double quotation mark - RDQUOT = DQUOTE SWS ; close double quotation mark - - - - - - - -Rosenberg, et. al. Standards Track [Page 221] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Comments can be included in some SIP header fields by surrounding the - comment text with parentheses. Comments are only allowed in fields - containing "comment" as part of their field value definition. In all - other fields, parentheses are considered part of the field value. - - comment = LPAREN *(ctext / quoted-pair / comment) RPAREN - ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII - / LWS - - ctext includes all chars except left and right parens and backslash. - A string of text is parsed as a single word if it is quoted using - double-quote marks. In quoted strings, quotation marks (") and - backslashes (\) need to be escaped. - - quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE - qdtext = LWS / %x21 / %x23-5B / %x5D-7E - / UTF8-NONASCII - - The backslash character ("\") MAY be used as a single-character - quoting mechanism only within quoted-string and comment constructs. - Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this - mechanism to avoid conflict with line folding and header separation. - -quoted-pair = "\" (%x00-09 / %x0B-0C - / %x0E-7F) - -SIP-URI = "sip:" [ userinfo ] hostport - uri-parameters [ headers ] -SIPS-URI = "sips:" [ userinfo ] hostport - uri-parameters [ headers ] -userinfo = ( user / telephone-subscriber ) [ ":" password ] "@" -user = 1*( unreserved / escaped / user-unreserved ) -user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" -password = *( unreserved / escaped / - "&" / "=" / "+" / "$" / "," ) -hostport = host [ ":" port ] -host = hostname / IPv4address / IPv6reference -hostname = *( domainlabel "." ) toplabel [ "." ] -domainlabel = alphanum - / alphanum *( alphanum / "-" ) alphanum -toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 222] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT -IPv6reference = "[" IPv6address "]" -IPv6address = hexpart [ ":" IPv4address ] -hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] -hexseq = hex4 *( ":" hex4) -hex4 = 1*4HEXDIG -port = 1*DIGIT - - The BNF for telephone-subscriber can be found in RFC 2806 [9]. Note, - however, that any characters allowed there that are not allowed in - the user part of the SIP URI MUST be escaped. - -uri-parameters = *( ";" uri-parameter) -uri-parameter = transport-param / user-param / method-param - / ttl-param / maddr-param / lr-param / other-param -transport-param = "transport=" - ( "udp" / "tcp" / "sctp" / "tls" - / other-transport) -other-transport = token -user-param = "user=" ( "phone" / "ip" / other-user) -other-user = token -method-param = "method=" Method -ttl-param = "ttl=" ttl -maddr-param = "maddr=" host -lr-param = "lr" -other-param = pname [ "=" pvalue ] -pname = 1*paramchar -pvalue = 1*paramchar -paramchar = param-unreserved / unreserved / escaped -param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" - -headers = "?" header *( "&" header ) -header = hname "=" hvalue -hname = 1*( hnv-unreserved / unreserved / escaped ) -hvalue = *( hnv-unreserved / unreserved / escaped ) -hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$" - -SIP-message = Request / Response -Request = Request-Line - *( message-header ) - CRLF - [ message-body ] -Request-Line = Method SP Request-URI SP SIP-Version CRLF -Request-URI = SIP-URI / SIPS-URI / absoluteURI -absoluteURI = scheme ":" ( hier-part / opaque-part ) -hier-part = ( net-path / abs-path ) [ "?" query ] -net-path = "//" authority [ abs-path ] -abs-path = "/" path-segments - - - -Rosenberg, et. al. Standards Track [Page 223] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -opaque-part = uric-no-slash *uric -uric = reserved / unreserved / escaped -uric-no-slash = unreserved / escaped / ";" / "?" / ":" / "@" - / "&" / "=" / "+" / "$" / "," -path-segments = segment *( "/" segment ) -segment = *pchar *( ";" param ) -param = *pchar -pchar = unreserved / escaped / - ":" / "@" / "&" / "=" / "+" / "$" / "," -scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) -authority = srvr / reg-name -srvr = [ [ userinfo "@" ] hostport ] -reg-name = 1*( unreserved / escaped / "$" / "," - / ";" / ":" / "@" / "&" / "=" / "+" ) -query = *uric -SIP-Version = "SIP" "/" 1*DIGIT "." 1*DIGIT - -message-header = (Accept - / Accept-Encoding - / Accept-Language - / Alert-Info - / Allow - / Authentication-Info - / Authorization - / Call-ID - / Call-Info - / Contact - / Content-Disposition - / Content-Encoding - / Content-Language - / Content-Length - / Content-Type - / CSeq - / Date - / Error-Info - / Expires - / From - / In-Reply-To - / Max-Forwards - / MIME-Version - / Min-Expires - / Organization - / Priority - / Proxy-Authenticate - / Proxy-Authorization - / Proxy-Require - / Record-Route - / Reply-To - - - -Rosenberg, et. al. Standards Track [Page 224] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - / Require - / Retry-After - / Route - / Server - / Subject - / Supported - / Timestamp - / To - / Unsupported - / User-Agent - / Via - / Warning - / WWW-Authenticate - / extension-header) CRLF - -INVITEm = %x49.4E.56.49.54.45 ; INVITE in caps -ACKm = %x41.43.4B ; ACK in caps -OPTIONSm = %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps -BYEm = %x42.59.45 ; BYE in caps -CANCELm = %x43.41.4E.43.45.4C ; CANCEL in caps -REGISTERm = %x52.45.47.49.53.54.45.52 ; REGISTER in caps -Method = INVITEm / ACKm / OPTIONSm / BYEm - / CANCELm / REGISTERm - / extension-method -extension-method = token -Response = Status-Line - *( message-header ) - CRLF - [ message-body ] - -Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF -Status-Code = Informational - / Redirection - / Success - / Client-Error - / Server-Error - / Global-Failure - / extension-code -extension-code = 3DIGIT -Reason-Phrase = *(reserved / unreserved / escaped - / UTF8-NONASCII / UTF8-CONT / SP / HTAB) - -Informational = "100" ; Trying - / "180" ; Ringing - / "181" ; Call Is Being Forwarded - / "182" ; Queued - / "183" ; Session Progress - - - - -Rosenberg, et. al. Standards Track [Page 225] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -Success = "200" ; OK - -Redirection = "300" ; Multiple Choices - / "301" ; Moved Permanently - / "302" ; Moved Temporarily - / "305" ; Use Proxy - / "380" ; Alternative Service - -Client-Error = "400" ; Bad Request - / "401" ; Unauthorized - / "402" ; Payment Required - / "403" ; Forbidden - / "404" ; Not Found - / "405" ; Method Not Allowed - / "406" ; Not Acceptable - / "407" ; Proxy Authentication Required - / "408" ; Request Timeout - / "410" ; Gone - / "413" ; Request Entity Too Large - / "414" ; Request-URI Too Large - / "415" ; Unsupported Media Type - / "416" ; Unsupported URI Scheme - / "420" ; Bad Extension - / "421" ; Extension Required - / "423" ; Interval Too Brief - / "480" ; Temporarily not available - / "481" ; Call Leg/Transaction Does Not Exist - / "482" ; Loop Detected - / "483" ; Too Many Hops - / "484" ; Address Incomplete - / "485" ; Ambiguous - / "486" ; Busy Here - / "487" ; Request Terminated - / "488" ; Not Acceptable Here - / "491" ; Request Pending - / "493" ; Undecipherable - -Server-Error = "500" ; Internal Server Error - / "501" ; Not Implemented - / "502" ; Bad Gateway - / "503" ; Service Unavailable - / "504" ; Server Time-out - / "505" ; SIP Version not supported - / "513" ; Message Too Large - - - - - - - -Rosenberg, et. al. Standards Track [Page 226] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -Global-Failure = "600" ; Busy Everywhere - / "603" ; Decline - / "604" ; Does not exist anywhere - / "606" ; Not Acceptable - -Accept = "Accept" HCOLON - [ accept-range *(COMMA accept-range) ] -accept-range = media-range *(SEMI accept-param) -media-range = ( "*/*" - / ( m-type SLASH "*" ) - / ( m-type SLASH m-subtype ) - ) *( SEMI m-parameter ) -accept-param = ("q" EQUAL qvalue) / generic-param -qvalue = ( "0" [ "." 0*3DIGIT ] ) - / ( "1" [ "." 0*3("0") ] ) -generic-param = token [ EQUAL gen-value ] -gen-value = token / host / quoted-string - -Accept-Encoding = "Accept-Encoding" HCOLON - [ encoding *(COMMA encoding) ] -encoding = codings *(SEMI accept-param) -codings = content-coding / "*" -content-coding = token - -Accept-Language = "Accept-Language" HCOLON - [ language *(COMMA language) ] -language = language-range *(SEMI accept-param) -language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) - -Alert-Info = "Alert-Info" HCOLON alert-param *(COMMA alert-param) -alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) - -Allow = "Allow" HCOLON [Method *(COMMA Method)] - -Authorization = "Authorization" HCOLON credentials -credentials = ("Digest" LWS digest-response) - / other-response -digest-response = dig-resp *(COMMA dig-resp) -dig-resp = username / realm / nonce / digest-uri - / dresponse / algorithm / cnonce - / opaque / message-qop - / nonce-count / auth-param -username = "username" EQUAL username-value -username-value = quoted-string -digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT -digest-uri-value = rquest-uri ; Equal to request-uri as specified - by HTTP/1.1 -message-qop = "qop" EQUAL qop-value - - - -Rosenberg, et. al. Standards Track [Page 227] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -cnonce = "cnonce" EQUAL cnonce-value -cnonce-value = nonce-value -nonce-count = "nc" EQUAL nc-value -nc-value = 8LHEX -dresponse = "response" EQUAL request-digest -request-digest = LDQUOT 32LHEX RDQUOT -auth-param = auth-param-name EQUAL - ( token / quoted-string ) -auth-param-name = token -other-response = auth-scheme LWS auth-param - *(COMMA auth-param) -auth-scheme = token - -Authentication-Info = "Authentication-Info" HCOLON ainfo - *(COMMA ainfo) -ainfo = nextnonce / message-qop - / response-auth / cnonce - / nonce-count -nextnonce = "nextnonce" EQUAL nonce-value -response-auth = "rspauth" EQUAL response-digest -response-digest = LDQUOT *LHEX RDQUOT - -Call-ID = ( "Call-ID" / "i" ) HCOLON callid -callid = word [ "@" word ] - -Call-Info = "Call-Info" HCOLON info *(COMMA info) -info = LAQUOT absoluteURI RAQUOT *( SEMI info-param) -info-param = ( "purpose" EQUAL ( "icon" / "info" - / "card" / token ) ) / generic-param - -Contact = ("Contact" / "m" ) HCOLON - ( STAR / (contact-param *(COMMA contact-param))) -contact-param = (name-addr / addr-spec) *(SEMI contact-params) -name-addr = [ display-name ] LAQUOT addr-spec RAQUOT -addr-spec = SIP-URI / SIPS-URI / absoluteURI -display-name = *(token LWS)/ quoted-string - -contact-params = c-p-q / c-p-expires - / contact-extension -c-p-q = "q" EQUAL qvalue -c-p-expires = "expires" EQUAL delta-seconds -contact-extension = generic-param -delta-seconds = 1*DIGIT - -Content-Disposition = "Content-Disposition" HCOLON - disp-type *( SEMI disp-param ) -disp-type = "render" / "session" / "icon" / "alert" - / disp-extension-token - - - -Rosenberg, et. al. Standards Track [Page 228] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -disp-param = handling-param / generic-param -handling-param = "handling" EQUAL - ( "optional" / "required" - / other-handling ) -other-handling = token -disp-extension-token = token - -Content-Encoding = ( "Content-Encoding" / "e" ) HCOLON - content-coding *(COMMA content-coding) - -Content-Language = "Content-Language" HCOLON - language-tag *(COMMA language-tag) -language-tag = primary-tag *( "-" subtag ) -primary-tag = 1*8ALPHA -subtag = 1*8ALPHA - -Content-Length = ( "Content-Length" / "l" ) HCOLON 1*DIGIT -Content-Type = ( "Content-Type" / "c" ) HCOLON media-type -media-type = m-type SLASH m-subtype *(SEMI m-parameter) -m-type = discrete-type / composite-type -discrete-type = "text" / "image" / "audio" / "video" - / "application" / extension-token -composite-type = "message" / "multipart" / extension-token -extension-token = ietf-token / x-token -ietf-token = token -x-token = "x-" token -m-subtype = extension-token / iana-token -iana-token = token -m-parameter = m-attribute EQUAL m-value -m-attribute = token -m-value = token / quoted-string - -CSeq = "CSeq" HCOLON 1*DIGIT LWS Method - -Date = "Date" HCOLON SIP-date -SIP-date = rfc1123-date -rfc1123-date = wkday "," SP date1 SP time SP "GMT" -date1 = 2DIGIT SP month SP 4DIGIT - ; day month year (e.g., 02 Jun 1982) -time = 2DIGIT ":" 2DIGIT ":" 2DIGIT - ; 00:00:00 - 23:59:59 -wkday = "Mon" / "Tue" / "Wed" - / "Thu" / "Fri" / "Sat" / "Sun" -month = "Jan" / "Feb" / "Mar" / "Apr" - / "May" / "Jun" / "Jul" / "Aug" - / "Sep" / "Oct" / "Nov" / "Dec" - -Error-Info = "Error-Info" HCOLON error-uri *(COMMA error-uri) - - - -Rosenberg, et. al. Standards Track [Page 229] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) - -Expires = "Expires" HCOLON delta-seconds -From = ( "From" / "f" ) HCOLON from-spec -from-spec = ( name-addr / addr-spec ) - *( SEMI from-param ) -from-param = tag-param / generic-param -tag-param = "tag" EQUAL token - -In-Reply-To = "In-Reply-To" HCOLON callid *(COMMA callid) - -Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT - -MIME-Version = "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT - -Min-Expires = "Min-Expires" HCOLON delta-seconds - -Organization = "Organization" HCOLON [TEXT-UTF8-TRIM] - -Priority = "Priority" HCOLON priority-value -priority-value = "emergency" / "urgent" / "normal" - / "non-urgent" / other-priority -other-priority = token - -Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge -challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) - / other-challenge -other-challenge = auth-scheme LWS auth-param - *(COMMA auth-param) -digest-cln = realm / domain / nonce - / opaque / stale / algorithm - / qop-options / auth-param -realm = "realm" EQUAL realm-value -realm-value = quoted-string -domain = "domain" EQUAL LDQUOT URI - *( 1*SP URI ) RDQUOT -URI = absoluteURI / abs-path -nonce = "nonce" EQUAL nonce-value -nonce-value = quoted-string -opaque = "opaque" EQUAL quoted-string -stale = "stale" EQUAL ( "true" / "false" ) -algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" - / token ) -qop-options = "qop" EQUAL LDQUOT qop-value - *("," qop-value) RDQUOT -qop-value = "auth" / "auth-int" / token - -Proxy-Authorization = "Proxy-Authorization" HCOLON credentials - - - -Rosenberg, et. al. Standards Track [Page 230] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -Proxy-Require = "Proxy-Require" HCOLON option-tag - *(COMMA option-tag) -option-tag = token - -Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route) -rec-route = name-addr *( SEMI rr-param ) -rr-param = generic-param - -Reply-To = "Reply-To" HCOLON rplyto-spec -rplyto-spec = ( name-addr / addr-spec ) - *( SEMI rplyto-param ) -rplyto-param = generic-param -Require = "Require" HCOLON option-tag *(COMMA option-tag) - -Retry-After = "Retry-After" HCOLON delta-seconds - [ comment ] *( SEMI retry-param ) - -retry-param = ("duration" EQUAL delta-seconds) - / generic-param - -Route = "Route" HCOLON route-param *(COMMA route-param) -route-param = name-addr *( SEMI rr-param ) - -Server = "Server" HCOLON server-val *(LWS server-val) -server-val = product / comment -product = token [SLASH product-version] -product-version = token - -Subject = ( "Subject" / "s" ) HCOLON [TEXT-UTF8-TRIM] - -Supported = ( "Supported" / "k" ) HCOLON - [option-tag *(COMMA option-tag)] - -Timestamp = "Timestamp" HCOLON 1*(DIGIT) - [ "." *(DIGIT) ] [ LWS delay ] -delay = *(DIGIT) [ "." *(DIGIT) ] - -To = ( "To" / "t" ) HCOLON ( name-addr - / addr-spec ) *( SEMI to-param ) -to-param = tag-param / generic-param - -Unsupported = "Unsupported" HCOLON option-tag *(COMMA option-tag) -User-Agent = "User-Agent" HCOLON server-val *(LWS server-val) - - - - - - - - -Rosenberg, et. al. Standards Track [Page 231] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm) -via-parm = sent-protocol LWS sent-by *( SEMI via-params ) -via-params = via-ttl / via-maddr - / via-received / via-branch - / via-extension -via-ttl = "ttl" EQUAL ttl -via-maddr = "maddr" EQUAL host -via-received = "received" EQUAL (IPv4address / IPv6address) -via-branch = "branch" EQUAL token -via-extension = generic-param -sent-protocol = protocol-name SLASH protocol-version - SLASH transport -protocol-name = "SIP" / token -protocol-version = token -transport = "UDP" / "TCP" / "TLS" / "SCTP" - / other-transport -sent-by = host [ COLON port ] -ttl = 1*3DIGIT ; 0 to 255 - -Warning = "Warning" HCOLON warning-value *(COMMA warning-value) -warning-value = warn-code SP warn-agent SP warn-text -warn-code = 3DIGIT -warn-agent = hostport / pseudonym - ; the name or pseudonym of the server adding - ; the Warning header, for use in debugging -warn-text = quoted-string -pseudonym = token - -WWW-Authenticate = "WWW-Authenticate" HCOLON challenge - -extension-header = header-name HCOLON header-value -header-name = token -header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) -message-body = *OCTET - -26 Security Considerations: Threat Model and Security Usage - Recommendations - - SIP is not an easy protocol to secure. Its use of intermediaries, - its multi-faceted trust relationships, its expected usage between - elements with no trust at all, and its user-to-user operation make - security far from trivial. Security solutions are needed that are - deployable today, without extensive coordination, in a wide variety - of environments and usages. In order to meet these diverse needs, - several distinct mechanisms applicable to different aspects and - usages of SIP will be required. - - - - - -Rosenberg, et. al. Standards Track [Page 232] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Note that the security of SIP signaling itself has no bearing on the - security of protocols used in concert with SIP such as RTP, or with - the security implications of any specific bodies SIP might carry - (although MIME security plays a substantial role in securing SIP). - Any media associated with a session can be encrypted end-to-end - independently of any associated SIP signaling. Media encryption is - outside the scope of this document. - - The considerations that follow first examine a set of classic threat - models that broadly identify the security needs of SIP. The set of - security services required to address these threats is then detailed, - followed by an explanation of several security mechanisms that can be - used to provide these services. Next, the requirements for - implementers of SIP are enumerated, along with exemplary deployments - in which these security mechanisms could be used to improve the - security of SIP. Some notes on privacy conclude this section. - -26.1 Attacks and Threat Models - - This section details some threats that should be common to most - deployments of SIP. These threats have been chosen specifically to - illustrate each of the security services that SIP requires. - - The following examples by no means provide an exhaustive list of the - threats against SIP; rather, these are "classic" threats that - demonstrate the need for particular security services that can - potentially prevent whole categories of threats. - - These attacks assume an environment in which attackers can - potentially read any packet on the network - it is anticipated that - SIP will frequently be used on the public Internet. Attackers on the - network may be able to modify packets (perhaps at some compromised - intermediary). Attackers may wish to steal services, eavesdrop on - communications, or disrupt sessions. - -26.1.1 Registration Hijacking - - The SIP registration mechanism allows a user agent to identify itself - to a registrar as a device at which a user (designated by an address - of record) is located. A registrar assesses the identity asserted in - the From header field of a REGISTER message to determine whether this - request can modify the contact addresses associated with the - address-of-record in the To header field. While these two fields are - frequently the same, there are many valid deployments in which a - third-party may register contacts on a user's behalf. - - - - - - -Rosenberg, et. al. Standards Track [Page 233] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The From header field of a SIP request, however, can be modified - arbitrarily by the owner of a UA, and this opens the door to - malicious registrations. An attacker that successfully impersonates - a party authorized to change contacts associated with an address-of- - record could, for example, de-register all existing contacts for a - URI and then register their own device as the appropriate contact - address, thereby directing all requests for the affected user to the - attacker's device. - - This threat belongs to a family of threats that rely on the absence - of cryptographic assurance of a request's originator. Any SIP UAS - that represents a valuable service (a gateway that interworks SIP - requests with traditional telephone calls, for example) might want to - control access to its resources by authenticating requests that it - receives. Even end-user UAs, for example SIP phones, have an - interest in ascertaining the identities of originators of requests. - - This threat demonstrates the need for security services that enable - SIP entities to authenticate the originators of requests. - -26.1.2 Impersonating a Server - - The domain to which a request is destined is generally specified in - the Request-URI. UAs commonly contact a server in this domain - directly in order to deliver a request. However, there is always a - possibility that an attacker could impersonate the remote server, and - that the UA's request could be intercepted by some other party. - - For example, consider a case in which a redirect server at one - domain, chicago.com, impersonates a redirect server at another - domain, biloxi.com. A user agent sends a request to biloxi.com, but - the redirect server at chicago.com answers with a forged response - that has appropriate SIP header fields for a response from - biloxi.com. The forged contact addresses in the redirection response - could direct the originating UA to inappropriate or insecure - resources, or simply prevent requests for biloxi.com from succeeding. - - This family of threats has a vast membership, many of which are - critical. As a converse to the registration hijacking threat, - consider the case in which a registration sent to biloxi.com is - intercepted by chicago.com, which replies to the intercepted - registration with a forged 301 (Moved Permanently) response. This - response might seem to come from biloxi.com yet designate chicago.com - as the appropriate registrar. All future REGISTER requests from the - originating UA would then go to chicago.com. - - Prevention of this threat requires a means by which UAs can - authenticate the servers to whom they send requests. - - - -Rosenberg, et. al. Standards Track [Page 234] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -26.1.3 Tampering with Message Bodies - - As a matter of course, SIP UAs route requests through trusted proxy - servers. Regardless of how that trust is established (authentication - of proxies is discussed elsewhere in this section), a UA may trust a - proxy server to route a request, but not to inspect or possibly - modify the bodies contained in that request. - - Consider a UA that is using SIP message bodies to communicate session - encryption keys for a media session. Although it trusts the proxy - server of the domain it is contacting to deliver signaling properly, - it may not want the administrators of that domain to be capable of - decrypting any subsequent media session. Worse yet, if the proxy - server were actively malicious, it could modify the session key, - either acting as a man-in-the-middle, or perhaps changing the - security characteristics requested by the originating UA. - - This family of threats applies not only to session keys, but to most - conceivable forms of content carried end-to-end in SIP. These might - include MIME bodies that should be rendered to the user, SDP, or - encapsulated telephony signals, among others. Attackers might - attempt to modify SDP bodies, for example, in order to point RTP - media streams to a wiretapping device in order to eavesdrop on - subsequent voice communications. - - Also note that some header fields in SIP are meaningful end-to-end, - for example, Subject. UAs might be protective of these header fields - as well as bodies (a malicious intermediary changing the Subject - header field might make an important request appear to be spam, for - example). However, since many header fields are legitimately - inspected or altered by proxy servers as a request is routed, not all - header fields should be secured end-to-end. - - For these reasons, the UA might want to secure SIP message bodies, - and in some limited cases header fields, end-to-end. The security - services required for bodies include confidentiality, integrity, and - authentication. These end-to-end services should be independent of - the means used to secure interactions with intermediaries such as - proxy servers. - -26.1.4 Tearing Down Sessions - - Once a dialog has been established by initial messaging, subsequent - requests can be sent that modify the state of the dialog and/or - session. It is critical that principals in a session can be certain - that such requests are not forged by attackers. - - - - - -Rosenberg, et. al. Standards Track [Page 235] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Consider a case in which a third-party attacker captures some initial - messages in a dialog shared by two parties in order to learn the - parameters of the session (To tag, From tag, and so forth) and then - inserts a BYE request into the session. The attacker could opt to - forge the request such that it seemed to come from either - participant. Once the BYE is received by its target, the session - will be torn down prematurely. - - Similar mid-session threats include the transmission of forged re- - INVITEs that alter the session (possibly to reduce session security - or redirect media streams as part of a wiretapping attack). - - The most effective countermeasure to this threat is the - authentication of the sender of the BYE. In this instance, the - recipient needs only know that the BYE came from the same party with - whom the corresponding dialog was established (as opposed to - ascertaining the absolute identity of the sender). Also, if the - attacker is unable to learn the parameters of the session due to - confidentiality, it would not be possible to forge the BYE. However, - some intermediaries (like proxy servers) will need to inspect those - parameters as the session is established. - -26.1.5 Denial of Service and Amplification - - Denial-of-service attacks focus on rendering a particular network - element unavailable, usually by directing an excessive amount of - network traffic at its interfaces. A distributed denial-of-service - attack allows one network user to cause multiple network hosts to - flood a target host with a large amount of network traffic. - - In many architectures, SIP proxy servers face the public Internet in - order to accept requests from worldwide IP endpoints. SIP creates a - number of potential opportunities for distributed denial-of-service - attacks that must be recognized and addressed by the implementers and - operators of SIP systems. - - Attackers can create bogus requests that contain a falsified source - IP address and a corresponding Via header field that identify a - targeted host as the originator of the request and then send this - request to a large number of SIP network elements, thereby using - hapless SIP UAs or proxies to generate denial-of-service traffic - aimed at the target. - - Similarly, attackers might use falsified Route header field values in - a request that identify the target host and then send such messages - to forking proxies that will amplify messaging sent to the target. - - - - - -Rosenberg, et. al. Standards Track [Page 236] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Record-Route could be used to similar effect when the attacker is - certain that the SIP dialog initiated by the request will result in - numerous transactions originating in the backwards direction. - - A number of denial-of-service attacks open up if REGISTER requests - are not properly authenticated and authorized by registrars. - Attackers could de-register some or all users in an administrative - domain, thereby preventing these users from being invited to new - sessions. An attacker could also register a large number of contacts - designating the same host for a given address-of-record in order to - use the registrar and any associated proxy servers as amplifiers in a - denial-of-service attack. Attackers might also attempt to deplete - available memory and disk resources of a registrar by registering - huge numbers of bindings. - - The use of multicast to transmit SIP requests can greatly increase - the potential for denial-of-service attacks. - - These problems demonstrate a general need to define architectures - that minimize the risks of denial-of-service, and the need to be - mindful in recommendations for security mechanisms of this class of - attacks. - -26.2 Security Mechanisms - - From the threats described above, we gather that the fundamental - security services required for the SIP protocol are: preserving the - confidentiality and integrity of messaging, preventing replay attacks - or message spoofing, providing for the authentication and privacy of - the participants in a session, and preventing denial-of-service - attacks. Bodies within SIP messages separately require the security - services of confidentiality, integrity, and authentication. - - Rather than defining new security mechanisms specific to SIP, SIP - reuses wherever possible existing security models derived from the - HTTP and SMTP space. - - Full encryption of messages provides the best means to preserve the - confidentiality of signaling - it can also guarantee that messages - are not modified by any malicious intermediaries. However, SIP - requests and responses cannot be naively encrypted end-to-end in - their entirety because message fields such as the Request-URI, Route, - and Via need to be visible to proxies in most network architectures - so that SIP requests are routed correctly. Note that proxy servers - need to modify some features of messages as well (such as adding Via - header field values) in order for SIP to function. Proxy servers - must therefore be trusted, to some degree, by SIP UAs. To this - purpose, low-layer security mechanisms for SIP are recommended, which - - - -Rosenberg, et. al. Standards Track [Page 237] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - encrypt the entire SIP requests or responses on the wire on a hop- - by-hop basis, and that allow endpoints to verify the identity of - proxy servers to whom they send requests. - - SIP entities also have a need to identify one another in a secure - fashion. When a SIP endpoint asserts the identity of its user to a - peer UA or to a proxy server, that identity should in some way be - verifiable. A cryptographic authentication mechanism is provided in - SIP to address this requirement. - - An independent security mechanism for SIP message bodies supplies an - alternative means of end-to-end mutual authentication, as well as - providing a limit on the degree to which user agents must trust - intermediaries. - -26.2.1 Transport and Network Layer Security - - Transport or network layer security encrypts signaling traffic, - guaranteeing message confidentiality and integrity. - - Oftentimes, certificates are used in the establishment of lower-layer - security, and these certificates can also be used to provide a means - of authentication in many architectures. - - Two popular alternatives for providing security at the transport and - network layer are, respectively, TLS [25] and IPSec [26]. - - IPSec is a set of network-layer protocol tools that collectively can - be used as a secure replacement for traditional IP (Internet - Protocol). IPSec is most commonly used in architectures in which a - set of hosts or administrative domains have an existing trust - relationship with one another. IPSec is usually implemented at the - operating system level in a host, or on a security gateway that - provides confidentiality and integrity for all traffic it receives - from a particular interface (as in a VPN architecture). IPSec can - also be used on a hop-by-hop basis. - - In many architectures IPSec does not require integration with SIP - applications; IPSec is perhaps best suited to deployments in which - adding security directly to SIP hosts would be arduous. UAs that - have a pre-shared keying relationship with their first-hop proxy - server are also good candidates to use IPSec. Any deployment of - IPSec for SIP would require an IPSec profile describing the protocol - tools that would be required to secure SIP. No such profile is given - in this document. - - - - - - -Rosenberg, et. al. Standards Track [Page 238] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - TLS provides transport-layer security over connection-oriented - protocols (for the purposes of this document, TCP); "tls" (signifying - TLS over TCP) can be specified as the desired transport protocol - within a Via header field value or a SIP-URI. TLS is most suited to - architectures in which hop-by-hop security is required between hosts - with no pre-existing trust association. For example, Alice trusts - her local proxy server, which after a certificate exchange decides to - trust Bob's local proxy server, which Bob trusts, hence Bob and Alice - can communicate securely. - - TLS must be tightly coupled with a SIP application. Note that - transport mechanisms are specified on a hop-by-hop basis in SIP, thus - a UA that sends requests over TLS to a proxy server has no assurance - that TLS will be used end-to-end. - - The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at - a minimum by implementers when TLS is used in a SIP application. For - purposes of backwards compatibility, proxy servers, redirect servers, - and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. - Implementers MAY also support any other ciphersuite. - -26.2.2 SIPS URI Scheme - - The SIPS URI scheme adheres to the syntax of the SIP URI (described - in 19), although the scheme string is "sips" rather than "sip". The - semantics of SIPS are very different from the SIP URI, however. SIPS - allows resources to specify that they should be reached securely. - - A SIPS URI can be used as an address-of-record for a particular user - - the URI by which the user is canonically known (on their business - cards, in the From header field of their requests, in the To header - field of REGISTER requests). When used as the Request-URI of a - request, the SIPS scheme signifies that each hop over which the - request is forwarded, until the request reaches the SIP entity - responsible for the domain portion of the Request-URI, must be - secured with TLS; once it reaches the domain in question it is - handled in accordance with local security and routing policy, quite - possibly using TLS for any last hop to a UAS. When used by the - originator of a request (as would be the case if they employed a SIPS - URI as the address-of-record of the target), SIPS dictates that the - entire request path to the target domain be so secured. - - The SIPS scheme is applicable to many of the other ways in which SIP - URIs are used in SIP today in addition to the Request-URI, including - in addresses-of-record, contact addresses (the contents of Contact - headers, including those of REGISTER methods), and Route headers. In - each instance, the SIPS URI scheme allows these existing fields to - - - - -Rosenberg, et. al. Standards Track [Page 239] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - designate secure resources. The manner in which a SIPS URI is - dereferenced in any of these contexts has its own security properties - which are detailed in [4]. - - The use of SIPS in particular entails that mutual TLS authentication - SHOULD be employed, as SHOULD the ciphersuite - TLS_RSA_WITH_AES_128_CBC_SHA. Certificates received in the - authentication process SHOULD be validated with root certificates - held by the client; failure to validate a certificate SHOULD result - in the failure of the request. - - Note that in the SIPS URI scheme, transport is independent of TLS, - and thus "sips:alice@atlanta.com;transport=tcp" and - "sips:alice@atlanta.com;transport=sctp" are both valid (although - note that UDP is not a valid transport for SIPS). The use of - "transport=tls" has consequently been deprecated, partly because - it was specific to a single hop of the request. This is a change - since RFC 2543. - - Users that distribute a SIPS URI as an address-of-record may elect to - operate devices that refuse requests over insecure transports. - -26.2.3 HTTP Authentication - - SIP provides a challenge capability, based on HTTP authentication, - that relies on the 401 and 407 response codes as well as header - fields for carrying challenges and credentials. Without significant - modification, the reuse of the HTTP Digest authentication scheme in - SIP allows for replay protection and one-way authentication. - - The usage of Digest authentication in SIP is detailed in Section 22. - -26.2.4 S/MIME - - As is discussed above, encrypting entire SIP messages end-to-end for - the purpose of confidentiality is not appropriate because network - intermediaries (like proxy servers) need to view certain header - fields in order to route messages correctly, and if these - intermediaries are excluded from security associations, then SIP - messages will essentially be non-routable. - - However, S/MIME allows SIP UAs to encrypt MIME bodies within SIP, - securing these bodies end-to-end without affecting message headers. - S/MIME can provide end-to-end confidentiality and integrity for - message bodies, as well as mutual authentication. It is also - possible to use S/MIME to provide a form of integrity and - confidentiality for SIP header fields through SIP message tunneling. - - - - -Rosenberg, et. al. Standards Track [Page 240] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The usage of S/MIME in SIP is detailed in Section 23. - -26.3 Implementing Security Mechanisms - -26.3.1 Requirements for Implementers of SIP - - Proxy servers, redirect servers, and registrars MUST implement TLS, - and MUST support both mutual and one-way authentication. It is - strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also - be capable of acting as a TLS server. Proxy servers, redirect - servers, and registrars SHOULD possess a site certificate whose - subject corresponds to their canonical hostname. UAs MAY have - certificates of their own for mutual authentication with TLS, but no - provisions are set forth in this document for their use. All SIP - elements that support TLS MUST have a mechanism for validating - certificates received during TLS negotiation; this entails possession - of one or more root certificates issued by certificate authorities - (preferably well-known distributors of site certificates comparable - to those that issue root certificates for web browsers). - - All SIP elements that support TLS MUST also support the SIPS URI - scheme. - - Proxy servers, redirect servers, registrars, and UAs MAY also - implement IPSec or other lower-layer security protocols. - - When a UA attempts to contact a proxy server, redirect server, or - registrar, the UAC SHOULD initiate a TLS connection over which it - will send SIP messages. In some architectures, UASs MAY receive - requests over such TLS connections as well. - - Proxy servers, redirect servers, registrars, and UAs MUST implement - Digest Authorization, encompassing all of the aspects required in 22. - Proxy servers, redirect servers, and registrars SHOULD be configured - with at least one Digest realm, and at least one "realm" string - supported by a given server SHOULD correspond to the server's - hostname or domainname. - - UAs MAY support the signing and encrypting of MIME bodies, and - transference of credentials with S/MIME as described in Section 23. - If a UA holds one or more root certificates of certificate - authorities in order to validate certificates for TLS or IPSec, it - SHOULD be capable of reusing these to verify S/MIME certificates, as - appropriate. A UA MAY hold root certificates specifically for - validating S/MIME certificates. - - - - - - -Rosenberg, et. al. Standards Track [Page 241] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Note that is it anticipated that future security extensions may - upgrade the normative strength associated with S/MIME as S/MIME - implementations appear and the problem space becomes better - understood. - -26.3.2 Security Solutions - - The operation of these security mechanisms in concert can follow the - existing web and email security models to some degree. At a high - level, UAs authenticate themselves to servers (proxy servers, - redirect servers, and registrars) with a Digest username and - password; servers authenticate themselves to UAs one hop away, or to - another server one hop away (and vice versa), with a site certificate - delivered by TLS. - - On a peer-to-peer level, UAs trust the network to authenticate one - another ordinarily; however, S/MIME can also be used to provide - direct authentication when the network does not, or if the network - itself is not trusted. - - The following is an illustrative example in which these security - mechanisms are used by various UAs and servers to prevent the sorts - of threats described in Section 26.1. While implementers and network - administrators MAY follow the normative guidelines given in the - remainder of this section, these are provided only as example - implementations. - -26.3.2.1 Registration - - When a UA comes online and registers with its local administrative - domain, it SHOULD establish a TLS connection with its registrar - (Section 10 describes how the UA reaches its registrar). The - registrar SHOULD offer a certificate to the UA, and the site - identified by the certificate MUST correspond with the domain in - which the UA intends to register; for example, if the UA intends to - register the address-of-record 'alice@atlanta.com', the site - certificate must identify a host within the atlanta.com domain (such - as sip.atlanta.com). When it receives the TLS Certificate message, - the UA SHOULD verify the certificate and inspect the site identified - by the certificate. If the certificate is invalid, revoked, or if it - does not identify the appropriate party, the UA MUST NOT send the - REGISTER message and otherwise proceed with the registration. - - When a valid certificate has been provided by the registrar, the - UA knows that the registrar is not an attacker who might redirect - the UA, steal passwords, or attempt any similar attacks. - - - - - -Rosenberg, et. al. Standards Track [Page 242] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The UA then creates a REGISTER request that SHOULD be addressed to a - Request-URI corresponding to the site certificate received from the - registrar. When the UA sends the REGISTER request over the existing - TLS connection, the registrar SHOULD challenge the request with a 401 - (Proxy Authentication Required) response. The "realm" parameter - within the Proxy-Authenticate header field of the response SHOULD - correspond to the domain previously given by the site certificate. - When the UAC receives the challenge, it SHOULD either prompt the user - for credentials or take an appropriate credential from a keyring - corresponding to the "realm" parameter in the challenge. The - username of this credential SHOULD correspond with the "userinfo" - portion of the URI in the To header field of the REGISTER request. - Once the Digest credentials have been inserted into an appropriate - Proxy-Authorization header field, the REGISTER should be resubmitted - to the registrar. - - Since the registrar requires the user agent to authenticate - itself, it would be difficult for an attacker to forge REGISTER - requests for the user's address-of-record. Also note that since - the REGISTER is sent over a confidential TLS connection, attackers - will not be able to intercept the REGISTER to record credentials - for any possible replay attack. - - Once the registration has been accepted by the registrar, the UA - SHOULD leave this TLS connection open provided that the registrar - also acts as the proxy server to which requests are sent for users in - this administrative domain. The existing TLS connection will be - reused to deliver incoming requests to the UA that has just completed - registration. - - Because the UA has already authenticated the server on the other - side of the TLS connection, all requests that come over this - connection are known to have passed through the proxy server - - attackers cannot create spoofed requests that appear to have been - sent through that proxy server. - -26.3.2.2 Interdomain Requests - - Now let's say that Alice's UA would like to initiate a session with a - user in a remote administrative domain, namely "bob@biloxi.com". We - will also say that the local administrative domain (atlanta.com) has - a local outbound proxy. - - The proxy server that handles inbound requests for an administrative - domain MAY also act as a local outbound proxy; for simplicity's sake - we'll assume this to be the case for atlanta.com (otherwise the user - agent would initiate a new TLS connection to a separate server at - this point). Assuming that the client has completed the registration - - - -Rosenberg, et. al. Standards Track [Page 243] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - process described in the preceding section, it SHOULD reuse the TLS - connection to the local proxy server when it sends an INVITE request - to another user. The UA SHOULD reuse cached credentials in the - INVITE to avoid prompting the user unnecessarily. - - When the local outbound proxy server has validated the credentials - presented by the UA in the INVITE, it SHOULD inspect the Request-URI - to determine how the message should be routed (see [4]). If the - "domainname" portion of the Request-URI had corresponded to the local - domain (atlanta.com) rather than biloxi.com, then the proxy server - would have consulted its location service to determine how best to - reach the requested user. - - Had "alice@atlanta.com" been attempting to contact, say, - "alex@atlanta.com", the local proxy would have proxied to the - request to the TLS connection Alex had established with the - registrar when he registered. Since Alex would receive this - request over his authenticated channel, he would be assured that - Alice's request had been authorized by the proxy server of the - local administrative domain. - - However, in this instance the Request-URI designates a remote domain. - The local outbound proxy server at atlanta.com SHOULD therefore - establish a TLS connection with the remote proxy server at - biloxi.com. Since both of the participants in this TLS connection - are servers that possess site certificates, mutual TLS authentication - SHOULD occur. Each side of the connection SHOULD verify and inspect - the certificate of the other, noting the domain name that appears in - the certificate for comparison with the header fields of SIP - messages. The atlanta.com proxy server, for example, SHOULD verify - at this stage that the certificate received from the remote side - corresponds with the biloxi.com domain. Once it has done so, and TLS - negotiation has completed, resulting in a secure channel between the - two proxies, the atlanta.com proxy can forward the INVITE request to - biloxi.com. - - The proxy server at biloxi.com SHOULD inspect the certificate of the - proxy server at atlanta.com in turn and compare the domain asserted - by the certificate with the "domainname" portion of the From header - field in the INVITE request. The biloxi proxy MAY have a strict - security policy that requires it to reject requests that do not match - the administrative domain from which they have been proxied. - - Such security policies could be instituted to prevent the SIP - equivalent of SMTP 'open relays' that are frequently exploited to - generate spam. - - - - - -Rosenberg, et. al. Standards Track [Page 244] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - This policy, however, only guarantees that the request came from the - domain it ascribes to itself; it does not allow biloxi.com to - ascertain how atlanta.com authenticated Alice. Only if biloxi.com - has some other way of knowing atlanta.com's authentication policies - could it possibly ascertain how Alice proved her identity. - biloxi.com might then institute an even stricter policy that forbids - requests that come from domains that are not known administratively - to share a common authentication policy with biloxi.com. - - Once the INVITE has been approved by the biloxi proxy, the proxy - server SHOULD identify the existing TLS channel, if any, associated - with the user targeted by this request (in this case - "bob@biloxi.com"). The INVITE should be proxied through this channel - to Bob. Since the request is received over a TLS connection that had - previously been authenticated as the biloxi proxy, Bob knows that the - From header field was not tampered with and that atlanta.com has - validated Alice, although not necessarily whether or not to trust - Alice's identity. - - Before they forward the request, both proxy servers SHOULD add a - Record-Route header field to the request so that all future requests - in this dialog will pass through the proxy servers. The proxy - servers can thereby continue to provide security services for the - lifetime of this dialog. If the proxy servers do not add themselves - to the Record-Route, future messages will pass directly end-to-end - between Alice and Bob without any security services (unless the two - parties agree on some independent end-to-end security such as - S/MIME). In this respect the SIP trapezoid model can provide a nice - structure where conventions of agreement between the site proxies can - provide a reasonably secure channel between Alice and Bob. - - An attacker preying on this architecture would, for example, be - unable to forge a BYE request and insert it into the signaling - stream between Bob and Alice because the attacker has no way of - ascertaining the parameters of the session and also because the - integrity mechanism transitively protects the traffic between - Alice and Bob. - -26.3.2.3 Peer-to-Peer Requests - - Alternatively, consider a UA asserting the identity - "carol@chicago.com" that has no local outbound proxy. When Carol - wishes to send an INVITE to "bob@biloxi.com", her UA SHOULD initiate - a TLS connection with the biloxi proxy directly (using the mechanism - described in [4] to determine how to best to reach the given - Request-URI). When her UA receives a certificate from the biloxi - proxy, it SHOULD be verified normally before she passes her INVITE - across the TLS connection. However, Carol has no means of proving - - - -Rosenberg, et. al. Standards Track [Page 245] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - her identity to the biloxi proxy, but she does have a CMS-detached - signature over a "message/sip" body in the INVITE. It is unlikely in - this instance that Carol would have any credentials in the biloxi.com - realm, since she has no formal association with biloxi.com. The - biloxi proxy MAY also have a strict policy that precludes it from - even bothering to challenge requests that do not have biloxi.com in - the "domainname" portion of the From header field - it treats these - users as unauthenticated. - - The biloxi proxy has a policy for Bob that all non-authenticated - requests should be redirected to the appropriate contact address - registered against 'bob@biloxi.com', namely . - Carol receives the redirection response over the TLS connection she - established with the biloxi proxy, so she trusts the veracity of the - contact address. - - Carol SHOULD then establish a TCP connection with the designated - address and send a new INVITE with a Request-URI containing the - received contact address (recomputing the signature in the body as - the request is readied). Bob receives this INVITE on an insecure - interface, but his UA inspects and, in this instance, recognizes the - From header field of the request and subsequently matches a locally - cached certificate with the one presented in the signature of the - body of the INVITE. He replies in similar fashion, authenticating - himself to Carol, and a secure dialog begins. - - Sometimes firewalls or NATs in an administrative domain could - preclude the establishment of a direct TCP connection to a UA. In - these cases, proxy servers could also potentially relay requests - to UAs in a way that has no trust implications (for example, - forgoing an existing TLS connection and forwarding the request - over cleartext TCP) as local policy dictates. - -26.3.2.4 DoS Protection - - In order to minimize the risk of a denial-of-service attack against - architectures using these security solutions, implementers should - take note of the following guidelines. - - When the host on which a SIP proxy server is operating is routable - from the public Internet, it SHOULD be deployed in an administrative - domain with defensive operational policies (blocking source-routed - traffic, preferably filtering ping traffic). Both TLS and IPSec can - also make use of bastion hosts at the edges of administrative domains - that participate in the security associations to aggregate secure - tunnels and sockets. These bastion hosts can also take the brunt of - denial-of-service attacks, ensuring that SIP hosts within the - administrative domain are not encumbered with superfluous messaging. - - - -Rosenberg, et. al. Standards Track [Page 246] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - No matter what security solutions are deployed, floods of messages - directed at proxy servers can lock up proxy server resources and - prevent desirable traffic from reaching its destination. There is a - computational expense associated with processing a SIP transaction at - a proxy server, and that expense is greater for stateful proxy - servers than it is for stateless proxy servers. Therefore, stateful - proxies are more susceptible to flooding than stateless proxy - servers. - - UAs and proxy servers SHOULD challenge questionable requests with - only a single 401 (Unauthorized) or 407 (Proxy Authentication - Required), forgoing the normal response retransmission algorithm, and - thus behaving statelessly towards unauthenticated requests. - - Retransmitting the 401 (Unauthorized) or 407 (Proxy Authentication - Required) status response amplifies the problem of an attacker - using a falsified header field value (such as Via) to direct - traffic to a third party. - - In summary, the mutual authentication of proxy servers through - mechanisms such as TLS significantly reduces the potential for rogue - intermediaries to introduce falsified requests or responses that can - deny service. This commensurately makes it harder for attackers to - make innocent SIP nodes into agents of amplification. - -26.4 Limitations - - Although these security mechanisms, when applied in a judicious - manner, can thwart many threats, there are limitations in the scope - of the mechanisms that must be understood by implementers and network - operators. - -26.4.1 HTTP Digest - - One of the primary limitations of using HTTP Digest in SIP is that - the integrity mechanisms in Digest do not work very well for SIP. - Specifically, they offer protection of the Request-URI and the method - of a message, but not for any of the header fields that UAs would - most likely wish to secure. - - The existing replay protection mechanisms described in RFC 2617 also - have some limitations for SIP. The next-nonce mechanism, for - example, does not support pipelined requests. The nonce-count - mechanism should be used for replay protection. - - Another limitation of HTTP Digest is the scope of realms. Digest is - valuable when a user wants to authenticate themselves to a resource - with which they have a pre-existing association, like a service - - - -Rosenberg, et. al. Standards Track [Page 247] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - provider of which the user is a customer (which is quite a common - scenario and thus Digest provides an extremely useful function). By - way of contrast, the scope of TLS is interdomain or multirealm, since - certificates are often globally verifiable, so that the UA can - authenticate the server with no pre-existing association. - -26.4.2 S/MIME - - The largest outstanding defect with the S/MIME mechanism is the lack - of a prevalent public key infrastructure for end users. If self- - signed certificates (or certificates that cannot be verified by one - of the participants in a dialog) are used, the SIP-based key exchange - mechanism described in Section 23.2 is susceptible to a man-in-the- - middle attack with which an attacker can potentially inspect and - modify S/MIME bodies. The attacker needs to intercept the first - exchange of keys between the two parties in a dialog, remove the - existing CMS-detached signatures from the request and response, and - insert a different CMS-detached signature containing a certificate - supplied by the attacker (but which seems to be a certificate for the - proper address-of-record). Each party will think they have exchanged - keys with the other, when in fact each has the public key of the - attacker. - - It is important to note that the attacker can only leverage this - vulnerability on the first exchange of keys between two parties - on - subsequent occasions, the alteration of the key would be noticeable - to the UAs. It would also be difficult for the attacker to remain in - the path of all future dialogs between the two parties over time (as - potentially days, weeks, or years pass). - - SSH is susceptible to the same man-in-the-middle attack on the first - exchange of keys; however, it is widely acknowledged that while SSH - is not perfect, it does improve the security of connections. The use - of key fingerprints could provide some assistance to SIP, just as it - does for SSH. For example, if two parties use SIP to establish a - voice communications session, each could read off the fingerprint of - the key they received from the other, which could be compared against - the original. It would certainly be more difficult for the man-in- - the-middle to emulate the voices of the participants than their - signaling (a practice that was used with the Clipper chip-based - secure telephone). - - The S/MIME mechanism allows UAs to send encrypted requests without - preamble if they possess a certificate for the destination address- - of-record on their keyring. However, it is possible that any - particular device registered for an address-of-record will not hold - the certificate that has been previously employed by the device's - current user, and that it will therefore be unable to process an - - - -Rosenberg, et. al. Standards Track [Page 248] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - encrypted request properly, which could lead to some avoidable error - signaling. This is especially likely when an encrypted request is - forked. - - The keys associated with S/MIME are most useful when associated with - a particular user (an address-of-record) rather than a device (a UA). - When users move between devices, it may be difficult to transport - private keys securely between UAs; how such keys might be acquired by - a device is outside the scope of this document. - - Another, more prosaic difficulty with the S/MIME mechanism is that it - can result in very large messages, especially when the SIP tunneling - mechanism described in Section 23.4 is used. For that reason, it is - RECOMMENDED that TCP should be used as a transport protocol when - S/MIME tunneling is employed. - -26.4.3 TLS - - The most commonly voiced concern about TLS is that it cannot run over - UDP; TLS requires a connection-oriented underlying transport - protocol, which for the purposes of this document means TCP. - - It may also be arduous for a local outbound proxy server and/or - registrar to maintain many simultaneous long-lived TLS connections - with numerous UAs. This introduces some valid scalability concerns, - especially for intensive ciphersuites. Maintaining redundancy of - long-lived TLS connections, especially when a UA is solely - responsible for their establishment, could also be cumbersome. - - TLS only allows SIP entities to authenticate servers to which they - are adjacent; TLS offers strictly hop-by-hop security. Neither TLS, - nor any other mechanism specified in this document, allows clients to - authenticate proxy servers to whom they cannot form a direct TCP - connection. - -26.4.4 SIPS URIs - - Actually using TLS on every segment of a request path entails that - the terminating UAS must be reachable over TLS (perhaps registering - with a SIPS URI as a contact address). This is the preferred use of - SIPS. Many valid architectures, however, use TLS to secure part of - the request path, but rely on some other mechanism for the final hop - to a UAS, for example. Thus SIPS cannot guarantee that TLS usage - will be truly end-to-end. Note that since many UAs will not accept - incoming TLS connections, even those UAs that do support TLS may be - required to maintain persistent TLS connections as described in the - TLS limitations section above in order to receive requests over TLS - as a UAS. - - - -Rosenberg, et. al. Standards Track [Page 249] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Location services are not required to provide a SIPS binding for a - SIPS Request-URI. Although location services are commonly populated - by user registrations (as described in Section 10.2.1), various other - protocols and interfaces could conceivably supply contact addresses - for an AOR, and these tools are free to map SIPS URIs to SIP URIs as - appropriate. When queried for bindings, a location service returns - its contact addresses without regard for whether it received a - request with a SIPS Request-URI. If a redirect server is accessing - the location service, it is up to the entity that processes the - Contact header field of a redirection to determine the propriety of - the contact addresses. - - Ensuring that TLS will be used for all of the request segments up to - the target domain is somewhat complex. It is possible that - cryptographically authenticated proxy servers along the way that are - non-compliant or compromised may choose to disregard the forwarding - rules associated with SIPS (and the general forwarding rules in - Section 16.6). Such malicious intermediaries could, for example, - retarget a request from a SIPS URI to a SIP URI in an attempt to - downgrade security. - - Alternatively, an intermediary might legitimately retarget a request - from a SIP to a SIPS URI. Recipients of a request whose Request-URI - uses the SIPS URI scheme thus cannot assume on the basis of the - Request-URI alone that SIPS was used for the entire request path - (from the client onwards). - - To address these concerns, it is RECOMMENDED that recipients of a - request whose Request-URI contains a SIP or SIPS URI inspect the To - header field value to see if it contains a SIPS URI (though note that - it does not constitute a breach of security if this URI has the same - scheme but is not equivalent to the URI in the To header field). - Although clients may choose to populate the Request-URI and To header - field of a request differently, when SIPS is used this disparity - could be interpreted as a possible security violation, and the - request could consequently be rejected by its recipient. Recipients - MAY also inspect the Via header chain in order to double-check - whether or not TLS was used for the entire request path until the - local administrative domain was reached. S/MIME may also be used by - the originating UAC to help ensure that the original form of the To - header field is carried end-to-end. - - If the UAS has reason to believe that the scheme of the Request-URI - has been improperly modified in transit, the UA SHOULD notify its - user of a potential security breach. - - - - - - -Rosenberg, et. al. Standards Track [Page 250] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - As a further measure to prevent downgrade attacks, entities that - accept only SIPS requests MAY also refuse connections on insecure - ports. - - End users will undoubtedly discern the difference between SIPS and - SIP URIs, and they may manually edit them in response to stimuli. - This can either benefit or degrade security. For example, if an - attacker corrupts a DNS cache, inserting a fake record set that - effectively removes all SIPS records for a proxy server, then any - SIPS requests that traverse this proxy server may fail. When a user, - however, sees that repeated calls to a SIPS AOR are failing, they - could on some devices manually convert the scheme from SIPS to SIP - and retry. Of course, there are some safeguards against this (if the - destination UA is truly paranoid it could refuse all non-SIPS - requests), but it is a limitation worth noting. On the bright side, - users might also divine that 'SIPS' would be valid even when they are - presented only with a SIP URI. - -26.5 Privacy - - SIP messages frequently contain sensitive information about their - senders - not just what they have to say, but with whom they - communicate, when they communicate and for how long, and from where - they participate in sessions. Many applications and their users - require that this sort of private information be hidden from any - parties that do not need to know it. - - Note that there are also less direct ways in which private - information can be divulged. If a user or service chooses to be - reachable at an address that is guessable from the person's name and - organizational affiliation (which describes most addresses-of- - record), the traditional method of ensuring privacy by having an - unlisted "phone number" is compromised. A user location service can - infringe on the privacy of the recipient of a session invitation by - divulging their specific whereabouts to the caller; an implementation - consequently SHOULD be able to restrict, on a per-user basis, what - kind of location and availability information is given out to certain - classes of callers. This is a whole class of problem that is - expected to be studied further in ongoing SIP work. - - In some cases, users may want to conceal personal information in - header fields that convey identity. This can apply not only to the - From and related headers representing the originator of the request, - but also the To - it may not be appropriate to convey to the final - destination a speed-dialing nickname, or an unexpanded identifier for - a group of targets, either of which would be removed from the - Request-URI as the request is routed, but not changed in the To - - - - -Rosenberg, et. al. Standards Track [Page 251] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - header field if the two were initially identical. Thus it MAY be - desirable for privacy reasons to create a To header field that - differs from the Request-URI. - -27 IANA Considerations - - All method names, header field names, status codes, and option tags - used in SIP applications are registered with IANA through - instructions in an IANA Considerations section in an RFC. - - The specification instructs the IANA to create four new sub- - registries under http://www.iana.org/assignments/sip-parameters: - Option Tags, Warning Codes (warn-codes), Methods and Response Codes, - added to the sub-registry of Header Fields that is already present - there. - -27.1 Option Tags - - This specification establishes the Option Tags sub-registry under - http://www.iana.org/assignments/sip-parameters. - - Option tags are used in header fields such as Require, Supported, - Proxy-Require, and Unsupported in support of SIP compatibility - mechanisms for extensions (Section 19.2). The option tag itself is a - string that is associated with a particular SIP option (that is, an - extension). It identifies the option to SIP endpoints. - - Option tags are registered by the IANA when they are published in - standards track RFCs. The IANA Considerations section of the RFC - must include the following information, which appears in the IANA - registry along with the RFC number of the publication. - - o Name of the option tag. The name MAY be of any length, but - SHOULD be no more than twenty characters long. The name MUST - consist of alphanum (Section 25) characters only. - - o Descriptive text that describes the extension. - -27.2 Warn-Codes - - This specification establishes the Warn-codes sub-registry under - http://www.iana.org/assignments/sip-parameters and initiates its - population with the warn-codes listed in Section 20.43. Additional - warn-codes are registered by RFC publication. - - - - - - - -Rosenberg, et. al. Standards Track [Page 252] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - The descriptive text for the table of warn-codes is: - - Warning codes provide information supplemental to the status code in - SIP response messages when the failure of the transaction results - from a Session Description Protocol (SDP) (RFC 2327 [1]) problem. - - The "warn-code" consists of three digits. A first digit of "3" - indicates warnings specific to SIP. Until a future specification - describes uses of warn-codes other than 3xx, only 3xx warn-codes may - be registered. - - Warnings 300 through 329 are reserved for indicating problems with - keywords in the session description, 330 through 339 are warnings - related to basic network services requested in the session - description, 370 through 379 are warnings related to quantitative QoS - parameters requested in the session description, and 390 through 399 - are miscellaneous warnings that do not fall into one of the above - categories. - -27.3 Header Field Names - - This obsoletes the IANA instructions about the header sub-registry - under http://www.iana.org/assignments/sip-parameters. - - The following information needs to be provided in an RFC publication - in order to register a new header field name: - - o The RFC number in which the header is registered; - - o the name of the header field being registered; - - o a compact form version for that header field, if one is - defined; - - Some common and widely used header fields MAY be assigned one-letter - compact forms (Section 7.3.3). Compact forms can only be assigned - after SIP working group review, followed by RFC publication. - -27.4 Method and Response Codes - - This specification establishes the Method and Response-Code sub- - registries under http://www.iana.org/assignments/sip-parameters and - initiates their population as follows. The initial Methods table is: - - - - - - - - -Rosenberg, et. al. Standards Track [Page 253] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - INVITE [RFC3261] - ACK [RFC3261] - BYE [RFC3261] - CANCEL [RFC3261] - REGISTER [RFC3261] - OPTIONS [RFC3261] - INFO [RFC2976] - - The response code table is initially populated from Section 21, the - portions labeled Informational, Success, Redirection, Client-Error, - Server-Error, and Global-Failure. The table has the following - format: - - Type (e.g., Informational) - Number Default Reason Phrase [RFC3261] - - The following information needs to be provided in an RFC publication - in order to register a new response code or method: - - o The RFC number in which the method or response code is - registered; - - o the number of the response code or name of the method being - registered; - - o the default reason phrase for that response code, if - applicable; - -27.5 The "message/sip" MIME type. - - This document registers the "message/sip" MIME media type in order to - allow SIP messages to be tunneled as bodies within SIP, primarily for - end-to-end security purposes. This media type is defined by the - following information: - - Media type name: message - Media subtype name: sip - Required parameters: none - - Optional parameters: version - version: The SIP-Version number of the enclosed message (e.g., - "2.0"). If not present, the version defaults to "2.0". - Encoding scheme: SIP messages consist of an 8-bit header - optionally followed by a binary MIME data object. As such, SIP - messages must be treated as binary. Under normal circumstances - SIP messages are transported over binary-capable transports, no - special encodings are needed. - - - - -Rosenberg, et. al. Standards Track [Page 254] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Security considerations: see below - Motivation and examples of this usage as a security mechanism - in concert with S/MIME are given in 23.4. - -27.6 New Content-Disposition Parameter Registrations - - This document also registers four new Content-Disposition header - "disposition-types": alert, icon, session and render. The authors - request that these values be recorded in the IANA registry for - Content-Dispositions. - - Descriptions of these "disposition-types", including motivation and - examples, are given in Section 20.11. - - Short descriptions suitable for the IANA registry are: - - alert the body is a custom ring tone to alert the user - icon the body is displayed as an icon to the user - render the body should be displayed to the user - session the body describes a communications session, for - example, as RFC 2327 SDP body - -28 Changes From RFC 2543 - - This RFC revises RFC 2543. It is mostly backwards compatible with - RFC 2543. The changes described here fix many errors discovered in - RFC 2543 and provide information on scenarios not detailed in RFC - 2543. The protocol has been presented in a more cleanly layered - model here. - - We break the differences into functional behavior that is a - substantial change from RFC 2543, which has impact on - interoperability or correct operation in some cases, and functional - behavior that is different from RFC 2543 but not a potential source - of interoperability problems. There have been countless - clarifications as well, which are not documented here. - -28.1 Major Functional Changes - - o When a UAC wishes to terminate a call before it has been answered, - it sends CANCEL. If the original INVITE still returns a 2xx, the - UAC then sends BYE. BYE can only be sent on an existing call leg - (now called a dialog in this RFC), whereas it could be sent at any - time in RFC 2543. - - o The SIP BNF was converted to be RFC 2234 compliant. - - - - - -Rosenberg, et. al. Standards Track [Page 255] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - o SIP URL BNF was made more general, allowing a greater set of - characters in the user part. Furthermore, comparison rules were - simplified to be primarily case-insensitive, and detailed handling - of comparison in the presence of parameters was described. The - most substantial change is that a URI with a parameter with the - default value does not match a URI without that parameter. - - o Removed Via hiding. It had serious trust issues, since it relied - on the next hop to perform the obfuscation process. Instead, Via - hiding can be done as a local implementation choice in stateful - proxies, and thus is no longer documented. - - o In RFC 2543, CANCEL and INVITE transactions were intermingled. - They are separated now. When a user sends an INVITE and then a - CANCEL, the INVITE transaction still terminates normally. A UAS - needs to respond to the original INVITE request with a 487 - response. - - o Similarly, CANCEL and BYE transactions were intermingled; RFC 2543 - allowed the UAS not to send a response to INVITE when a BYE was - received. That is disallowed here. The original INVITE needs a - response. - - o In RFC 2543, UAs needed to support only UDP. In this RFC, UAs - need to support both UDP and TCP. - - o In RFC 2543, a forking proxy only passed up one challenge from - downstream elements in the event of multiple challenges. In this - RFC, proxies are supposed to collect all challenges and place them - into the forwarded response. - - o In Digest credentials, the URI needs to be quoted; this is unclear - from RFC 2617 and RFC 2069 which are both inconsistent on it. - - o SDP processing has been split off into a separate specification - [13], and more fully specified as a formal offer/answer exchange - process that is effectively tunneled through SIP. SDP is allowed - in INVITE/200 or 200/ACK for baseline SIP implementations; RFC - 2543 alluded to the ability to use it in INVITE, 200, and ACK in a - single transaction, but this was not well specified. More complex - SDP usages are allowed in extensions. - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 256] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - o Added full support for IPv6 in URIs and in the Via header field. - Support for IPv6 in Via has required that its header field - parameters allow the square bracket and colon characters. These - characters were previously not permitted. In theory, this could - cause interop problems with older implementations. However, we - have observed that most implementations accept any non-control - ASCII character in these parameters. - - o DNS SRV procedure is now documented in a separate specification - [4]. This procedure uses both SRV and NAPTR resource records and - no longer combines data from across SRV records as described in - RFC 2543. - - o Loop detection has been made optional, supplanted by a mandatory - usage of Max-Forwards. The loop detection procedure in RFC 2543 - had a serious bug which would report "spirals" as an error - condition when it was not. The optional loop detection procedure - is more fully and correctly specified here. - - o Usage of tags is now mandatory (they were optional in RFC 2543), - as they are now the fundamental building blocks of dialog - identification. - - o Added the Supported header field, allowing for clients to indicate - what extensions are supported to a server, which can apply those - extensions to the response, and indicate their usage with a - Require in the response. - - o Extension parameters were missing from the BNF for several header - fields, and they have been added. - - o Handling of Route and Record-Route construction was very - underspecified in RFC 2543, and also not the right approach. It - has been substantially reworked in this specification (and made - vastly simpler), and this is arguably the largest change. - Backwards compatibility is still provided for deployments that do - not use "pre-loaded routes", where the initial request has a set - of Route header field values obtained in some way outside of - Record-Route. In those situations, the new mechanism is not - interoperable. - - o In RFC 2543, lines in a message could be terminated with CR, LF, - or CRLF. This specification only allows CRLF. - - - - - - - - -Rosenberg, et. al. Standards Track [Page 257] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - o Usage of Route in CANCEL and ACK was not well defined in RFC 2543. - It is now well specified; if a request had a Route header field, - its CANCEL or ACK for a non-2xx response to the request need to - carry the same Route header field values. ACKs for 2xx responses - use the Route values learned from the Record-Route of the 2xx - responses. - - o RFC 2543 allowed multiple requests in a single UDP packet. This - usage has been removed. - - o Usage of absolute time in the Expires header field and parameter - has been removed. It caused interoperability problems in elements - that were not time synchronized, a common occurrence. Relative - times are used instead. - - o The branch parameter of the Via header field value is now - mandatory for all elements to use. It now plays the role of a - unique transaction identifier. This avoids the complex and bug- - laden transaction identification rules from RFC 2543. A magic - cookie is used in the parameter value to determine if the previous - hop has made the parameter globally unique, and comparison falls - back to the old rules when it is not present. Thus, - interoperability is assured. - - o In RFC 2543, closure of a TCP connection was made equivalent to a - CANCEL. This was nearly impossible to implement (and wrong) for - TCP connections between proxies. This has been eliminated, so - that there is no coupling between TCP connection state and SIP - processing. - - o RFC 2543 was silent on whether a UA could initiate a new - transaction to a peer while another was in progress. That is now - specified here. It is allowed for non-INVITE requests, disallowed - for INVITE. - - o PGP was removed. It was not sufficiently specified, and not - compatible with the more complete PGP MIME. It was replaced with - S/MIME. - - o Added the "sips" URI scheme for end-to-end TLS. This scheme is - not backwards compatible with RFC 2543. Existing elements that - receive a request with a SIPS URI scheme in the Request-URI will - likely reject the request. This is actually a feature; it ensures - that a call to a SIPS URI is only delivered if all path hops can - be secured. - - - - - - -Rosenberg, et. al. Standards Track [Page 258] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - o Additional security features were added with TLS, and these are - described in a much larger and complete security considerations - section. - - o In RFC 2543, a proxy was not required to forward provisional - responses from 101 to 199 upstream. This was changed to MUST. - This is important, since many subsequent features depend on - delivery of all provisional responses from 101 to 199. - - o Little was said about the 503 response code in RFC 2543. It has - since found substantial use in indicating failure or overload - conditions in proxies. This requires somewhat special treatment. - Specifically, receipt of a 503 should trigger an attempt to - contact the next element in the result of a DNS SRV lookup. Also, - 503 response is only forwarded upstream by a proxy under certain - conditions. - - o RFC 2543 defined, but did no sufficiently specify, a mechanism for - UA authentication of a server. That has been removed. Instead, - the mutual authentication procedures of RFC 2617 are allowed. - - o A UA cannot send a BYE for a call until it has received an ACK for - the initial INVITE. This was allowed in RFC 2543 but leads to a - potential race condition. - - o A UA or proxy cannot send CANCEL for a transaction until it gets a - provisional response for the request. This was allowed in RFC - 2543 but leads to potential race conditions. - - o The action parameter in registrations has been deprecated. It was - insufficient for any useful services, and caused conflicts when - application processing was applied in proxies. - - o RFC 2543 had a number of special cases for multicast. For - example, certain responses were suppressed, timers were adjusted, - and so on. Multicast now plays a more limited role, and the - protocol operation is unaffected by usage of multicast as opposed - to unicast. The limitations as a result of that are documented. - - o Basic authentication has been removed entirely and its usage - forbidden. - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 259] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - o Proxies no longer forward a 6xx immediately on receiving it. - Instead, they CANCEL pending branches immediately. This avoids a - potential race condition that would result in a UAC getting a 6xx - followed by a 2xx. In all cases except this race condition, the - result will be the same - the 6xx is forwarded upstream. - - o RFC 2543 did not address the problem of request merging. This - occurs when a request forks at a proxy and later rejoins at an - element. Handling of merging is done only at a UA, and procedures - are defined for rejecting all but the first request. - -28.2 Minor Functional Changes - - o Added the Alert-Info, Error-Info, and Call-Info header fields for - optional content presentation to users. - - o Added the Content-Language, Content-Disposition and MIME-Version - header fields. - - o Added a "glare handling" mechanism to deal with the case where - both parties send each other a re-INVITE simultaneously. It uses - the new 491 (Request Pending) error code. - - o Added the In-Reply-To and Reply-To header fields for supporting - the return of missed calls or messages at a later time. - - o Added TLS and SCTP as valid SIP transports. - - o There were a variety of mechanisms described for handling failures - at any time during a call; those are now generally unified. BYE - is sent to terminate. - - o RFC 2543 mandated retransmission of INVITE responses over TCP, but - noted it was really only needed for 2xx. That was an artifact of - insufficient protocol layering. With a more coherent transaction - layer defined here, that is no longer needed. Only 2xx responses - to INVITEs are retransmitted over TCP. - - o Client and server transaction machines are now driven based on - timeouts rather than retransmit counts. This allows the state - machines to be properly specified for TCP and UDP. - - o The Date header field is used in REGISTER responses to provide a - simple means for auto-configuration of dates in user agents. - - o Allowed a registrar to reject registrations with expirations that - are too short in duration. Defined the 423 response code and the - Min-Expires for this purpose. - - - -Rosenberg, et. al. Standards Track [Page 260] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -29 Normative References - - [1] Handley, M. and V. Jacobson, "SDP: Session Description - Protocol", RFC 2327, April 1998. - - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [3] Resnick, P., "Internet Message Format", RFC 2822, April 2001. - - [4] Rosenberg, J. and H. Schulzrinne, "SIP: Locating SIP Servers", - RFC 3263, June 2002. - - [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource - Identifiers (URI): Generic Syntax", RFC 2396, August 1998. - - [6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for - Transport Layer Security (TLS)", RFC 3268, June 2002. - - [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC - 2279, January 1998. - - [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., - Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- - HTTP/1.1", RFC 2616, June 1999. - - [9] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April - 2000. - - [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [11] Freed, F. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part Two: Media Types", RFC 2046, November - 1996. - - [12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness - Recommendations for Security", RFC 1750, December 1994. - - [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with - SDP", RFC 3264, June 2002. - - [14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August - 1980. - - [15] Postel, J., "DoD Standard Transmission Control Protocol", RFC - 761, January 1980. - - - - -Rosenberg, et. al. Standards Track [Page 261] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - [16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, - H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, - "Stream Control Transmission Protocol", RFC 2960, October 2000. - - [17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., - Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication: - Basic and Digest Access Authentication", RFC 2617, June 1999. - - [18] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation - Information in Internet Messages: The Content-Disposition Header - Field", RFC 2183, August 1997. - - [19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., - Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG - Objects", RFC 3204, December 2001. - - [20] Braden, R., "Requirements for Internet Hosts - Application and - Support", STD 3, RFC 1123, October 1989. - - [21] Alvestrand, H., "IETF Policy on Character Sets and Languages", - BCP 18, RFC 2277, January 1998. - - [22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security - Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", - RFC 1847, October 1995. - - [23] Housley, R., "Cryptographic Message Syntax", RFC 2630, June - 1999. - - [24] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 2633, - June 1999. - - [25] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC - 2246, January 1999. - - [26] Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - -30 Informative References - - [27] R. Pandya, "Emerging mobile and personal communication systems," - IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995. - - [28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, - "RTP: A Transport Protocol for Real-Time Applications", RFC - 1889, January 1996. - - - - - -Rosenberg, et. al. Standards Track [Page 262] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - [29] Schulzrinne, H., Rao, R. and R. Lanphier, "Real Time Streaming - Protocol (RTSP)", RFC 2326, April 1998. - - [30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and - J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November - 2000. - - [31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, - "SIP: Session Initiation Protocol", RFC 2543, March 1999. - - [32] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL - scheme", RFC 2368, July 1998. - - [33] E. M. Schooler, "A multicast user directory service for - synchronous rendezvous," Master's Thesis CS-TR-96-18, Department - of Computer Science, California Institute of Technology, - Pasadena, California, Aug. 1996. - - [34] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. - - [35] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April - 1992. - - [36] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC - 2426, September 1998. - - [37] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical - Specification", RFC 2849, June 2000. - - [38] Palme, J., "Common Internet Message Headers", RFC 2076, - February 1997. - - [39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., - Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: - Digest Access Authentication", RFC 2069, January 1997. - - [40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis, - D., Rosenberg, J., Summers, K. and H. Schulzrinne, "SIP Call - Flow Examples", Work in Progress. - - [41] E. M. Schooler, "Case study: multimedia conference control in a - packet-switched teleconferencing system," Journal of - Internetworking: Research and Experience, Vol. 4, pp. 99--120, - June 1993. ISI reprint series ISI/RS-93-359. - - - - - - - -Rosenberg, et. al. Standards Track [Page 263] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - [42] H. Schulzrinne, "Personal mobility for multimedia services in - the Internet," in European Workshop on Interactive Distributed - Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar. - 1996. - - [43] Floyd, S., "Congestion Control Principles", RFC 2914, September - 2000. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 264] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -A Table of Timer Values - - Table 4 summarizes the meaning and defaults of the various timers - used by this specification. - -Timer Value Section Meaning ----------------------------------------------------------------------- -T1 500ms default Section 17.1.1.1 RTT Estimate -T2 4s Section 17.1.2.2 The maximum retransmit - interval for non-INVITE - requests and INVITE - responses -T4 5s Section 17.1.2.2 Maximum duration a - message will - remain in the network -Timer A initially T1 Section 17.1.1.2 INVITE request retransmit - interval, for UDP only -Timer B 64*T1 Section 17.1.1.2 INVITE transaction - timeout timer -Timer C > 3min Section 16.6 proxy INVITE transaction - bullet 11 timeout -Timer D > 32s for UDP Section 17.1.1.2 Wait time for response - 0s for TCP/SCTP retransmits -Timer E initially T1 Section 17.1.2.2 non-INVITE request - retransmit interval, - UDP only -Timer F 64*T1 Section 17.1.2.2 non-INVITE transaction - timeout timer -Timer G initially T1 Section 17.2.1 INVITE response - retransmit interval -Timer H 64*T1 Section 17.2.1 Wait time for - ACK receipt -Timer I T4 for UDP Section 17.2.1 Wait time for - 0s for TCP/SCTP ACK retransmits -Timer J 64*T1 for UDP Section 17.2.2 Wait time for - 0s for TCP/SCTP non-INVITE request - retransmits -Timer K T4 for UDP Section 17.1.2.2 Wait time for - 0s for TCP/SCTP response retransmits - - Table 4: Summary of timers - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 265] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -Acknowledgments - - We wish to thank the members of the IETF MMUSIC and SIP WGs for their - comments and suggestions. Detailed comments were provided by Ofir - Arkin, Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan, - Keith Drage, Bill Fenner, Cedric Fluckiger, Yaron Goland, John - Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema, - Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders - Kristensen, Jonathan Lennox, Gethin Liddell, Allison Mankin, William - Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe - J. Sambol, Chip Sharp, Igor Slepchin, Eric Tremblay, and Rick - Workman. - - Brian Rosen provided the compiled BNF. - - Jean Mahoney provided technical writing assistance. - - This work is based, inter alia, on [41,42]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 266] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -Authors' Addresses - - Authors addresses are listed alphabetically for the editors, the - writers, and then the original authors of RFC 2543. All listed - authors actively contributed large amounts of text to this document. - - Jonathan Rosenberg - dynamicsoft - 72 Eagle Rock Ave - East Hanover, NJ 07936 - USA - - EMail: jdrosen@dynamicsoft.com - - - Henning Schulzrinne - Dept. of Computer Science - Columbia University - 1214 Amsterdam Avenue - New York, NY 10027 - USA - - EMail: schulzrinne@cs.columbia.edu - - - Gonzalo Camarillo - Ericsson - Advanced Signalling Research Lab. - FIN-02420 Jorvas - Finland - - EMail: Gonzalo.Camarillo@ericsson.com - - - Alan Johnston - WorldCom - 100 South 4th Street - St. Louis, MO 63102 - USA - - EMail: alan.johnston@wcom.com - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 267] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - - Jon Peterson - NeuStar, Inc - 1800 Sutter Street, Suite 570 - Concord, CA 94520 - USA - - EMail: jon.peterson@neustar.com - - - Robert Sparks - dynamicsoft, Inc. - 5100 Tennyson Parkway - Suite 1200 - Plano, Texas 75024 - USA - - EMail: rsparks@dynamicsoft.com - - - Mark Handley - International Computer Science Institute - 1947 Center St, Suite 600 - Berkeley, CA 94704 - USA - - EMail: mjh@icir.org - - - Eve Schooler - AT&T Labs-Research - 75 Willow Road - Menlo Park, CA 94025 - USA - - EMail: schooler@research.att.com - - - - - - - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 268] - -RFC 3261 SIP: Session Initiation Protocol June 2002 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Rosenberg, et. al. Standards Track [Page 269] - diff --git a/etc/rfc3283.txt b/etc/rfc3283.txt deleted file mode 100644 index 1960f92..0000000 --- a/etc/rfc3283.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -Network Working Group B. Mahoney -Request for Comments: 3283 MIT -Category: Informational G. Babics - Steltor - A. Taler - June 2002 - - - Guide to Internet Calendaring - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2002). All Rights Reserved. - -Abstract - - This document describes the various Internet calendaring and - scheduling standards and works in progress, and the relationships - between them. Its intent is to provide a context for these - documents, assist in their understanding, and potentially aid in the - design of standards-based calendaring and scheduling systems. The - standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and - RFC 2447 (iMIP). The work in progress addressed is "Calendar Access - Protocol" (CAP). This document also describes issues and problems - that are not solved by these protocols, and that could be targets for - future work. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2 - 1.2 Concepts and Relationships . . . . . . . . . . . . . . . . . 4 - 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1 Fundamental Needs . . . . . . . . . . . . . . . . . . . . . 4 - 2.2 Protocol Requirements . . . . . . . . . . . . . . . . . . . 5 - 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2 Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.2.1 Standalone Single-user System . . . . . . . . . . . . . . . 8 - 3.2.2 Single-user Systems Communicating . . . . . . . . . . . . . 8 - 3.2.3 Single-user with Multiple CUAs . . . . . . . . . . . . . . . 9 - 3.2.4 Single-user with Multiple Calendars . . . . . . . . . . . . 9 - - - -Mahoney, et. al. Informational [Page 1] - -RFC 3283 Guide to Internet Calendaring June 2002 - - - 3.2.5 Users Communicating on a Multi-user System . . . . . . . . . 10 - 3.2.6 Users Communicating through Different Multi-user Systems . . 10 - 4. Important Aspects . . . . . . . . . . . . . . . . . . . . . 10 - 4.1 Timezones . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.2 Choice of Transport . . . . . . . . . . . . . . . . . . . . 11 - 4.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.4 Amount of data . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.5 Recurring Components . . . . . . . . . . . . . . . . . . . . 11 - 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 11 - 5.1 Scheduling People, not Calendars . . . . . . . . . . . . . . 12 - 5.2 Administration . . . . . . . . . . . . . . . . . . . . . . . 12 - 5.3 Notification . . . . . . . . . . . . . . . . . . . . . . . . 12 - 6. Security Considerations . . . . . . . . . . . . . . . . . . 12 - 6.1 Access Control . . . . . . . . . . . . . . . . . . . . . . . 12 - 6.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 12 - 6.3 Using E-mail . . . . . . . . . . . . . . . . . . . . . . . . 13 - 6.4 Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 13 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 - References . . . . . . . . . . . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 - Full Copyright Statement . . . . . . . . . . . . . . . . . . 16 - -1. Introduction - - Calendaring and scheduling protocols are intended to aid individuals - in obtaining calendaring information and scheduling meetings across - the Internet, to aid organizations in providing calendaring - information on the Internet, and to provide for organizations looking - for a calendaring and scheduling solution to deploy internally. - - It is the intent of this document to provide a context for these - documents, assist in their understanding, and potentially help in the - design of standards-based calendaring and scheduling systems. - - Problems not solved by these protocols, as well as security issues to - be kept in mind, are discussed at the end of the document. - -1.1 Terminology - - This memo uses much of the same terminology as iCalendar [RFC-2445], - iTIP [RFC-2446], iMIP [RFC-2447], and [CAP]. The following - definitions are provided as an introduction; the definitions in the - protocol specifications themselves should be considered canonical. - - - - - - - - -Mahoney, et. al. Informational [Page 2] - -RFC 3283 Guide to Internet Calendaring June 2002 - - - Calendar - - A collection of events, to-dos, journal entries, etc. A calendar - could be the content of a person or resource's agenda; it could - also be a collection of data serving a more specialized need. - Calendars are the basic storage containers for calendaring - information. - - Calendar Access Rights - - A set of rules defining who may perform what operations, such as - reading or writing information, on a given calendar. - - Calendar Service - - A running server application that provides access to a number of - calendar stores. - - Calendar Store (CS) - - A data store of a calendar service. A calendar service may have - several calendar stores, and each store may contain several - calendars, as well as properties and components outside of those - calendars. - - Calendar User (CU) - - An entity (often a human) that accesses calendar information. - - Calendar User Agent (CUA) - - Software with which the calendar user communicates with a calendar - service or local calendar store to access calendar information. - - Component - - A piece of calendar data such as an event, a to-do or an alarm. - Information about components is stored as properties of those - components. - - Delegator - - A calendar user who has assigned his or her participation in a - scheduled calendar component (e.g. a VEVENT) to another calendar - user (sometimes called the delegate or delegatee). An example of - a delegator is a busy executive sending an employee to a meeting - in his or her place. - - - - -Mahoney, et. al. Informational [Page 3] - -RFC 3283 Guide to Internet Calendaring June 2002 - - - Delegate - - A calendar user (sometimes called the delegatee) who has been - assigned to participate in a scheduled calendar component (e.g. a - VEVENT) in place of one of the attendees in that component - (sometimes called the delegator). An example of a delegate is a - team member sent to a particular meeting. - - Designate - - A calendar user authorized to act on behalf of another calendar - user. An example of a designate is an assistant scheduling - meetings for his or her superior. - - Local Store - - A CS that is on the same device as the CUA. - - Property - - A description of some element of a component, such as a start - time, title or location. - - Remote Store - - A CS that is not on the same device as the CUA. - -1.2 Concepts and Relationships - - iCalendar is the language used to describe calendar objects. iTIP - describes a way to use the iCalendar language to do scheduling. iMIP - describes how to do iTIP scheduling via e-mail. CAP describes a way - to use the iCalendar language to access a calendar store in real- - time. - - The relationship between calendaring protocols is similar to that - between e-mail protocols. In those terms, iCalendar is analogous to - RFC 2822, iTIP and iMIP are analogous to the Simple Mail Transfer - Protocol (SMTP), and CAP is analogous to the Post Office Protocol - (POP) or Internet Message Access Protocol (IMAP). - -2. Requirements - -2.1 Fundamental Needs - - The following scenarios illustrate people and organizations' basic - calendaring and scheduling needs: - - - - -Mahoney, et. al. Informational [Page 4] - -RFC 3283 Guide to Internet Calendaring June 2002 - - - a] A doctor wishes to keep track of all her appointments. - - Need: To read and manipulate one's own calendar with only one CUA. - - b] A busy musician wants to maintain her schedule with multiple - devices, such as through an Internet-based agenda and with a PDA. - - Need: To read and manipulate one's own calendar, possibly with - solutions from different vendors. - - c] A software development team wishes to more effectively schedule - their time through viewing each other's calendar information. - - Need: To share calendar information between users of the same - calendar service. - - d] A teacher wants his students to schedule appointments during - his office hours. - - Need: To schedule calendar events, to-dos and journals with other - users of the same calendar service. - - e] A movie theater wants to publish its schedule for prospective - customers. - - Need: To share calendar information with users of other calendar - services, possibly from a number of different vendors. - - f] A social club wants to schedule calendar entries effectively - with its members. - - Need: To schedule calendar events and to-dos with users of other - calendar services, possibly from a number of different vendors. - -2.2 Protocol Requirements - - Some of these needs can be met by proprietary solutions (a, c, d), - but others can not (b, e, f). These latter scenarios show that - standard protocols are required for accessing information in a - calendar store and scheduling calendar entries. In addition, these - protocols require a common data format for representing calendar - information. - - These requirements are met by the following protocol specifications. - - - - - - - -Mahoney, et. al. Informational [Page 5] - -RFC 3283 Guide to Internet Calendaring June 2002 - - - - Data format: iCalendar [RFC-2445] - - iCalendar [RFC-2445] provides a data format for representing - calendar information, to be used and exchanged by other protocols. - iCalendar [RFC-2445] can also be used in other contexts, such as a - drag-and-drop interface, or an export/import feature. All the - other calendaring protocols depend on iCalendar [RFC-2445], so all - elements of a standards-based calendaring and scheduling systems - will have to be able to interpret iCalendar [RFC-2445]. - - - Scheduling protocol: iTIP [RFC-2446] - - iTIP [RFC-2446] describes the messages used to schedule calendar - events. Within iTIP messages, events are represented in iCalendar - [RFC-2445] format, and have semantics that identify the message as - being an invitation to a meeting, an acceptance of an invitation, - or the assignment of a task. - - iTIP [RFC-2446] messages are used in the scheduling workflow, - where users exchange messages in order to organize things such as - events and to-dos. CUAs generate and interpret iTIP [RFC-2446] - messages at the direction of the calendar user. With iTIP [RFC- - 2446] users can create, modify, delete, reply to, counter, and - decline counters to the various iCalendar [RFC-2445] components. - Furthermore, users can also request the free/busy time of other - people. - - iTIP [RFC-2446] is transport-independent, and has one specified - transport binding: iMIP [RFC-2447] binds iTIP to e-mail. In - addition [CAP] will provide a real-time binding of iTIP [RFC- - 2446], allowing CUAs to perform calendar management and scheduling - over a single connection. - - - Calendar management protocol: [CAP] - - [CAP] describes the messages used to manage calendars on a - calendar store. These messages use iCalendar [RFC-2445] to - describe various components such as events and to-dos. These - messages make it possible to perform iTIP [RFC-2446] operations, - as well as other operations relating to a calendar store such as - searching, creating calendars, specifying calendar properties, and - specifying calendar access rights. - - - - - - - - - -Mahoney, et. al. Informational [Page 6] - -RFC 3283 Guide to Internet Calendaring June 2002 - - -3. Solutions - -3.1 Examples - - Returning to the scenarios presented in section 2.1, the calendaring - protocols can be used in the following ways: - - a] The doctor can use a proprietary CUA with a local store, and - perhaps use iCalendar [RFC-2445] as a storage mechanism. This - would allow her to easily import her data store into another - application that supports iCalendar [RFC-2445]. - - b] The musician who wishes to access her agenda from anywhere can - use a [CAP]-enabled calendar service accessible over the Internet. - She can then use any available [CAP] clients to access the data. - - A proprietary system that provides access through a Web-based - interface could also be employed, but the use of [CAP] would be - superior in that it would allow the use of third party - applications, such as PDA synchronization tools. - - c] The development team can use a calendar service which supports - [CAP], and each member can use a [CAP]-enabled CUA of their - choice. - - Alternatively, each member could use an iMIP [RFC-2447]-enabled - CUA, and they could book meetings over e-mail. This solution has - the drawback that it is difficult to examine other users' agendas, - making the organization of meetings more difficult. - - Proprietary solutions are also available, but they require that - all members use clients by the same vendor, and disallow the use - of third party applications. - - d] The teacher can set up a calendar service, and have students - book time through any of the iTIP [RFC-2446] bindings. [CAP] - provides real-time access, but could require additional - configuration. iMIP [RFC-2447] would be the easiest to configure, - but may require more e-mail processing. - - If [CAP] access is provided then determining the state of the - teacher's schedule is straightforward. If not, this can be - determined through iTIP [RFC-2446] free/busy requests. Non- - standard methods could also be employed, such as serving up - iCalendar [RFC-2445], HTML, or XML over HTTP. - - A proprietary system could also be used, but would require that - all students be able to use software from a specific vendor. - - - -Mahoney, et. al. Informational [Page 7] - -RFC 3283 Guide to Internet Calendaring June 2002 - - - e] [CAP] would be preferred for publishing a movie theater's - schedule, since it provides advanced access and search - capabilities. It also allows easy integration with customers' - calendar systems. - - Non-standard methods such as serving data over HTTP could also be - employed, but would be harder to integrate with customers' - systems. - - Using a completely proprietary solution would be very difficult, - if not impossible, since it would require every user to install - and use the proprietary software. - - f] The social club could distribute meeting information in the - form of iTIP [RFC-2446] messages, sent via e-mail using iMIP - [RFC-2447]. The club could distribute meeting invitations, as - well as a full published agenda. - - Alternatively, the club could provide access to a [CAP]-enabled - calendar service. However, this solution would be more expensive - since it requires the maintenance of a server. - -3.2 Systems - - The following diagrams illustrate possible systems and their usage of - the various protocols. - -3.2.1 Standalone Single-user System - - A single user system that does not communicate with other systems - need not employ any of the protocols. However, it may use iCalendar - [RFC-2445] as a data format in some places. - - ----------- O - | CUA w/ | -+- user - |local store| A - ----------- / \ - -3.2.2 Single-user Systems Communicating - - Users with single-user systems may schedule meetings with each others - using iTIP [RFC-2446]. The easiest binding of iTIP [RFC-2446] to use - would be iMIP [RFC-2447], since messages can be held in the users' - mail queues, which we assume to already exist. [CAP] could also be - used. - - - - - - -Mahoney, et. al. Informational [Page 8] - -RFC 3283 Guide to Internet Calendaring June 2002 - - - O ----------- ----------- O - -+- | CUA w/ | -----[iMIP]----- | CUA w/ | -+- user - A |local store| Internet |local store| A - / \ ----------- ----------- / \ - -3.2.3 Single-user with Multiple CUAs - - A single user may use more than one CUA to access his or her - calendar. The user may use a PDA, a Web client, a PC, or some other - device, depending on accessibility. Some of these clients may have - local stores and others may not. Those with local stores need to - synchronize the data on the CUA with the data on the CS. - - ----------- - | CUA w | -----[CAP]----------+ - |local store| | - O ----------- ---------- - -+- | CS | - A | | - / \ ---------- - ----------- | - | CUA w/o | -----[CAP]----------+ - |local store| - ----------- - -3.2.4 Single-user with Multiple Calendars - - A single user may have many independent calendars; for example, one - may contain work-related information and another personal - information. The CUA may or may not have a local store. If it does, - then it needs to synchronize the data of the CUA with the data on - both of the CS. - - ---------- - +------------[CAP]------ | CS | - | | | - O ----------- ---------- - -+- | CUA | - A | | - / \ ----------- - | ---------- - +------------[CAP]------ | CS | - | | - ---------- - - - - - - - -Mahoney, et. al. Informational [Page 9] - -RFC 3283 Guide to Internet Calendaring June 2002 - - -3.2.5 Users Communicating on a Multi-user System - - Users on a multi-user system may schedule meetings with each other - using [CAP]-enabled CUAs and services. The CUAs may or may not have - local stores. Those with local stores need to synchronize the data - on the CUAs with the data on the CS. - - O ----------- - -+- | CUA w | -----[CAP]----------+ - A |local store| | - / \ ----------- ---------- - | CS | - | | - ---------- - O ----------- | - -+- | CUA w/o | -----[CAP]----------+ - A |local store| - / \ ----------- - -3.2.6 Users Communicating through Different Multi-user Systems - - Users on a multi-user system may need to schedule meetings with users - on a different multi-user system. The services can communicate using - [CAP] or iMIP [RFC-2447]. - - O ----------- ---------- - -+- | CUA w | -----[CAP]-------| CS | - A |local store| | | - / \ ----------- ---------- - | - [CAP] or [iMIP] - | - O ----------- ---------- - -+- | CUA w/o | -----[CAP]-------| CS | - A |local store| | | - / \ ----------- ---------- - -4. Important Aspects - - There are a number of important aspects of these calendaring - standards of which people, especially implementers, should be aware. - -4.1 Timezones - - The dates and times in components can refer to a specific time zone. - Time zones can be defined in a central store, or they may be defined - by a user to fit his or her needs. All users and applications should - be aware of time zones and time zone differences. New time zones may - - - -Mahoney, et. al. Informational [Page 10] - -RFC 3283 Guide to Internet Calendaring June 2002 - - - need to be added, and others removed. Two different vendors may - describe the same time zone differently (such as by using a different - name). - -4.2 Choice of Transport - - There are issues to be aware of in choosing between a network - protocol such as [CAP], or a store and forward protocol, such as iMIP - [RFC-2447]. - - The use of a network ("on-the-wire") mechanism may require some - organizations to make provisions to allow calendaring traffic to - traverse a corporate firewall on the required ports. Depending on - the organizational culture, this may be a challenging social - exercise. - - The use of an email-based mechanism exposes time-sensitive data to - unbounded latency. Large or heavily utilized mail systems may - experience an unacceptable delay in message receipt. - -4.3 Security - - See the "Security Considerations" (Section 6) section below. - -4.4 Amount of data - - In some cases, a component may be very large, for instance, a - component with a very large attachment. Some applications may be - low-bandwidth or may be limited in the amount of data they can store. - Maximum component size may be set in [CAP]. It can also be - controlled in iMIP [RFC-2447] by restricting the maximum size of the - e-mail that the application can download. - -4.5 Recurring Components - - In iCAL [RFC-2445], one can specify complex recurrence rules for - VEVENTs, VTODOs, and VJOURNALs. One must be careful to correctly - interpret these recurrence rules and pay extra attention to being - able to interoperate using them. - -5. Open Issues - - Many issues are not currently resolved by these protocols, and many - desirable features are not yet provided. Some of the more prominent - ones are outlined below. - - - - - - -Mahoney, et. al. Informational [Page 11] - -RFC 3283 Guide to Internet Calendaring June 2002 - - -5.1 Scheduling People, not Calendars - - Meetings are scheduled with people; however, people may have many - calendars, and may store these calendars in many places. There may - also be many routes to contact them. The calendaring protocols do - not attempt to provide unique access for contacting a given person. - Instead, 'calendar addresses' are booked, which may be e-mail - addresses or individual calendars. It is up to the users themselves - to orchestrate mechanisms to ensure that the bookings go to the right - place. - -5.2 Administration - - The calendaring protocols do not address the issues of administering - users and calendars on a calendar service. This must be handled by - proprietary mechanisms for each implementation. - -5.3 Notification - - People often wish to be notified of upcoming events, new events, or - changes to existing events. The calendaring protocols do not attempt - to address these needs in a real-time system. Instead, the ability - to store alarm information on events is provided, which can be used - to provide client-side notification of upcoming events. To organize - notification of new or changed events, clients have to poll the data - store. - -6. Security Considerations - -6.1 Access Control - - There has to be reasonable granularity in the configuration options - for access to data through [CAP], so that what should be released to - requesters is released, and what shouldn't is not. Details of - handling this are described in [CAP]. - -6.2 Authentication - - Access control must be coupled with a good authentication system, so - that the right people get the right information. For [CAP], this - means requiring authentication before any database access can be - performed, and checking access rights and authentication credentials - before releasing information. [CAP] uses the Simple Authentication - Security Layer (SASL) for this authentication. In iMIP [RFC-2447], - this may present some challenges, as authentication is often not a - consideration in store-and-forward protocols. - - - - - -Mahoney, et. al. Informational [Page 12] - -RFC 3283 Guide to Internet Calendaring June 2002 - - - Authentication is also important for scheduling, in that receivers of - scheduling messages should be able to validate the apparent sender. - Since scheduling messages are wrapped in MIME [RFC-2045], signing and - encryption are freely available. For messages transmitted over mail, - this is the only available alternative. It is suggested that - developers take care in implementing the security features in iMIP - [RFC-2447], bearing in mind that the concept and need may be foreign - or non-obvious to users, yet essential for the system to function as - they might expect. - - The real-time protocols provide for the authentication of users, and - the preservation of that authentication information, allowing for - validation by the receiving end-user or server. - -6.3 Using E-mail - - Because scheduling information can be transmitted over mail without - any authentication information, e-mail spoofing is extremely easy if - the receiver is not checking for authentication. It is suggested - that implementers consider requiring authentication as a default, - using mechanisms such as are described in Section 3 of iMIP [RFC- - 2447]. The use of e-mail, and the potential for anonymous - connections, means that 'calendar spam' is possible. Developers - should consider this threat when designing systems, particularly - those that allow for automated request processing. - -6.4 Other Issues - - The current security context should be obvious to users. Because the - underlying mechanisms may not be clear to users, efforts to make - clear the current state in the UI should be made. One example of - this is the 'lock' icon used in some Web browsers during secure - connections. - - With both iMIP [RFC-2447] and [CAP], the possibilities of Denial of - Service attacks must be considered. The ability to flood a calendar - system with bogus requests is likely to be exploited once these - systems become widely deployed, and detection and recovery methods - will need to be considered. - -Acknowledgments - - Thanks to the following, who have participated in the development of - this document: - - Eric Busboom, Pat Egen, David Madeo, Shawn Packwood, Bruce Kahn, - Alan Davies, Robb Surridge. - - - - -Mahoney, et. al. Informational [Page 13] - -RFC 3283 Guide to Internet Calendaring June 2002 - - -References - - [RFC-2445] Dawson, F. and D. Stenerson, "Internet Calendaring and - Scheduling Core Object Specification - iCalendar", RFC - 2445, November 1998. - - [RFC-2446] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson, - "iCalendar Transport-Independent Interoperability Protocol - (iTIP): Scheduling Events, Busy Time, To-dos and Journal - Entries", RFC 2446, November 1998. - - [RFC-2447] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar - Message-Based Interoperability Protocol - iMIP", RFC 2447, - November 1998. - - [RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) - Part One: Format of Internet Message - Bodies", RFC 2045, November 1996. - - [CAP] Mansour, S., Royer, D., Babics, G., and Hill, P., - "Calendar Access Protocol (CAP)", Work in Progress. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Mahoney, et. al. Informational [Page 14] - -RFC 3283 Guide to Internet Calendaring June 2002 - - -Authors' Addresses - - Bob Mahoney - MIT - E40-327 - 77 Massachusetts Avenue - Cambridge, MA 02139 - US - - Phone: (617) 253-0774 - EMail: bobmah@mit.edu - - - George Babics - Steltor - 2000 Peel Street - Montreal, Quebec H3A 2W5 - CA - - Phone: (514) 733-8500 x4201 - EMail: georgeb@steltor.com - - - Alexander Taler - - EMail: alex@0--0.org - - - - - - - - - - - - - - - - - - - - - - - - - -Mahoney, et. al. Informational [Page 15] - -RFC 3283 Guide to Internet Calendaring June 2002 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Mahoney, et. al. Informational [Page 16] - diff --git a/etc/rfc3859.txt b/etc/rfc3859.txt deleted file mode 100644 index 7d9bfbf..0000000 --- a/etc/rfc3859.txt +++ /dev/null @@ -1,843 +0,0 @@ - - - - - - -Network Working Group J. Peterson -Request for Comments: 3859 NeuStar -Category: Standards Track August 2004 - - - Common Profile for Presence (CPP) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2004). - -Abstract - - 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. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Abstract Presence Service . . . . . . . . . . . . . . . . . . 4 - 3.1. Overview of the Presence Service . . . . . . . . . . . . 4 - 3.2. Identification of PRESENTITIES and WATCHERS . . . . . . 6 - 3.2.1. Address Resolution . . . . . . . . . . . . . . . 6 - 3.3. Format of Presence Information . . . . . . . . . . . . . 6 - 3.4. The Presence Service . . . . . . . . . . . . . . . . . . 7 - 3.4.1. The Subscribe Operation . . . . . . . . . . . . 7 - 3.4.2. The Notify Operation . . . . . . . . . . . . . . 8 - 3.4.3. Subscribe Operation (with Zero Duration) . . . . 8 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 5.1. The PRES URI Scheme . . . . . . . . . . . . . . . . . . 9 - 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 - 7.2. Informative References . . . . . . . . . . . . . . . . . 11 - - - -Peterson Standards Track [Page 1] - -RFC 3859 Common Profile for Presence August 2004 - - - A. PRES URI IANA Registration Template . . . . . . . . . . . . . 12 - A.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . 12 - A.2. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . 12 - A.3. Character Encoding Considerations . . . . . . . . . . . 12 - A.4. Intended Usage . . . . . . . . . . . . . . . . . . . . . 12 - A.5. Applications and/or Protocols which use this URI Scheme - Name . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - A.6. Interoperability Considerations . . . . . . . . . . . . 13 - A.7. Security Considerations . . . . . . . . . . . . . . . . 13 - A.8. Relevant Publications . . . . . . . . . . . . . . . . . 13 - A.9. Person & Email Address to Contact for Further - Information. . . . . . . . . . . . . . . . . . . . . . . 13 - A.10. Author/Change Controller . . . . . . . . . . . . . . . . 13 - A.11. Applications and/or Protocols which use this URI Scheme - Name . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - B. Issues of Interest . . . . . . . . . . . . . . . . . . . . . . 13 - B.1. Address Mapping . . . . . . . . . . . . . . . . . . . . 13 - B.2. Source-Route Mapping . . . . . . . . . . . . . . . . . . 13 - C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 15 - -1. Introduction - - Presence is defined in RFC2778 [5]. At the time this document was - written, numerous presence protocols are 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 semantics and data formats for - common services of presence to facilitate the creation of gateways - between presence services: a common profile for presence (CPP). - - Service behavior is described abstractly in terms of operations - invoked between the consumer and provider of a service. Accordingly, - each presence service must specify how this behavior is mapped onto - its own protocol interactions. The choice of strategy is a local - matter, providing that there is a clear relation between the abstract - behaviors of the service (as specified in this memo) and how it is - faithfully realized by a particular presence service. For example, - one strategy might transmit presence information as key/value pairs, - another might use a compact binary representation, and a third might - use nested containers. - - The parameters for each operation are defined using an abstract - syntax. Although the syntax specifies the range of possible data - values, each presence service must specify how well-formed instances - of the abstract representation are encoded as a concrete series of - bits. - - - -Peterson Standards Track [Page 2] - -RFC 3859 Common Profile for Presence August 2004 - - - In order to provide a means for the preservation of end-to-end - features (especially security) to pass through presence - interoperability gateways, this specification also provides - recommendations for presence document formats that could be employed - by presence protocols. - -2. Terminology - - In this document, the key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT - RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as - described in BCP 14, RFC 2119 [1] and indicate requirement levels for - compliant implementations. - - This memos makes use of the vocabulary defined in RFC 2778 [5]. - Terms such as CLOSED, INSTANT INBOX, PRESENCE, and OPEN are used in - the same meaning as defined therein. - - The term 'gateway' used in this document denotes a network element - responsible for interworking between diverse presence protocols. - Although the presence protocols themselves are diverse, under the - model in this document these protocols can carry a common payload - that is relayed by the gateway. Whether these interworking - intermediaries should be called 'gateways' or 'relays' is therefore - somewhat debatable; for the purposes of this document, they are - called 'CPP gateways'. - - The term 'presence service' also derives from RFC 2778, but its - meaning changes slightly due to the existence of gateways in the CPP - model. When a client sends an operation to a presence service, that - service might either be an endpoint or an intermediary such as a CPP - gateway - in fact, the client should not have to be aware which it is - addressing, as responses from either will appear the same. - - This document defines operations and attributes of an abstract - presence protocol. In order for a compliant protocol to interface - with a presence gateway, it must support all of the operations - described in this document (i.e., the presence protocol must have - some message or capability that provides the function described by - all given operations). Similarly, the attributes defined for these - operations must correspond to information available in the presence - protocol in order for the protocol to interface with gateways defined - by this specification. Note that these attributes provide only the - minimum possible information that needs to be specified for - interoperability - the functions in a presence protocol that - correspond to the operations described in this document can contain - additional information that will not be mapped by CPP. - - - - -Peterson Standards Track [Page 3] - -RFC 3859 Common Profile for Presence August 2004 - - -3. Abstract Presence Service - -3.1. Overview of the Presence Service - - When an application wants to subscriber to the presence information - associated with a PRESENTITY (in order to receive periodic - notifications of presence information), it invokes the subscribe - operation, e.g., - - +-------+ +-------+ - | | | | - | appl. | -- subscribe ----> | pres. | - | | | svc. | - +-------+ +-------+ - - The subscribe operation has the following attributes: watcher, - target, duration, SubscriptID and TransID. The 'watcher' and - 'target' identify the WATCHER and PRESENTITY, respectively, using the - identifiers described in Section 3.2. The duration specifies the - maximum number of seconds that the SUBSCRIPTION should be active - (which may be zero, in which case this is a one-time request for - presence information). The SubscriptID creates a reference to the - SUBSCRIPTION that is used when unsubscribing. The TransID is a - unique identifier used to correlate the subscribe operation with a - response operation. Gateways should be capable of handling TransIDs - and SubscriptIDs up to 40 bytes in length. - - Upon receiving a subscribe operation, the service immediately - responds by invoking the response operation containing the same - TransID, e.g., - - +-------+ +-------+ - | | | | - | appl. | <----- response -- | pres. | - | | | svc. | - +-------+ +-------+ - - The response operation has the following attributes: status, TransID, - and duration. 'status' indicates whether the subscribe operation has - succeeded or failed. The TransID of the response operation - corresponds to the TransID of the subscription operation to which it - is responding. The 'duration' attribute specifies the number of - seconds for which the subscription will be active (which may differ - from the value requested in the subscribe operation). - - - - - - - -Peterson Standards Track [Page 4] - -RFC 3859 Common Profile for Presence August 2004 - - - If the response operation indicates success, the service immediately - invokes the notify operation to communicate the presence information - to the WATCHER, e.g., - - +-------+ +-------+ - | | | | - | appl. | <------- notify -- | pres. | - | | | svc. | - +-------+ +-------+ - - The notify operation has the following attributes: watcher, target, - and TransID. The values of 'watcher' and 'target' are identical to - those given in the subscribe operation that triggered this notify - operation. The TransID is a unique identifier for this notification. - - The notify operation also has content, namely PRESENCE INFORMATION. - Content details are specified in Section 3.3. - - If the duration parameter is non-zero, then for up to the specified - duration, the service invokes the notify operation whenever there are - any changes to the PRESENTITY's presence information. Otherwise, - exactly one notify operation is invoked, achieving a one-time poll of - the presence information. Regardless, there is no application - response to the notify operation (i.e., the application does not - invoke a response operation when a notify operation occurs) defined - in CPP. - - The application may prematurely cancel a subscription by re-invoking - the subscribe operation (as described above) with a duration of 0 and - the same SubscriptID as the original subscribe operation , e.g., - - +-------+ +-------+ - | | | | - | appl. | -- subscribe 0 --> | pres. | - | | | svc. | - +-------+ +-------+ - - Note that a notify operation will be invoked when a subscription is - prematurely canceled in this fashion; this notification may be - discarded by the watcher. - - - - - - - - - - - -Peterson Standards Track [Page 5] - -RFC 3859 Common Profile for Presence August 2004 - - - The service immediately responds by invoking the response operation - containing the same TransID; e.g., - - +-------+ +-------+ - | | | | - | appl. | <----- response -- | pres. | - | | | svc. | - +-------+ +-------+ - - Note that this specification assumes that CPP-compliant presence - protocols provide reliable message delivery; there are no - application-layer message delivery assurance provisions in this - specification. - -3.2. Identification of PRESENTITIES and WATCHERS - - A PRESENTITY is specified using the PRES URI scheme, which is further - described in Appendix A. An example would be: - "pres:fred@example.com" - - WATCHERs identify themselves in the same manner as PRESENTITIES; that - is, with a pres URI. - -3.2.1. Address Resolution - - A presence service client determines the next hop to forward an - operation to by resolving the domain name portion of the service - destination. Compliant implementations SHOULD follow the guidelines - for dereferencing URIs given in [2]. - -3.3. Format of Presence Information - - This specification defines an abstract interoperability mechanism for - presence protocols; the message content definition given here - pertains to semantics rather than syntax. However, some important - properties for interoperability can only be provided if a common - end-to-end format for presence is employed by the interoperating - presence protocols, especially with respect to security. In order to - maintain end-to-end security properties, applications that send - notification operations through a CPP gateway MUST support the format - defined in PIDF [4]. Applications MAY support other content formats. - - CPP gateways MUST be capable of relaying the body of a notification - operation between supported presence protocols without needing to - modify or inspect the content. - - - - - - -Peterson Standards Track [Page 6] - -RFC 3859 Common Profile for Presence August 2004 - - -3.4. The Presence Service - - An implementation of the service must maintain information about both - presence information and continual operations (like periodic - notification) in persistent storage. - - Note that the subscription-identifier attribute used by the subscribe - operation is potentially long-lived. Accordingly, the values - generated for this parameter should be unique across a significant - duration of time. The SubscriptID parameter should be intrinsically - globally unique over time, not merely unique among operations sent to - or from a particular WATCHER and PRESENTITY. - -3.4.1. The Subscribe Operation - - When an application wants to subscribe to the presence information - associated with a PRESENTITY, it invokes the subscribe operation. - - When the service is informed of the subscribe operation, it performs - these steps: - - 1. If the watcher or target parameter does not refer to a valid - PRESENTITY, a response operation having status "failure" is - invoked. - - 2. If access control does not permit the application to request this - operation, a response operation having status "failure" is - invoked. - - 3. If the duration parameter is non-zero, and if the watcher and - target parameters refer to an in-progress subscribe operation for - the application, a response operation having status "failure" is - invoked. - - 4. Otherwise, if the service is able to successfully deliver the - message: - - A response operation having status "success" is immediately - invoked. (If the service chooses a different duration for the - subscription then it conveys this information in the response - operation.) - - A notify operation, corresponding to the target's presence - information, is immediately invoked for the watcher. - - - - - - - -Peterson Standards Track [Page 7] - -RFC 3859 Common Profile for Presence August 2004 - - - For up to the amount of time indicated by the duration - parameter of the notify operation (measured from the time that - the subscribe operation was received), if the target's presence - information changes, and if access control allows, a notify - operation is invoked for the watcher. - - Note that if the duration parameter is zero-valued, then the - subscribe operation is making a one-time poll of the presence - information. Accordingly, the final step above (continued - notifications for the duration of the subscription) does not occur. - - When the service invokes a response operation as a result of this - processing, the transID parameter is identical to the value found in - the subscribe operation invoked by the application. - -3.4.2. The Notify Operation - - The service invokes the notify operation whenever the presence - information associated with a PRESENTITY changes and there are - subscribers requesting notifications for that PRESENTITY. - - There is no application response to the notify operation. - -3.4.3. Subscribe Operation (with Zero Duration) - - When an application wants to terminate a subscription, it issues a - SUBSCRIBE 0 with the SubscriptID of an existing subscription. Note - that a notify operation will be invoked by the presentity when a - subscription is canceled in this fashion; this notification can be - discarded by the watcher. There is no independent UNSUBSCRIBE - operation. - - When an application wants to directly request presence information to - be supplied immediately without initiating any persistent - subscription, it issues a SUBSCRIBE 0 with a new SubscriptID. There - is no independent FETCH operation. - -4. Security Considerations - - Detailed security considerations for presence protocols given in RFC - 2779 [6] (in particular, requirements are given in sections 5.1 - through 5.3 with some motivating discussion in 8.2). - - CPP defines an interoperability function that is employed by gateways - between presence protocols. CPP gateways MUST be compliant with the - minimum security requirements of the presence protocols with which - they interface. - - - - -Peterson Standards Track [Page 8] - -RFC 3859 Common Profile for Presence August 2004 - - - The introduction of gateways to the security model of presence in RFC - 2779 also introduces some new risks. End-to-end security properties - (especially confidentiality and integrity) between presentities and - watchers that interface through a CPP gateway can only be provided if - a common presence format (such as the format described in [4]) is - supported by the protocols interfacing with the CPP gateway. - - When end-to-end security is required, the notify operation MUST use - PIDF, and MUST secure the PIDF MIME body with S/MIME [8], with - encryption (CMS EnvelopeData) and/or S/MIME signatures (CMS - SignedData). - - The S/MIME algorithms are set by CMS [9]. The AES [11] algorithm - should be preferred, as it is expected that AES best suits the - capabilities of many platforms. Implementations MAY use AES as an - encryption algorithm, but are REQUIRED to support only the baseline - algorithms mandated by S/MIME and CMS. - - When PRES URIs are used in presence protocols, they convey the - identity of watchers and/or presentities. Certificates that are used - for S/MIME presence operations SHOULD, for the purposes of reference - integrity, contain a subjectAltName field containing the PRES URI of - their subject. Note that such certificates may also contain other - identifiers, including those specific to particular presence - protocols. In order to further facilitate interoperability of secure - presence services through CPP gateways, users and service providers - are encouraged to employ trust anchors for certificates that are - widely accepted rather than trust anchors specific to any particular - presence service or provider. - - In some cases, anonymous presence services may be desired. Such a - capability is beyond the scope of this specification. - -5. IANA Considerations - - The IANA has assigned the "pres" URI scheme. - -5.1. The PRES URI Scheme - - The Presence (PRES) URI scheme designates an Internet resource, - namely a PRESENTITY or WATCHER. - - The syntax of a PRES URI is given in Appendix A. - - - - - - - - -Peterson Standards Track [Page 9] - -RFC 3859 Common Profile for Presence August 2004 - - -6. Contributors - - Dave Crocker edited earlier versions of this document. - - The following individuals made substantial textual contributions to - this document: - - Athanassios Diacakis (thanos.diacakis@openwave.com) - - Florencio Mazzoldi (flo@networkprojects.com) - - Christian Huitema (huitema@microsoft.com) - - Graham Klyne (gk@ninebynine.org) - - Jonathan Rosenberg (jdrosen@dynamicsoft.com) - - Robert Sparks (rsparks@dynamicsoft.com) - - Hiroyasu Sugano (suga@flab.fujitsu.co.jp) - -7. References - -7.1. Normative References - - [1] Bradner, S., "Key words for use in RFCs to indicate requirement - levels", BCP 14, RFC 2119, March 1997. - - [2] Peterson, J., "Address Resolution for Instant Messaging and - Presence", RFC 3861, August 2004. - - [3] Resnick, P., "Internet Message Format", STD 11, RFC 2822, April - 2001. - - [4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and - J. Peterson, "Presence Information Data Format (PIDF)", RFC - 3863, August 2004. - - [5] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and - Instant Messaging", RFC 2778, February 2000. - - [6] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging / - Presence Protocol Requirements", RFC 2779, February 2000. - - [7] Allocchio, C., "GSTN Address Element Extensions in Email - Services", RFC 2846, June 2000. - - - - - -Peterson Standards Track [Page 10] - -RFC 3859 Common Profile for Presence August 2004 - - - [8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions - (S/MIME) Version 3.1 Message Specification", RFC 3851, July - 2004. - - [9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, - July 2004. - - [10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifiers (URI): Generic Syntax", RFC 2396, August - 1998. - -7.2. Informative References - - [11] Schaad, J., "Use of the Advanced Encryption Standard (AES) - Encryption Algorithm and in Cryptographic Message Syntax (CMS)", - RFC 3565, July 2003. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Peterson Standards Track [Page 11] - -RFC 3859 Common Profile for Presence August 2004 - - -Appendix A. PRES URI IANA Registration Template - - This section provides the information to register the pres: presence - URI . - -A.1. URI Scheme Name - - pres - -A.2. URI Scheme Syntax - - The syntax follows the existing mailto: URI syntax specified in RFC - 2368. The ABNF is: - - PRES-URI = "pres:" [ to ] [ headers ] - to = mailbox - headers = "?" header *( "&" header ) - header = hname "=" hvalue - hname = *uric - hvalue = *uric - - Here the symbol "mailbox" represents an encoded mailbox name as - defined in RFC 2822 [3], and the symbol "uric" denotes any character - that is valid in a URL (defined in RFC 2396 [10]). - -A.3. Character Encoding Considerations - - Representation of non-ASCII character sets in local-part strings is - limited to the standard methods provided as extensions to RFC 2822 - [3]. - -A.4. Intended Usage - - Use of the pres: URI follows closely usage of the mailto: URI. That - is, invocation of an PRES URI will cause the user's instant messaging - application to start, with destination address and message headers - fill-in according to the information supplied in the URI. - -A.5. Applications and/or Protocols which use this URI Scheme Name - - It is anticipated that protocols compliant with RFC 2779, and meeting - the interoperability requirements specified here, will make use of - this URI scheme name. - - - - - - - - -Peterson Standards Track [Page 12] - -RFC 3859 Common Profile for Presence August 2004 - - -A.6. Interoperability Considerations - - The underlying exchange protocol used to send an instant message may - vary from service to service. Therefore complete, Internet-scale - interoperability cannot be guaranteed. However, a service conforming - to this specification permits gateways to achieve interoperability - sufficient to the requirements of RFC 2779. - -A.7. Security Considerations - - See Section 4. - -A.8. Relevant Publications - - RFC 2779, RFC 2778 - -A.9. Person & Email Address to Contact for Further Information - - Jon Peterson [mailto:jon.peterson@neustar.biz] - -A.10. Author/Change Controller - - This scheme is registered under the IETF tree. As such, IETF - maintains change control. - -A.11. Applications and/or Protocols which use this URI Scheme Name - - Instant messaging service; presence service - -Appendix B. Issues of Interest - - This appendix briefly discusses issues that may be of interest when - designing an interoperation gateway. - -B.1. Address Mapping - - When mapping the service described in this memo, mappings that place - special information into the im: address local-part MUST use the - meta-syntax defined in RFC2846 [7]. - -B.2. Source-Route Mapping - - The easiest mapping technique is a form of source-routing and usually - is the least friendly to humans having to type the string. Source- - routing also has a history of operational problems. - - - - - - -Peterson Standards Track [Page 13] - -RFC 3859 Common Profile for Presence August 2004 - - - Use of source-routing for exchanges between different services is by - a transformation that places the entire, original address string into - the im: address local part and names the gateway in the domain part. - - For example, if the destination INSTANT INBOX is "pepp://example.com/ - fred", then, after performing the necessary character conversions, - the resulting mapping is: - - im:pepp=example.com/fred@relay-domain - - where "relay-domain" is derived from local configuration information. - - Experience shows that it is vastly preferable to hide this mapping - from end-users - if possible, the underlying software should perform - the mapping automatically. - -Appendix C. Acknowledgments - - The author would like to acknowledge John Ramsdell for his comments, - suggestions and enthusiasm. Thanks to Derek Atkins for editorial - fixes. - -Author's Address - - Jon Peterson - NeuStar, Inc. - 1800 Sutter St - Suite 570 - Concord, CA 94520 - US - - Phone: +1 925/363-8720 - EMail: jon.peterson@neustar.biz - - - - - - - - - - - - - - - - - - -Peterson Standards Track [Page 14] - -RFC 3859 Common Profile for Presence August 2004 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - -Peterson Standards Track [Page 15] - diff --git a/etc/rfc3860.txt b/etc/rfc3860.txt deleted file mode 100644 index 5b097cd..0000000 --- a/etc/rfc3860.txt +++ /dev/null @@ -1,731 +0,0 @@ - - - - - - -Network Working Group J. Peterson -Request for Comments: 3860 NeuStar -Category: Standards Track August 2004 - - - Common Profile for Instant Messaging (CPIM) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2004). - -Abstract - - 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. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Abstract Instant Messaging Service . . . . . . . . . . . . . . 4 - 3.1. Overview of Instant Messaging Service . . . . . . . . . 4 - 3.2. Identification of INSTANT INBOXes . . . . . . . . . . . 5 - 3.2.1. Address Resolution . . . . . . . . . . . . . . . 5 - 3.3. Format of Instant Messages . . . . . . . . . . . . . . . 5 - 3.4. The Messaging Service . . . . . . . . . . . . . . . . . 5 - 3.4.1. The Message Operation . . . . . . . . . . . . . 5 - 3.4.2. Looping . . . . . . . . . . . . . . . . . . . . 6 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 5.1. The IM URI Scheme. . . . . . . . . . . . . . . . . . . . 8 - 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 - 7.2. Informative References . . . . . . . . . . . . . . . . . 9 - - - - -Peterson Standards Track [Page 1] - -RFC 3860 CPIM August 2004 - - - A. IM URI IANA Registration Template . . . . . . . . . . . . . . 10 - A.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . 10 - A.2. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . 10 - A.3. Character Encoding Considerations . . . . . . . . . . . 10 - A.4. Intended Usage . . . . . . . . . . . . . . . . . . . . . 10 - A.5. Applications and/or Protocols which use this URI Scheme - Name . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - A.6. Security Considerations . . . . . . . . . . . . . . . . 10 - A.7. Relevant Publications . . . . . . . . . . . . . . . . . 11 - A.8. Person & Email Address to Contact for Further - Information. . . . . . . . . . . . . . . . . . . . . . . 11 - A.9. Author/Change Controller . . . . . . . . . . . . . . . . 11 - A.10. Applications and/or Protocols which use this URI Scheme - Name . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - B. Issues of Interest . . . . . . . . . . . . . . . . . . . . . . 11 - B.1. Address Mapping . . . . . . . . . . . . . . . . . . . . 11 - B.2. Source-Route Mapping . . . . . . . . . . . . . . . . . . 11 - C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13 - -1. Introduction - - Instant messaging is defined in RFC2778 [5]. At the time this - document was written, numerous instant messaging protocols are in - use, and little interoperability between services based on these - protocols has been achieved. This specification defines semantics - and data formats for common services of instant messaging to - facilitate the creation of gateways between instant messaging - services: a common profile for instant messaging (CPIM). - - Service behavior is described abstractly in terms of operations - invoked between the consumer and provider of a service. Accordingly, - each IM service must specify how this behavior is mapped onto its own - protocol interactions. The choice of strategy is a local matter, - providing that there is a clear relation between the abstract - behaviors of the service (as specified in this memo) and how it is - faithfully realized by a particular instant messaging service. For - example, one strategy might transmit an instant message as textual - key/value pairs, another might use a compact binary representation, - and a third might use nested containers. - - The attributes for each operation are defined using an abstract - syntax. Although the syntax specifies the range of possible data - values, each IM service must specify how well-formed instances of the - abstract representation are encoded as a concrete series of bits. - - - - - -Peterson Standards Track [Page 2] - -RFC 3860 CPIM August 2004 - - - In order to provide a means for the preservation of end-to-end - features (especially security) to pass through instant messaging - interoperability gateways, this specification also provides - recommendations for instant messaging document formats that could be - employed by instant messaging protocols. - -2. Terminology - - In this document, the key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT - RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as - described in RFC 2119 [1] and indicate requirement levels for - compliant implementations. - - This memos makes use of the vocabulary defined in RFC 2778 [5]. - Terms such as CLOSED, INSTANT INBOX, INSTANT MESSAGE, and OPEN are - used in the same meaning as defined therein. - - The term 'gateway' used in this document denotes a network element - responsible for interworking between diverse instant messaging - protocols. Although the instant messaging protocols themselves are - diverse, under the model used in this document these protocols can - carry a common payload that is relayed by the gateway. Whether these - interworking intermediaries should be called 'gateways' or 'relays' - is therefore somewhat debatable; for the purposes of this document, - they are called 'CPIM gateways'. - - The term 'instant messaging service' also derives from RFC 2778, but - its meaning changes slightly due to the existence of gateways in the - CPIM model. When a client sends an operation to an instant messaging - service, that service might either be an endpoint or an intermediary - such as a CPIM gateway - in fact, the client should not have to be - aware which it is addressing, as responses from either will appear - the same. - - This document defines operations and attributes of an abstract - instant messaging protocol. In order for a compliant protocol to - interface with an instant messaging gateway, it must support all of - the operations described in this document (i.e., the instant - messaging protocol must have some message or capability that provides - the function described by each of the given operations). Similarly, - the attributes defined for these operations must correspond to - information available in the instant messaging protocol in order for - the protocol to interface with gateways defined by this - specification. Note that these attributes provide only the minimum - possible information that needs to be specified for interoperability - - - - - -Peterson Standards Track [Page 3] - -RFC 3860 CPIM August 2004 - - - - the functions in an instant messaging protocol that correspond to - the operations described in this document can contain additional - information that will not be mapped by CPIM. - -3. Abstract Instant Messaging Service - -3.1. Overview of Instant Messaging Service - - When an application wants to send a message to an INSTANT INBOX, it - invokes the message operation, e.g., - - +-------+ +-------+ - | | | | - | appl. | -- message ------> | IM | - | | | svc. | - +-------+ +-------+ - - The message operation has the following attributes: source, - destination, MaxForwards and TransID. 'source' and 'destination' - identify the originator and recipient of an instant message, - respectively, and consist of an INSTANT INBOX identifier (as - described in Section 3.2). The MaxForwards is a hop counter to avoid - loops through gateways, with usage detailed defined in Section 3.4.2; - its initial value is set by the originator. The TransID is a unique - identifier used to correlate message operations to response - operations; gateways should be capable of handling TransIDs up to 40 - bytes in length. - - The message operation also has some content, the instant message - itself, which may be textual, or which may consist of other data. - Content details are specified in Section 3.3. - - Note that this specification assumes that instant messaging protocols - provide reliable message delivery; there are no application-layer - message delivery assurance provisions in this specification. - - Upon receiving a message operation, the service immediately responds - by invoking the response operation containing the same transaction- - identifier, e.g., - - +-------+ +-------+ - | | | | - | appl. | <----- response -- | IM | - | | | svc. | - +-------+ +-------+ - - - - - - -Peterson Standards Track [Page 4] - -RFC 3860 CPIM August 2004 - - - The response operation contains the following attributes: TransID and - status. The TransID is used to correlate the response to a - particular instant message. Status indicates whether the delivery of - the message succeeded or failed. Valid status values are described - in Section 3.4.1. - -3.2. Identification of INSTANT INBOXes - - An INSTANT INBOX is specified using an instant messaging URI with the - 'im:' URI scheme. The full syntax of the IM URI scheme is given in - Appendix A. An example would be: "im:fred@example.com" - -3.2.1. Address Resolution - - An IM service client determines the next hop to forward the IM to by - resolving the domain name portion of the service destination. - Compliant implementations SHOULD follow the guidelines for - dereferencing URIs given in [2]. - -3.3. Format of Instant Messages - - This specification defines an abstract interoperability mechanism for - instant messaging protocols; the message content definition given - here pertains to semantics rather than syntax. However, some - important properties for interoperability can only be provided if a - common end-to-end format for instant messaging is employed by the - interoperating instant messaging protocols, especially with respect - to security. In order to maintain end-to-end security properties, - applications that send message operations to a CPIM gateway MUST - implement the format defined in MSGFMT [4]. Applications MAY support - other content formats. - - CPIM gateways MUST be capable of relaying the content of a message - operation between supported instant messaging protocols without - needing to modify or inspect the content. - -3.4. The Messaging Service - -3.4.1. The Message Operation - - When an application wants to send an INSTANT MESSAGE, it invokes the - message operation. - - - - - - - - - -Peterson Standards Track [Page 5] - -RFC 3860 CPIM August 2004 - - - When an instant messaging service receives the message operation, it - performs the following preliminary checks: - - 1. If the source or destination does not refer to a syntactically - valid INSTANT INBOX, a response operation having status "failure" - is invoked. - - 2. If the destination of the operation cannot be resolved by the - recipient, and the recipient is not the final recipient, a - response operation with the status "failure" is invoked. - - 3. If access control does not permit the application to request this - operation, a response operation having status "failure" is - invoked. - - 4. Provided these checks are successful: - - If the instant messaging service is able to successfully - deliver the message, a response operation having status - "success" is invoked. - - If the service is unable to successfully deliver the message, - a response operation having status "failure" is invoked. - - If the service must delegate responsibility for delivery - (i.e., if it is acting as a gateway or proxying the - operation), and if the delegation will not result in a future - authoritative indication to the service, a response operation - having status "indeterminant" is invoked. - - If the service must delegate responsibility for delivery, and - if the delegation will result in a future authoritative - indication to the service, then a response operation is - invoked immediately after the indication is received. - - When the service invokes the response operation, the transID - parameter is identical to the value found in the message operation - invoked by the application. - -3.4.2. Looping - - The dynamic routing of instant messages can result in looping of a - message through a relay. Detection of loops is not always obvious, - since aliasing and group list expansions can legitimately cause a - message to pass through a relay more than one time. - - - - - - -Peterson Standards Track [Page 6] - -RFC 3860 CPIM August 2004 - - - This document assumes that instant messaging protocols that can be - gatewayed by CPIM support some semantic equivalent to an integer - value that indicates the maximum number of hops through which a - message can pass. When that number of hops has been reached, the - message is assumed to have looped. - - When a CPIM gateway relays an instant message, it decrements the - value of the MaxForwards attribute. This document does not mandate - any particular initial setting for the MaxForwards element in instant - messaging protocols, but it is recommended that the value be - reasonably large (over one hundred). - - If a CPIM gateway receives an instant message operation that has a - MaxForwards attribute of 0, it discards the message and invokes a - failure operation. - -4. Security Considerations - - Detailed security considerations for instant messaging protocols are - given in RFC 2779 [6] (in particular, requirements are given in - section 5.4 and some motivating discussion with 8.1). - - CPIM defines an interoperability function that is employed by - gateways between instant messaging protocols. CPIM gateways MUST be - compliant with the minimum security requirements of the instant - messaging protocols with which they interface. - - The introduction of gateways to the security model of instant - messaging in RFC 2779 also introduces some new risks. End-to-end - security properties (especially confidentiality and integrity) - between instant messaging user agents that interface through a CPIM - gateway can only be provided if a common instant message format (such - as the format described in MSGFMT [4]) is supported by the protocols - interfacing with the CPIM gateway. - - When end-to-end security is required, the message operation MUST use - MSGFMT, and MUST secure the MSGFMT MIME body with S/MIME [8], with - encryption (CMS EnvelopeData) and/or S/MIME signatures (CMS - SignedData). - - The S/MIME algorithms are set by CMS [9]. The AES [11] algorithm - should be preferred, as it is expected that AES best suits the - capabilities of many platforms. Implementations MAY use AES as an - encryption algorithm, but are REQUIRED to support only the baseline - algorithms mandated by S/MIME and CMS. - - - - - - -Peterson Standards Track [Page 7] - -RFC 3860 CPIM August 2004 - - - When IM URIs are placed in instant messaging protocols, they convey - the identity of the sender and/or the recipient. Certificates that - are used for S/MIME IM operations SHOULD, for the purposes of - reference integrity, contain a subjectAltName field containing the IM - URI of their subject. Note that such certificates may also contain - other identifiers, including those specific to particular instant - messaging protocols. In order to further facilitate interoperability - of secure messaging through CPIM gateways, users and service - providers are encouraged to employ trust anchors for certificates - that are widely accepted rather than trust anchors specific to any - particular instant messaging service or provider. - - In some cases, anonymous messaging may be desired. Such a capability - is beyond the scope of this specification. - -5. IANA Considerations - - The IANA has assigned the "im" scheme. - -5.1. The IM URI Scheme - - The Instant Messaging (IM) URI scheme designates an Internet - resource, namely an INSTANT INBOX. - - The syntax of an IM URI is given in Appendix A. - -6. Contributors - - Dave Crocker edited earlier versions of this document. - - The following individuals made substantial textual contributions to - this document: - - Athanassios Diacakis (thanos.diacakis@openwave.com) - - Florencio Mazzoldi (flo@networkprojects.com) - - Christian Huitema (huitema@microsoft.com) - - Graham Klyne (gk@ninebynine.org) - - Jonathan Rosenberg (jdrosen@dynamicsoft.com) - - Robert Sparks (rsparks@dynamicsoft.com) - - Hiroyasu Sugano (suga@flab.fujitsu.co.jp) - - - - - -Peterson Standards Track [Page 8] - -RFC 3860 CPIM August 2004 - - -7. References - -7.1. Normative References - - [1] Bradner, S., "Key words for use in RFCs to indicate requirement - levels", BCP 14, RFC 2119, March 1997. - - [2] Peterson, J., "Address Resolution for Instant Messaging and - Presence", RFC 3861, August 2004. - - [3] Resnick, P., "Internet Message Format", STD 11, RFC 2822, April - 2001. - - [4] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging: - Message Format", RFC 3862, August 2004. - - [5] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and - Instant Messaging", RFC 2778, February 2000. - - [6] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging / - Presence Protocol Requirements", RFC 2779, February 2000. - - [7] Allocchio, C., "GSTN Address Element Extensions in Email - Services", RFC 2846, June 2000. - - [8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions - (S/MIME) Version 3.1 Message Specification", RFC 3851, July - 2004. - - [9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, - July 2004. - - [10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifiers (URI): Generic Syntax", RFC 2396, August - 1998. - -7.2. Informative References - - [11] Schaad, J., "Use of the Advanced Encryption Standard (AES) - Encryption Algorithm and in Cryptographic Message Syntax (CMS)", - RFC 3565, August 2003. - - - - - - - - - - -Peterson Standards Track [Page 9] - -RFC 3860 CPIM August 2004 - - -Appendix A. IM URI IANA Registration Template - - This section provides the information to register the im: instant - messaging URI. - -A.1. URI Scheme Name - - im - -A.2. URI Scheme Syntax - - The syntax follows the existing mailto: URI syntax specified in RFC - 2368. The ABNF is: - - IM-URI = "im:" [ to ] [ headers ] - to = mailbox - headers = "?" header *( "&" header ) - header = hname "=" hvalue - hname = *uric - hvalue = *uric - - Here the symbol "mailbox" represents an encoded mailbox name as - defined in RFC 2822 [3], and the symbol "uric" denotes any character - that is valid in a URL (defined in RFC 2396 [10]). - -A.3. Character Encoding Considerations - - Representation of non-ASCII character sets in local-part strings is - limited to the standard methods provided as extensions to RFC 2822 - [3]. - -A.4. Intended Usage - - Use of the im: URI follows closely usage of the mailto: URI. That - is, invocation of an IM URI will cause the user's instant messaging - application to start, with destination address and message headers - fill-in according to the information supplied in the URI. - -A.5. Applications and/or Protocols which use this URI Scheme Name - - It is anticipated that protocols compliant with RFC 2779, and meeting - the interoperability requirements specified here, will make use of - this URI scheme name. - -A.6. Security Considerations - - See Section 4. - - - - -Peterson Standards Track [Page 10] - -RFC 3860 CPIM August 2004 - - -A.7. Relevant Publications - - RFC 2779, RFC 2778 - -A.8. Person & Email Address to Contact for Further Information - - Jon Peterson [mailto:jon.peterson@neustar.biz] - -A.9. Author/Change Controller - - This scheme is registered under the IETF tree. As such, IETF - maintains change control. - -A.10. Applications and/or Protocols which use this URI Scheme Name - - Instant messaging service - -Appendix B. Issues of Interest - - This appendix briefly discusses issues that may be of interest when - designing an interoperation gateway. - -B.1. Address Mapping - - When mapping the service described in this memo, mappings that place - special information into the im: address local-part MUST use the - meta-syntax defined in RFC 2846 [7]. - -B.2. Source-Route Mapping - - The easiest mapping technique is a form of source-routing and usually - is the least friendly to humans having to type the string. Source- - routing also has a history of operational problems. - - Use of source-routing for exchanges between different services is by - a transformation that places the entire, original address string into - the im: address local part and names the gateway in the domain part. - - For example, if the destination INSTANT INBOX is "pepp://example.com/ - fred", then, after performing the necessary character conversions, - the resulting mapping is: - - im:pepp=example.com/fred@relay-domain - - where "relay-domain" is derived from local configuration information. - - - - - - -Peterson Standards Track [Page 11] - -RFC 3860 CPIM August 2004 - - - Experience shows that it is vastly preferable to hide this mapping - from end-users - if possible, the underlying software should perform - the mapping automatically. - -Appendix C. Acknowledgments - - The author would like to acknowledge John Ramsdell for his comments, - suggestions and enthusiasm. Thanks to Derek Atkins for editorial - fixes. - -Author's Address - - Jon Peterson - NeuStar, Inc. - 1800 Sutter St - Suite 570 - Concord, CA 94520 - US - - Phone: +1 925/363-8720 - EMail: jon.peterson@neustar.biz - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Peterson Standards Track [Page 12] - -RFC 3860 CPIM August 2004 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - -Peterson Standards Track [Page 13] - diff --git a/etc/rrule.txt b/etc/rrule.txt deleted file mode 100644 index e6af51c..0000000 --- a/etc/rrule.txt +++ /dev/null @@ -1,694 +0,0 @@ -4.3.10 Recurrence Rule - - Value Name: RECUR - - Purpose: This value type is used to identify properties that contain - a recurrence rule specification. - - Formal Definition: The value type is defined by the following - notation: - - recur = "FREQ"=freq *( - - ; either UNTIL or COUNT may appear in a 'recur', - ; but UNTIL and COUNT MUST NOT occur in the same 'recur' - - ( ";" "UNTIL" "=" enddate ) / - ( ";" "COUNT" "=" 1*DIGIT ) / - - ; the rest of these keywords are optional, - ; but MUST NOT occur more than once - - ( ";" "INTERVAL" "=" 1*DIGIT ) / - ( ";" "BYSECOND" "=" byseclist ) / - ( ";" "BYMINUTE" "=" byminlist ) / - ( ";" "BYHOUR" "=" byhrlist ) / - ( ";" "BYDAY" "=" bywdaylist ) / - ( ";" "BYMONTHDAY" "=" bymodaylist ) / - ( ";" "BYYEARDAY" "=" byyrdaylist ) / - ( ";" "BYWEEKNO" "=" bywknolist ) / - ( ";" "BYMONTH" "=" bymolist ) / - ( ";" "BYSETPOS" "=" bysplist ) / - ( ";" "WKST" "=" weekday ) / - - ( ";" x-name "=" text ) - ) - - freq = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY" - / "WEEKLY" / "MONTHLY" / "YEARLY" - - enddate = date - enddate =/ date-time ;An UTC value - - byseclist = seconds / ( seconds *("," seconds) ) - - seconds = 1DIGIT / 2DIGIT ;0 to 59 - - byminlist = minutes / ( minutes *("," minutes) ) - - minutes = 1DIGIT / 2DIGIT ;0 to 59 - - byhrlist = hour / ( hour *("," hour) ) - - hour = 1DIGIT / 2DIGIT ;0 to 23 - - bywdaylist = weekdaynum / ( weekdaynum *("," weekdaynum) ) - - weekdaynum = [([plus] ordwk / minus ordwk)] weekday - - plus = "+" - - minus = "-" - - ordwk = 1DIGIT / 2DIGIT ;1 to 53 - - weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" - ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, - ;FRIDAY, SATURDAY and SUNDAY days of the week. - - bymodaylist = monthdaynum / ( monthdaynum *("," monthdaynum) ) - - monthdaynum = ([plus] ordmoday) / (minus ordmoday) - - ordmoday = 1DIGIT / 2DIGIT ;1 to 31 - - byyrdaylist = yeardaynum / ( yeardaynum *("," yeardaynum) ) - - yeardaynum = ([plus] ordyrday) / (minus ordyrday) - - ordyrday = 1DIGIT / 2DIGIT / 3DIGIT ;1 to 366 - - bywknolist = weeknum / ( weeknum *("," weeknum) ) - - weeknum = ([plus] ordwk) / (minus ordwk) - - bymolist = monthnum / ( monthnum *("," monthnum) ) - - monthnum = 1DIGIT / 2DIGIT ;1 to 12 - - bysplist = setposday / ( setposday *("," setposday) ) - - setposday = yeardaynum - - Description: If the property permits, multiple "recur" values are - specified by a COMMA character (US-ASCII decimal 44) separated list - of values. The value type is a structured value consisting of a list - of one or more recurrence grammar parts. Each rule part is defined by - a NAME=VALUE pair. The rule parts are separated from each other by - the SEMICOLON character (US-ASCII decimal 59). The rule parts are not - ordered in any particular sequence. Individual rule parts MUST only - be specified once. - - The FREQ rule part identifies the type of recurrence rule. This rule - part MUST be specified in the recurrence rule. Valid values include - SECONDLY, to specify repeating events based on an interval of a - second or more; MINUTELY, to specify repeating events based on an - interval of a minute or more; HOURLY, to specify repeating events - based on an interval of an hour or more; DAILY, to specify repeating - events based on an interval of a day or more; WEEKLY, to specify - repeating events based on an interval of a week or more; MONTHLY, to - specify repeating events based on an interval of a month or more; and - YEARLY, to specify repeating events based on an interval of a year or - more. - - The INTERVAL rule part contains a positive integer representing how - often the recurrence rule repeats. The default value is "1", meaning - every second for a SECONDLY rule, or every minute for a MINUTELY - rule, every hour for an HOURLY rule, every day for a DAILY rule, - every week for a WEEKLY rule, every month for a MONTHLY rule and - every year for a YEARLY rule. - - The UNTIL rule part defines a date-time value which bounds the - recurrence rule in an inclusive manner. If the value specified by - UNTIL is synchronized with the specified recurrence, this date or - date-time becomes the last instance of the recurrence. If specified - as a date-time value, then it MUST be specified in an UTC time - format. If not present, and the COUNT rule part is also not present, - the RRULE is considered to repeat forever. - - The COUNT rule part defines the number of occurrences at which to - range-bound the recurrence. The "DTSTART" property value, if - specified, counts as the first occurrence. - - The BYSECOND rule part specifies a COMMA character (US-ASCII decimal - 44) separated list of seconds within a minute. Valid values are 0 to - 59. The BYMINUTE rule part specifies a COMMA character (US-ASCII - decimal 44) separated list of minutes within an hour. Valid values - are 0 to 59. The BYHOUR rule part specifies a COMMA character (US- - ASCII decimal 44) separated list of hours of the day. Valid values - are 0 to 23. - - The BYDAY rule part specifies a COMMA character (US-ASCII decimal 44) - separated list of days of the week; MO indicates Monday; TU indicates - Tuesday; WE indicates Wednesday; TH indicates Thursday; FR indicates - Friday; SA indicates Saturday; SU indicates Sunday. - - Each BYDAY value can also be preceded by a positive (+n) or negative - (-n) integer. If present, this indicates the nth occurrence of the - specific day within the MONTHLY or YEARLY RRULE. For example, within - a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday - within the month, whereas -1MO represents the last Monday of the - month. If an integer modifier is not present, it means all days of - this type within the specified frequency. For example, within a - MONTHLY rule, MO represents all Mondays within the month. - - The BYMONTHDAY rule part specifies a COMMA character (ASCII decimal - 44) separated list of days of the month. Valid values are 1 to 31 or - -31 to -1. For example, -10 represents the tenth to the last day of - the month. - - The BYYEARDAY rule part specifies a COMMA character (US-ASCII decimal - 44) separated list of days of the year. Valid values are 1 to 366 or - -366 to -1. For example, -1 represents the last day of the year - (December 31st) and -306 represents the 306th to the last day of the - year (March 1st). - - The BYWEEKNO rule part specifies a COMMA character (US-ASCII decimal - 44) separated list of ordinals specifying weeks of the year. Valid - values are 1 to 53 or -53 to -1. This corresponds to weeks according - to week numbering as defined in [ISO 8601]. A week is defined as a - seven day period, starting on the day of the week defined to be the - week start (see WKST). Week number one of the calendar year is the - first week which contains at least four (4) days in that calendar - year. This rule part is only valid for YEARLY rules. For example, 3 - represents the third week of the year. - - Note: Assuming a Monday week start, week 53 can only occur when - Thursday is January 1 or if it is a leap year and Wednesday is - January 1. - - The BYMONTH rule part specifies a COMMA character (US-ASCII decimal - 44) separated list of months of the year. Valid values are 1 to 12. - - The WKST rule part specifies the day on which the workweek starts. - Valid values are MO, TU, WE, TH, FR, SA and SU. This is significant - when a WEEKLY RRULE has an interval greater than 1, and a BYDAY rule - part is specified. This is also significant when in a YEARLY RRULE - when a BYWEEKNO rule part is specified. The default value is MO. - - The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal - 44) separated list of values which corresponds to the nth occurrence - within the set of events specified by the rule. Valid values are 1 to - 366 or -366 to -1. It MUST only be used in conjunction with another - BYxxx rule part. For example "the last work day of the month" could - be represented as: - - RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 - - Each BYSETPOS value can include a positive (+n) or negative (-n) - integer. If present, this indicates the nth occurrence of the - specific occurrence within the set of events specified by the rule. - - If BYxxx rule part values are found which are beyond the available - scope (ie, BYMONTHDAY=30 in February), they are simply ignored. - - Information, not contained in the rule, necessary to determine the - various recurrence instance start time and dates are derived from the - Start Time (DTSTART) entry attribute. For example, - "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the - month or a time. This information would be the same as what is - specified for DTSTART. - - BYxxx rule parts modify the recurrence in some manner. BYxxx rule - parts for a period of time which is the same or greater than the - frequency generally reduce or limit the number of occurrences of the - recurrence generated. For example, "FREQ=DAILY;BYMONTH=1" reduces the - number of recurrence instances from all days (if BYMONTH tag is not - present) to all days in January. BYxxx rule parts for a period of - time less than the frequency generally increase or expand the number - of occurrences of the recurrence. For example, - "FREQ=YEARLY;BYMONTH=1,2" increases the number of days within the - yearly recurrence set from 1 (if BYMONTH tag is not present) to 2. - - If multiple BYxxx rule parts are specified, then after evaluating the - specified FREQ and INTERVAL rule parts, the BYxxx rule parts are - applied to the current set of evaluated occurrences in the following - order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR, - BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are evaluated. - - Here is an example of evaluating multiple BYxxx rule parts. - - DTSTART;TZID=US-Eastern:19970105T083000 - RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9; - BYMINUTE=30 - - First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to arrive - at "every other year". Then, "BYMONTH=1" would be applied to arrive - at "every January, every other year". Then, "BYDAY=SU" would be - applied to arrive at "every Sunday in January, every other year". - Then, "BYHOUR=8,9" would be applied to arrive at "every Sunday in - January at 8 AM and 9 AM, every other year". Then, "BYMINUTE=30" - would be applied to arrive at "every Sunday in January at 8:30 AM and - 9:30 AM, every other year". Then, lacking information from RRULE, the - second is derived from DTSTART, to end up in "every Sunday in January - at 8:30:00 AM and 9:30:00 AM, every other year". Similarly, if the - BYMINUTE, BYHOUR, BYDAY, BYMONTHDAY or BYMONTH rule part were - missing, the appropriate minute, hour, day or month would have been - retrieved from the "DTSTART" property. - - No additional content value encoding (i.e., BACKSLASH character - encoding) is defined for this value type. - - Example: The following is a rule which specifies 10 meetings which - occur every other day: - - FREQ=DAILY;COUNT=10;INTERVAL=2 - - There are other examples specified in the "RRULE" specification. - - - - -4.8.5.4 Recurrence Rule - - Property Name: RRULE - - Purpose: This property defines a rule or repeating pattern for - recurring events, to-dos, or time zone definitions. - - Value Type: RECUR - - Property Parameters: Non-standard property parameters can be - specified on this property. - - Conformance: This property can be specified one or more times in - recurring "VEVENT", "VTODO" and "VJOURNAL" calendar components. It - can also be specified once in each STANDARD or DAYLIGHT sub-component - of the "VTIMEZONE" calendar component. - - Description: The recurrence rule, if specified, is used in computing - the recurrence set. The recurrence set is the complete set of - recurrence instances for a calendar component. The recurrence set is - generated by considering the initial "DTSTART" property along with - the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained - within the iCalendar object. The "DTSTART" property defines the first - instance in the recurrence set. Multiple instances of the "RRULE" and - "EXRULE" properties can also be specified to define more - sophisticated recurrence sets. The final recurrence set is generated - by gathering all of the start date/times generated by any of the - specified "RRULE" and "RDATE" properties, and excluding any start - date/times which fall within the union of start date/times generated - by any specified "EXRULE" and "EXDATE" properties. This implies that - start date/times within exclusion related properties (i.e., "EXDATE" - and "EXRULE") take precedence over those specified by inclusion - properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are - generated by the "RRULE" and "RDATE" properties, only one recurrence - is considered. Duplicate instances are ignored. - - The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION" - property pair, specified within the iCalendar object defines the - first instance of the recurrence. When used with a recurrence rule, - the "DTSTART" and "DTEND" properties MUST be specified in local time - and the appropriate set of "VTIMEZONE" calendar components MUST be - included. For detail on the usage of the "VTIMEZONE" calendar - component, see the "VTIMEZONE" calendar component definition. - - Any duration associated with the iCalendar object applies to all - members of the generated recurrence set. Any modified duration for - specific recurrences MUST be explicitly specified using the "RDATE" - property. - - Format Definition: This property is defined by the following - notation: - - rrule = "RRULE" rrulparam ":" recur CRLF - - rrulparam = *(";" xparam) - - Example: All examples assume the Eastern United States time zone. - -Daylight Saving Time begins for most of the United States at 2 a.m. on the -first Sunday of April. Time reverts to standard time at 2 a.m. on the last -Sunday of October. In the U.S., each time zone switches at a different time. - -In the European Union, Summer Time begins and ends at 1 am Universal Time -(Greenwich Mean Time). It starts the last Sunday in March, and ends the last -Sunday in October. In the EU, all time zones change at the same moment. - - Daily for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=DAILY;COUNT=10 - - ==> (1997 9:00 AM EDT)September 2-11 - - Daily until December 24, 1997: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=DAILY;UNTIL=19971224T000000Z - - ==> (1997 9:00 AM EDT)September 2-30;October 1-25 - (1997 9:00 AM EST)October 26-31;November 1-30;December 1-23 - - Every other day - forever: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=DAILY;INTERVAL=2 - ==> (1997 9:00 AM EDT)September2,4,6,8...24,26,28,30; - October 2,4,6...20,22,24 - (1997 9:00 AM EST)October 26,28,30;November 1,3,5,7...25,27,29; - Dec 1,3,... - - Every 10 days, 5 occurrences: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5 - - ==> (1997 9:00 AM EDT)September 2,12,22;October 2,12 - - Everyday in January, for 3 years: - - DTSTART;TZID=US-Eastern:19980101T090000 - RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z; - BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA - or - RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1 - - ==> (1998 9:00 AM EDT)January 1-31 - (1999 9:00 AM EDT)January 1-31 - (2000 9:00 AM EDT)January 1-31 - -!! (2000 9:00 AM EDT)January 31 is AFTER the until day (2000 9:00 am UTC) January 31 - - Weekly for 10 occurrences - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;COUNT=10 - - ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21 - (1997 9:00 AM EST)October 28;November 4 - - Weekly until December 24, 1997 - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z - - ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21 - (1997 9:00 AM EST)October 28;November 4,11,18,25; - December 2,9,16,23 - Every other week - forever: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU - - ==> (1997 9:00 AM EDT)September 2,16,30;October 14 - (1997 9:00 AM EST)October 28;November 11,25;December 9,23 - (1998 9:00 AM EST)January 6,20;February - ... - - Weekly on Tuesday and Thursday for 5 weeks: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH - or - - RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH - - ==> (1997 9:00 AM EDT)September 2,4,9,11,16,18,23,25,30;October 2 - - Every other week on Monday, Wednesday and Friday until December 24, - 1997, but starting on Tuesday, September 2, 1997: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU; - BYDAY=MO,WE,FR - ==> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October - 1,3,13,15,17 - (1997 9:00 AM EST)October 27,29,31;November 10,12,14,24,26,28; - December 8,10,12,22 - - Every other week on Tuesday and Thursday, for 8 occurrences: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH - - ==> (1997 9:00 AM EDT)September 2,4,16,18,30;October 2,14,16 - - Monthly on the 1st Friday for ten occurrences: - - DTSTART;TZID=US-Eastern:19970905T090000 - RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR - - ==> (1997 9:00 AM EDT)September 5;October 3 - (1997 9:00 AM EST)November 7;Dec 5 - (1998 9:00 AM EST)January 2;February 6;March 6;April 3 - (1998 9:00 AM EDT)May 1;June 5 - - Monthly on the 1st Friday until December 24, 1997: - - DTSTART;TZID=US-Eastern:19970905T090000 - RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR - - ==> (1997 9:00 AM EDT)September 5;October 3 - (1997 9:00 AM EST)November 7;December 5 - - Every other month on the 1st and last Sunday of the month for 10 - occurrences: - - DTSTART;TZID=US-Eastern:19970907T090000 - RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU - - ==> (1997 9:00 AM EDT)September 7,28 - (1997 9:00 AM EST)November 2,30 - (1998 9:00 AM EST)January 4,25;March 1,29 - (1998 9:00 AM EDT)May 3,31 - - Monthly on the second to last Monday of the month for 6 months: - - DTSTART;TZID=US-Eastern:19970922T090000 - RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO - - ==> (1997 9:00 AM EDT)September 22;October 20 - (1997 9:00 AM EST)November 17;December 22 - (1998 9:00 AM EST)January 19;February 16 - - Monthly on the third to the last day of the month, forever: - - DTSTART;TZID=US-Eastern:19970928T090000 - RRULE:FREQ=MONTHLY;BYMONTHDAY=-3 - - ==> (1997 9:00 AM EDT)September 28 - (1997 9:00 AM EST)October 29;November 28;December 29 - (1998 9:00 AM EST)January 29;February 26 - ... - - Monthly on the 2nd and 15th of the month for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15 - - ==> (1997 9:00 AM EDT)September 2,15;October 2,15 - (1997 9:00 AM EST)November 2,15;December 2,15 - (1998 9:00 AM EST)January 2,15 - - Monthly on the first and last day of the month for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970930T090000 - RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1 - - ==> (1997 9:00 AM EDT)September 30;October 1 - (1997 9:00 AM EST)October 31;November 1,30;December 1,31 - (1998 9:00 AM EST)January 1,31;February 1 - - Every 18 months on the 10th thru 15th of the month for 10 - occurrences: - - DTSTART;TZID=US-Eastern:19970910T090000 - RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14, - 15 - - ==> (1997 9:00 AM EDT)September 10,11,12,13,14,15 - (1999 9:00 AM EST)March 10,11,12,13 - - Every Tuesday, every other month: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU - - ==> (1997 9:00 AM EDT)September 2,9,16,23,30 - (1997 9:00 AM EST)November 4,11,18,25 - (1998 9:00 AM EST)January 6,13,20,27;March 3,10,17,24,31 - ... - - Yearly in June and July for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970610T090000 - RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7 - ==> (1997 9:00 AM EDT)June 10;July 10 - (1998 9:00 AM EDT)June 10;July 10 - (1999 9:00 AM EDT)June 10;July 10 - (2000 9:00 AM EDT)June 10;July 10 - (2001 9:00 AM EDT)June 10;July 10 - Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY components - are specified, the day is gotten from DTSTART - - Every other year on January, February, and March for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970310T090000 - RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3 - - ==> (1997 9:00 AM EST)March 10 - (1999 9:00 AM EST)January 10;February 10;March 10 - (2001 9:00 AM EST)January 10;February 10;March 10 - (2003 9:00 AM EST)January 10;February 10;March 10 - - Every 3rd year on the 1st, 100th and 200th day for 10 occurrences: - - DTSTART;TZID=US-Eastern:19970101T090000 - RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200 - - ==> (1997 9:00 AM EST)January 1 - (1997 9:00 AM EDT)April 10;July 19 - (2000 9:00 AM EST)January 1 - (2000 9:00 AM EDT)April 9;July 18 - (2003 9:00 AM EST)January 1 - (2003 9:00 AM EDT)April 10;July 19 - (2006 9:00 AM EST)January 1 - - Every 20th Monday of the year, forever: - DTSTART;TZID=US-Eastern:19970519T090000 - RRULE:FREQ=YEARLY;BYDAY=20MO - - ==> (1997 9:00 AM EDT)May 19 - (1998 9:00 AM EDT)May 18 - (1999 9:00 AM EDT)May 17 - ... - - Monday of week number 20 (where the default start of the week is - Monday), forever: - - DTSTART;TZID=US-Eastern:19970512T090000 - RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO - - ==> (1997 9:00 AM EDT)May 12 - (1998 9:00 AM EDT)May 11 - (1999 9:00 AM EDT)May 17 - ... - - Every Thursday in March, forever: - - DTSTART;TZID=US-Eastern:19970313T090000 - RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH - - ==> (1997 9:00 AM EST)March 13,20,27 - (1998 9:00 AM EST)March 5,12,19,26 - (1999 9:00 AM EST)March 4,11,18,25 - ... - - Every Thursday, but only during June, July, and August, forever: - - DTSTART;TZID=US-Eastern:19970605T090000 - RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8 - - ==> (1997 9:00 AM EDT)June 5,12,19,26;July 3,10,17,24,31; - August 7,14,21,28 - (1998 9:00 AM EDT)June 4,11,18,25;July 2,9,16,23,30; - August 6,13,20,27 - (1999 9:00 AM EDT)June 3,10,17,24;July 1,8,15,22,29; - August 5,12,19,26 - ... - - Every Friday the 13th, forever: - - DTSTART;TZID=US-Eastern:19970902T090000 - EXDATE;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13 - ==> (1998 9:00 AM EST)February 13;March 13;November 13 - (1999 9:00 AM EDT)August 13 - (2000 9:00 AM EDT)October 13 - ... - - The first Saturday that follows the first Sunday of the month, - forever: - - DTSTART;TZID=US-Eastern:19970913T090000 - RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13 - - ==> (1997 9:00 AM EDT)September 13;October 11 - (1997 9:00 AM EST)November 8;December 13 - (1998 9:00 AM EST)January 10;February 7;March 7 - (1998 9:00 AM EDT)April 11;May 9;June 13... - ... - - Every four years, the first Tuesday after a Monday in November, - forever (U.S. Presidential Election day): - - DTSTART;TZID=US-Eastern:19961105T090000 - RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4, - 5,6,7,8 - - ==> (1996 9:00 AM EST)November 5 - (2000 9:00 AM EST)November 7 - (2004 9:00 AM EST)November 2 - ... - - The 3rd instance into the month of one of Tuesday, Wednesday or - Thursday, for the next 3 months: - - DTSTART;TZID=US-Eastern:19970904T090000 - RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3 - - ==> (1997 9:00 AM EDT)September 4;October 7 - (1997 9:00 AM EST)November 6 - - The 2nd to last weekday of the month: - - DTSTART;TZID=US-Eastern:19970929T090000 - RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2 - - ==> (1997 9:00 AM EDT)September 29 - (1997 9:00 AM EST)October 30;November 27;December 30 - (1998 9:00 AM EST)January 29;February 26;March 30 - ... - - Every 3 hours from 9:00 AM to 5:00 PM on a specific day: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z - - ==> (September 2, 1997 EDT)09:00,12:00,15:00 - - Every 15 minutes for 6 occurrences: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6 - - ==> (September 2, 1997 EDT)09:00,09:15,09:30,09:45,10:00,10:15 - - Every hour and a half for 4 occurrences: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4 - - ==> (September 2, 1997 EDT)09:00,10:30;12:00;13:30 - - Every 20 minutes from 9:00 AM to 4:40 PM every day: - - DTSTART;TZID=US-Eastern:19970902T090000 - RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 - or - RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16 - - ==> (September 2, 1997 EDT)9:00,9:20,9:40,10:00,10:20, - ... 16:00,16:20,16:40 - (September 3, 1997 EDT)9:00,9:20,9:40,10:00,10:20, - ...16:00,16:20,16:40 - ... - - An example where the days generated makes a difference because of - WKST: - - DTSTART;TZID=US-Eastern:19970805T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO - - ==> (1997 EDT)Aug 5,10,19,24 - - changing only WKST from MO to SU, yields different results... - - DTSTART;TZID=US-Eastern:19970805T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU - ==> (1997 EDT)August 5,17,19,31 - - - - diff --git a/etc/time+date.txt b/etc/time+date.txt deleted file mode 100644 index 66296ee..0000000 --- a/etc/time+date.txt +++ /dev/null @@ -1,215 +0,0 @@ - -(should I put this in as an RCR, or 3 RCRs?) - -What's the difference between Time and DateTime? - -Time is in absolute seconds since some start date (jan 1, 1970). - - **Also** it inherits the C libraries knowledge of the local timezone, as well - as of daylight savings time. - -DateTime is in absolute days since some start date, with the hour/min/sec -within that day. - - **Also** it implements the Julian and Gregorian calendar, the conversion time - when a country switched, and can have arbitrary offsets from UTC specified. - - can be used for the last few thousand years (in places where it was used, - basically that means Europe). The timezone offset defaults to the current - offset, but there is no knowledge of daylight savings time changes. - - -The situation is a little confusing because there is no obvious difference -between the two, conceptually, and the diffences in the APIs of the two classes -are reflections of the underlying implementation technique, - - - seconds vs. days as the absolute time measure - - implemented in ruby or uses the C library - -rather than differences based on what someone would want to do with a class -that represents a date and time. - - -I have 3 suggestions/requests, described in more detail below: - -1 - that DateTime support all the methods of Time, so that it can be used -anywhere a Time can, with the the magic of DuckTyping - -2 - that using times (both Time and DateTime) be made easier by adding some -methods to one or both classes - -3 - that a way of making DateTime aware of daylight savings time be thought up - - -** 1 - -I would like to request that DateTime be "duck type" compatible with Time. - -This may not be entirely possible, since they share some method names, but the -methods behave differently. Perhaps these can be deprecated, or the docs can -mark them as non-compatible, and methods that do the same thing with the same -name can be added? - -The following methods are missing in DateTime, but I think would be trivial -to implement: - -Instance methods -- - - aTime.methods - aDateTime.methods => - [ - "dst?" - "getgm" - "getlocal" - "getutc" - "gmt?" - "gmt_offset" - "gmtime" - "gmtoff" - "isdst" - "localtime" - "to_f" - "to_i" - "tv_sec" - "tv_usec" - "usec" - "utc" - "utc?" - "utc_offset" - ] - -Class methods -- - - Time.methods - DateTime.methods => - - "local" - "times" --> DEPRECATED - "mktime" - "at" - "utc" - "gm" - - -Notes: - - dst?/isdst is one exception to the "its easy to do" statement. DateTime only - knows the offset, it can't know if it is DST, so perhaps it should always - return false? - - #zone() - Time -> some local nickname for the timezone ("EST"), useful only within a - country - DateTime -> an RFC822 style string ("+0530") of the hour and minute offset from - UTC - #to_s() - Time -> "Mon Mar 29 13:19:05 EST 2004" - DateTime -> "2004-03-29T13:18:58-0500" - +/- - Time -> add/sub a second - DateTime -> add/sub a day - succ - Time -> add a second - DateTime -> add a day - - #parse() - DateParse#parse(), Time#parse(), and DateTime#parse() all appear to do - basically the same thing, with some API differences. The heuristics aren't - documented, so its hard to know if there is a more fundamental difference. - - Time -> uses DateParse.parse, but adds some logic to do 2 digit year to 4 digit - conversion, and to add defaults - - DateTime -> implements its own heuristics, are they better or different the DateParse? - - -** 2 - -It's hard to do things like add a week, or add a day, to a Time, or even a DateTime. - -I think the Time and DateTime construction methods should allow objects like this -to be constructed more flexibly. They already wrap out-of-range values to the next -valid value, in some cases, but not all: - -[ensemble] ~/p/ruby/vcard $ ruby -r date -e "p (Date.civil(2004, 1, 31) >> 1).to_s" -"2004-02-29" - -[ensemble] ~/p/ruby/vcard $ ruby -r date -e "p (Date.civil(2004, 2, 31) >> 1).to_s" -/usr/local/lib/ruby/1.8/date.rb:591:in `civil': invalid date (ArgumentError) - - -There should be ways to add - - years, - months, - days, - hour - min - sec - -to both Time and DateTime, and support for these 6 are partial in both Time and DateTime. - - -Things to add that would help using DateTime and Time together: - - Date#to_time - raises ArgumentError if not representable, or should it return - a negative number? - - Time#to_datetime - maybe only defined if you require 'date'? - - Time#to_date - useful? - - eql?, <=> - should allow comparisons between Time and DateTime - -Operations that modify a Time or a DateTime could have a bang: - - Time#gmtime - Time#utc - Time#localtime - -A number of methods of DateTime aren't in Time, perhaps they can be added? - -Many of the methods are useful, but you have to convert your Time to a DateTime -to use them. Maybe Time is supposed to be "lighter weight" than DateTime? - -That would be OK, the docs could say that Time is a light-weight date/time -representation, with only the range of the system time, and that for a more -powerful representation, and many useful utility functions, require 'date', and -convert your aTime object to a DateTime using Time#to_datetime(). - -But, minus the lightweight argument, there is no reason they can't both support exactly -the same methods, both object and class! - -** 3 - -Daylight savings time is painful to deal with, but it is important! Not all -mornings in Ontario have a 2:30 AM! Even if its messy, its true. - -It would be really powerful if you could tell DateTime what timezone it is in, -not just the current offset, but the rule for how the offset changes (if it -does) with DST. Currently, ruby is as weak as ANSI C in dealing with multiple -timezones, that are NOT your own local timezone, simultaneously in a single -application. - -This is probably a just a dream... but here's my request: - -I'd like to see it possible for a DateTime could have it's timezone set, where -the timezone consists of: - - std -> standard offset from UTC - dst -> optional, DST offset from UTC, and some way of specifying the changeover - -This information could be in some kind of raw format, or could even be a string -timezone name. In that case, perhaps DateTime could have a class variable that -mapped strings to the std/dst definition. - -Here's a reference to a textual notation that seems good enough to specify most STD/DST -time zone transitions, perhaps an equivalent programmatic representation would be enough: - - http://www.qnx.com/developers/docs/qnx_6.1_docs/neutrino/lib_ref/global.html#TheTZEnvironmentVariable - -I don't know if this is widely used, or is just a QNX extension. I know OS X -(FreeBSD?) has a zone info compiler, where you can compile textual definitions -of timezones into a binary format. - - - - diff --git a/etc/vcal-10.txt b/etc/vcal-10.txt deleted file mode 100644 index 073b12c..0000000 --- a/etc/vcal-10.txt +++ /dev/null @@ -1,1603 +0,0 @@ -vCalendar -The Electronic Calendaring and Scheduling -Exchange Format -Version 1.0 - -A versit Consortium Specification -September 18, 1996 - -Copyrights -©, 1996, International Business Machines Corp., Lucent Technologies, Inc., and Siemens. All rights reserved. -Permission is granted to copy and distribute this publication provided that it is reproduced in its entirety without modification and includes the above copyright notice and this permission notice. -No licenses, express or implied, are granted with respect to any of the technology described in this publication. International Business Machines Corp., Lucent Technologies, Inc., and Siemens retain all their intellectual property rights in the technology described in this publication. -Even though International Business Machines Corp., Lucent Technologies, Inc., and Siemens have reviewed this specification, INTERNATIONAL BUSINESS MACHINES CORP., LUCENT TECHNOLOGIES, INC., AND SIEMENS, MAKE NO WARRANTY OR REPRESENTATION, EITHER EXPRESS OR IMPLIED, WITH RESPECT TO THIS PUBLICATION, ITS QUALITY OR ACCURACY, NONINFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. AS A RESULT, THIS SPECIFICATION IS DELIVERED "AS IS" AND THE READER ASSUMES THE ENTIRE RISK AS TO ITS QUALITY, ACCURACY OR SUITABILITY FOR ANY PARTICULAR PURPOSE.. -IN NO EVENT WILL INTERNATIONAL BUSINESS MACHINES CORP., LUCENT TECHNOLOGIES, INC., AND SIEMENS, BE LIABLE FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES RESULTING FROM ANY DEFECT OR INACCURACY IN THIS PUBLICATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. -This publication is provided with RESTRICTED RIGHTS. Use, duplication, or disclosure by the Government are subject to restrictions set forth in DFARS 252.227-7013 or 48 CFR 52.227-19, as applicable. - -Trademarks -versit, the versit logo, versitcard, vCard, vCalendar are trademarks of Apple Computer, Inc., AT&T Corp., International Business Machines Corp., and Siemens. -Apple and the Apple Logo are trademarks of Apple Computer, Inc. registered in the U.S. and other countries. -AT&T is a registered trademarks of AT&T Corp. -IBM is a registered trademarks of International Business Machines Corporation. - -Contributors -Roland H. Alden -Stephen J. Bartlett - -Jay Batson, ON Technology -John Binici, Iris Associates - -Steve Carter, Novell -Liang-Jye Chang, Starfish Software - -Andre Courtemanche, CS&T -Jim Cunnie, AT&T EasyCommerce - -Frank Dawson, IBM Corporation -Rik Drummond, The Drummond Group - -Gavin Eadie, University of Michigan -Pat Egen, Provident Life and Accident - -Randell Flint, Sundial Systems -Ben Forta, OnTime/Division of FTP - -Anik Ganguly, OnTime/Division of FTP. -Arvind Goyal, Lotus Development Corporation - -David Goodhand, Microsoft -Steve Hanna, ON Technology - -John Hansen, Starfish Software -Niraj Jain, Oracle Corporation - -Del Jensen, Novell -Bruce M. Johnston, Lotus Development Corporation - -Dr. Mark K. Joseph, Attachmate Corporation -Bruce Kahn, Iris Associates - -Don Lavange, Novell -Larry Mason, Microsystems Software, Inc. - -Skip Montanaro, Automatrix, Inc. -Pete OíLeary, Clear Blue Networking Systems, Inc. - -Ron Rassner, Creative Networks, Inc. -Vinod Seraphin, Lotus Development Corporation - -Uppili Srivivasan, Oracle Corporation -Tom Steppe, OnTime/Divison of FTP Software - -Dean Stevens, Now Software, Inc. -Budi Sutardja - -Robert Tatar, Automatrix, Inc. -Yvonne Tso, SunSoft - -Mike Weston, Netscape Communications Corporation. -Steve Wincor, Lockheed Martin - - - -Reference Information -The cited references contain provisions which, through reference in this specification, constitute provisions of this specification. At the time of publication, the indicated versions in the following references were valid. Parties to agreements based on this specification are encouraged to research the possibility of revised standards. -ï ANSI X3.4-1977, Code for Information Interchange, American National Standards Institute, 1977. -* IETF RFC 1738, Universal Resource Locator, December 1994. -* IETF Network Working Group RFC 1766, Tags for the Identification of Languages, March 1995. -* ISO 639, Code for The Representation of names of languages, International Organization for Standardization, April, 1988. -* ISO 3166, Codes for The Representation of names of countries, International Organization for Standardization, December, 1993. -* ISO 8601, Data elements and interchange formats-Information interchange-Representation of dates and times, International Organization for Standardization, June, 1988. -* ISO 8601, Technical Corrigendum 1, Data elements and interchange formats-Information interchange-Representation of dates and tmes, International Organization for Standardization, May, 1991. -* ISO 8859-1, Information Processing-8-Bit single-byte coded graphic character sets-Part 1: Latin Alphabet No. 1, International Organization for Standardization, February, 1987. -* ISO/IEC 9070, Information Technology-SGML Support Facilities-Registration Procedures for Public Text Owner Identifiers, Second Edition, International Organization for Standardization, April, 1991. -* RFC1521, MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies, Network Working Group, September, 1993. -* XAPIA CSA, Calendaring and Scheduling Application Programming Interface (CSA) Version 1.0, X.400 API Association, November 15, 1994. - - -versit Update -versit is a multivendor development initiative of the communication and computer industries, founded by Apple, AT&T, IBM and Siemens. The versit parties believe that great potential exists in improving the nature of communications in the business world-permitting companies to better manage their quality, productivity, customer satisfaction and cost of operations, while expanding the market opportunities for a variety of product and service vendors. versit parties will jointly define and support open specifications that facilitate and promote the interoperability of advanced personal information and communication devices, networks and services. -The versit vision is to enable diverse communication and computing devices, applications and services from competing vendors to interoperate in all environments. Through developing a series of specifications for interoperability among diverse communications and computing devices, applications, networks and services, versit 's vision will become a reality. -versit 's primary development areas are in: -* Personal Data Interchange (PDI) -* Computer Telephone Integration (CTI) -* Conferencing and Messaging (C&M) -* Wired and Wireless connectivity -versit specifications are directed at both the decision makers and the implementation teams of: -* Equipment Manufacturers -* Independent Software Vendors -* Information Service Providers -* Online Service Providers -* Software Houses -* Users -versit specifications are made available to any interested party. In turn, versit encourages the support of our goals by soliciting feedback on versit specifications. -All comments relating to versit or the material within this specification should be submitted to: -versit -(800) 803-6240 -(201) 327-2803 (Outside USA) -pdi@versit.com -http://www.versit.com - - -Contents -Section 1 : Introduction -1.1 Overview -1.2 Scope -1.3 Contents -1.4 Definitions and Abbreviations -Section 2 : vCalendar -2.1 Encoding Characteristics -2.1.1 vCalendar Object -2.1.1.1 vEvent Object -2.1.1.2 vTodo Object -2.1.2 Property -2.1.3 Delimiters -2.1.4 Encodings -2.1.5 Character Set -2.1.6 Language -2.1.7 Date and Time -2.1.8 Time Duration -2.1.9 Value Location -2.1.10 Binary Values -2.1.11 Basic Recurrence Rule Grammar -2.1.11.1 Daily Rule -2.1.11.2 Weekly Rule -2.1.11.3 Monthly Rule -2.1.11.4 Yearly Rule -2.1.11.5 Grammar -2.1.11.6 Glossary -2.1.11.7 Policies -2.2 vCalendar Properties -2.2.1 Daylight Savings Rule -2.2.2 Geographic Position -2.2.3 Product Identifier -2.2.4 Time Zone -2.2.5 Version -2.3 vEvent and vTodo Properties -2.3.1 Attachment -2.3.2 Attendee -2.3.3 Audio Reminder -2.3.4 Categories -2.3.5 Classification -2.3.6 Date/Time Created -2.3.7 Date/Time Completed -2.3.8 Description -2.3.9 Display Reminder -2.3.10 Due Date/Time -2.3.11 End Date/Time -2.3.12 Exception Date/Times -2.3.13 Exception Rule -2.3.14 Last Modified -2.3.15 Location -2.3.16 Mail Reminder -2.3.17 Number Recurrences -2.3.18 Priority -2.3.19 Procedure Reminder -2.3.20 Related To -2.3.21 Recurrence Date/Times -2.3.22 Recurrence Rule -2.3.23 Resources -2.3.24 Sequence Number -2.3.25 Start Date/Time -2.3.26 Status -2.3.27 Summary -2.3.28 Time Transparency -2.3.29 Uniform Resource Locator -2.3.30 Unique Identifier -2.4 Miscellaneous Properties -2.4.1 Extensions -2.5 Formal Definition -Section 3 : Internet Recommendations -3.1 Recommended Practice With SMTP/MIME -3.1.1 Text/Plain Content Type -3.1.2 Text/X-vCalendar Content Type -3.2 Recommended Practice With HTTP/HTML -Section 4 : UI Support Recommendations -4.1 File System -4.2 Clipboard -4.3 Drag/Drop -Section 5 : Conformance -Section 6 : Extended Recurrence Grammar -6.1 Rule Introduction -6.2 Grammar -6.3 Glossary -6.4 Policies -6.5 Examples - - -Section 1 : Introduction -[DS1] -Personal Data Interchange (PDI) occurs every time two or more individuals communicate, in either a business or personal context, face-to-face, or across space and time. Such interchanges frequently include the exchange of informal information, such as business cards, telephone numbers, addresses, dates and times of appointments, etc. Augmenting PDI with electronics and telecommunications can help ensure that information is quickly and reliably communicated, stored, organized and easily located when needed. -Personal information, by nature, is complex and diverse. Currently, proprietary standards exist to structure some types of PDI information, but no single, open specification comprehensively addresses the needs of collecting and communicating PDI information across many common communication channels such as telephones, voice-mail, e-mail, and face-to-face meetings. versit is developing a comprehensive family of PDI technologies based on open specifications and interoperability agreements to help meet this technology need. -Overview -This specification defines a format for an electronic calendaring and scheduling (vCalendar) format. The vCalendar format allows for the capture of information normally stored within a calendaring and scheduling application; such as a Personal Information Manager or a Group Scheduling product. -The format is suitable as an interchange format between applications or systems. The format is defined independent of the particular method used to transport it. The transport for this exchange might be a file system, point-to-point asynchronous communication, wired-network transport, or some form of unwired transport. -A vCalendar is a data stream consisting of one or more vCalendar objects. The individual vCalendar definitions can be identified and parsed within the data stream. The vCalendar data stream may exist as a persistent form in a file system, document management system, network connection between two network endpoints, or in any other digital transport that has an abstraction of a stream of bytes. -Conceptually, a vCalendar Writer creates vCalendar data streams and a vCalendar Reader interprets vCalendar data streams. The vCalendar Reader and Writer may be implemented as a single application or as separate applications. It is not the intent of this specification to define the implementation of these processes beyond some fundamental capabilities related to the format of the vCalendar data stream and a common set of conformance requirements. -This specification provides for a clear-text encoding. The specification also includes a formal grammar for the clear-text encoding to aid in the implementation of parsers and to serve as the definitive reference when ambiguities or questions arise in interpreting the descriptive prose definition of the specification. -The clear-text encoding of this specification can be used in environments which are constrained to 7-bit transfer encodings, short line lengths, and low bandwidth. In addition, the encoding is simple in order to facilitate the implementation of reader and writer applications on small platforms, such as Personal Digital Assistants (PDA), cellular telephones, or alphanumeric pagers. -Scope -The vCalendar is intended to be used for exchanging information about event and todo types of calendaring and scheduling entities. An event is a calendaring and scheduling entity that represents a scheduled amount of time on a calendar. For example, it may be an activity; such as a one-hour, department meeting from 8 AM to 9 AM, tomorrow. A todo is a calendaring and scheduling entity that represents an action-item or assignment. For example, it may be an item of work assigned to an individual; such as "turn in travel expense today". -In today's business environment, this information is typically kept on a paper-based day-planner or calendar. More and more, this type of information is being also managed within electronic Personal Information Manager or Group Scheduling products. It is appropriate, then that this specification define this information in terms of a paradigm based on a calendaring and scheduling event and todo entities. -Prior to the introduction of the vCalendar specification, users of such applications typically had to re-key the original information, often transcribing it from paper day-planners, scraps of paper or electronic mail messages. With the advent of the vCalendar specification, this information can be exchanged in an automated and consistent fashion. -The basis for this specification have their origin in openly defined, industry specifications; such as the X.400 API Association's Calendaring and Scheduling API (CSA). In addition, this specification has capabilities that were derived from the experience of multi-vendor demonstrations of this capability. -The specification of all date and time values are defined in terms of the ISO 8601 standard for representation of dates and times. The ISO 8601 standard supersedes all other international standards defined at the time this specification was drafted. -Personal data applications such as Personal Information Managers (PIM) often provide an import/export capability using Comma Separated Value (CSV) or Tab Delimited Files (TDF) formats. However, these solutions do not preserve the intent of the originating application. When a CSV and TDF format is used by a PIM, the meta-data or semantics of the originating object are only apparent to a similar version of the originating application. Exchange of data between such applications is another important application of an industry-standard specification for an electronic calendaring and scheduling interchange format, such as the vCalendar specification. -This specification is intended to be used as a format for exchange of calendaring and scheduling information from one product to another. This exchange may take place using desktop application interaction techniques; such as a file system FILE-OPEN or FILE-SAVE-AS functions, an operating systems clipboard CUT or COPY or PASTE operations, or a user interface DRAG and DROP interaction. In addition, this exchange may take place using a wired or wireless network transport; such as LAN or WAN protocols, switched telephone circuits, IrDA-based infra-red "beaming" of data, or emerging cellular data services. In any of these example cases, the vCalendar format is intended to be a transport- and platform-independent format for exchanging calendaring and scheduling personal data. -Contents -This specification is separated into eight sections: -* "Section 1 : Introduction" introduces PDI and the vCalendar specification with an overview, scope statement and section on definitions and abbreviations. -* "Section 2 : vCalendar" defines the semantics and syntax for a clear-text encoding of the vCalendar. -* "Section 3: Internet Recommendations" specifies a set of guidelines to facilitate the exchange of vCalendar objects over Internet protocols such as HTTP using HTML and SMTP using MIME. -* "Section 4 : UI Support Recommendations" specifies a set of guidelines to facilitate the exchange of vCalendar objects at the desktop user interface using the file system, clipboard and drag/drop capabilities of the operating system. -* "Section 5 : Conformance" defines minimum conformance requirements to consider while developing support for this vCalendar specification. -* "Section 6 : Extended Recurrence Rule Grammar" defines reference information on an extended recurrence rule grammar, copied from the XAPIA CSA Specification. -Definitions and Abbreviations -Definitions and abbreviations used within this specification follow. -API: Application Programming Interface -Electronic Calendar: Also know as vCalendar. -FPI: Formal Public Identifier. A string expression that represents a public identifier for an object. FPI syntax is defined by ISO 9070. -GUID: Globally Unique IDentifier -Internet: A WAN connecting thousands of disparate networks in industry, education, government, and research. The Internet uses TCP/IP as the standard for transmitting information. -ISO: Organization for International Standardization; a worldwide federation of national standards bodies (ISO Member bodies). -MIME: Multipurpose Internet Mail Extensions, as defined in RFC1521. -PDA: Personal Digital Assistant computing device -PDI: Personal Data Interchange, a collaborative application area which involves the communication of data between people who have a business or personal relationship, but do not necessarily share a common computing infrastructure. -PIM: Personal Information Manager -RFC### documents: Internet "Request For Comment" documents (i.e., RFC822, RFC1521, etc.). -URL: Uniform Resource Locator; a string expression that can represent any resource on the Internet or local system. RFC 1738 defines the syntax for an URL. -UTC: Universal Time Coordinated; also known as UCT, for Universal Coordinated Time. -vCalendar: The generic term for an electronic, virtual collection of calendaring and scheduling information that can be transferred between computers, PDAs, or other electronic devices through telephone lines, or e-mail networks, or infrared links. How, when, why, and where vCalendar are used depends on the applications developed utilizing a vCalendar. -WAN: Wide-Area Network - - -Section 2 : vCalendar -[DS2] -This section defines the semantics and syntax for encoding the vCalendar in a simple, clear-text encoding. -Encoding Characteristics -The following characteristics are specific to this encoding. -vCalendar Object -A vCalendar data stream may include one or more vCalendar objects. An individual vCalendar object is identified within a data stream by the appearance of the Begin vCalendar Delimiter: -BEGIN:VCALENDAR -The sentinel string must appear as the first characters in the data stream or the first characters on a line. -The vCalendar object is terminated by the appearance of the End vCalendar Delimiter as the first characters on a line: -END:VCALENDAR -The vCalendar object is a container for calendaring and scheduling entities. These can include either event or todo entities. -vEvent Object -A vEvent is a grouping of calendaring and scheduling properties that define an entity that represents a scheduled amount of time on a calendar. For example, it may be an activity; such as a one-hour, department meeting from 8 AM to 9 AM, tomorrow. -An individual vEvent entity is identified within a vCalendar object by the appearance of the delimiter: -BEGIN:VEVENT -The sentinel string must appear as the first characters on a line. -The vEvent entity is terminated with the appearance of the following delimiter string as the first characters on a line -END:VEVENT -The vEvent entity can not be nested within another vEvent or vTodo entity. If vEvent entities need to be related to each other or to a vTodo entity, they can specify relationship with the RELATED-TO property. -vTodo Object -A vTodo is a grouping of calendaring and scheduling properties that define an entity that represents an action-item or assignment. For example, it mayto 7-bit transfer encodings, short line lengths, and low bandwidth. In addition, the encoding is simple in order to facilitate the implementation of reader and writer applications on small platforms, such as Personal Digital Assistants (PDA), cellular telephones, or alphanumeric pagers. -Scope -The vCalendar is intended to be used for exchanging information about event and todo types of calendaring and scheduling entities. An event is a calendaring and scheduling entity that represents a scheduled amount of time on a calendar. For example, it may be an activity; such as a one-hour, department meeting from 8 AM to 9 AM, tomorrow. A todo is a calendaring and scheduling entity that represents an action-item or assignment. For example, it may be an item of work assigned to an individual; such as "turn in travel expense today". -In today's business environment, this information is typically kept on a paper-based day-planner or calendar. More and more, this type of information is being also managed within electronic Personal Information Manager or Group Scheduling products. It is appropriate, then that this specification define this information in terms of a paradigm based on a calendaring and scheduling event and todo entities. -Prior to the introduction of the vCalendar specification, users of such applications typically had to re-key the original information, often transcribing it from paper day-planners, scraps of paper or electronic mail messages. With the advent of the vCalendar specification, this information can be exchanged in an automated and consistent fashion. -The basis for this specification have their origin in openly defined, industry specifications; such as the X.400 API Association's Calendaring and Scheduling API (CSA). In addition, this specification has capabilities that were derived from the experience of multi-vendor demonstrations of this capability. -The specification of all date and time values are defined in terms of the ISO 8601 standard for representation of dates and times. The ISO 8601 standard supersedes all other international standards defined at the time this specification was drafted. -Personal data applications such as Personal Information Managers (PIM) often provide an import/export capability using Comma Separated Value (CSV) or Tab Delimited Files (TDF) formats. However, these solutions do not preserve the intent of the originating application. When a CSV and TDF format is used by a PIM, the meta-data or semantics of the originating object are only apparent to a similar version of the originating application. Exchange of data between such applications is another important application of an industry-standard specification for an electronic calendaring and scheduling interchange format, such as the vCalendar specification. -This specification is intended to be used as a format for exchange of calendaring and scheduling information from one product to another. This exchange may take place using desktop application interaction techniques; such as a file system FILE-OPEN or FILE-SAVE-AS functions, an operating systems clipboard CUT or COPY or PASTE operations, or a user interface DRAG and DROP interaction. In addition, this exchange may take place using a wired or wireless network transport; such as LAN or WAN protocols, switched telephone circuits, IrDA-based infra-red "beaming" of data, or emerging cellular data services. In any of these example cases, the vCalendar format is intended to be a transport- and platform-independent format for exchanging calendaring and scheduling personal data. -Contents -This specification is separated into eight sections: -* "Section 1 : Introduction" introduces PDI and the vCalendar specification with an overview, scope statement and section on definitions and abbreviations. -* "Section 2 : vCalendar" defines the semantics and syntax for a clear-text encoding of the vCalendar. -* "Section 3: Internet Recommendations" specifies a set of guidelines to facilitate the exchange of vCalendar objects over Internet protocols such as HTTP using HTML and SMTP using ject XYZ Final Review -Conference Room - 3B -Come Prepared. -Would be represented in a Quoted-Printable encoding as: -DESCRIPTION;ENCODING=QUOTED-PRINTABLE:Project XYZ Final Review=0D=0A= - Conference Room - 3B=0D=0A= - Come Prepared. -Property parameter substrings are delimited by a field delimiter, specified by the Semi-colon character (ASCII decimal 59). A Semi-colon in a property parameter value must be escaped with a Backslash character (ASCII 92). -Compound property values are delimited by a field delimiter, specified by the Semi-colon character (ASCII decimal 59). A Semi-colon in a component of a compound property value must be escaped with a Backslash character (ASCII 92). -Encodings -The default encoding for the vCalendar object is 7-Bit. The default encoding can be overridden for an individual property value by using the "ENCODING" property parameter. This parameter value can be either "BASE64", "QUOTED-PRINTABLE", or "8-bit". This parameter may be used on any property. -Some transports (e.g., MIME based electronic mail) may also provide an encoding property at the transport wrapper level. This property can be used in these cases for transporting a vCalendar data stream that has been defined using a default encoding other than 7-bit (e.g., 8-bit). -Character Set -The default character set is ASCII. The default character set can be overridden for an individual property value by using the "CHARSET" property parameter. This property parameter may be used on any property. However, the use of this parameter on some properties may not make sense. -Any character set registered with the Internet Assigned Numbers Authority (IANA) can be specified by this property parameter. For example, ISO 8859-8 or the Latin/Hebrew character set is specified by: -DESCRIPTION;CHARSET=ISO-8859-8:... -Some transports (e.g., MIME based electronic mail) may also provide a character set property at the transport wrapper level. This property can be used in these cases for transporting a vCalendar data stream that has been defined using a default character set other than ASCII (e.g., UTF-8). -Language -The default language is "en-US" (US English). The default language can be overridden for an individual property value by using the "LANGUAGE" property parameter. The values for this property are a string consistent with RFC 1766, Tags for the Identification of Languages. This property parameter may be used on any property. However, the use of this parameter on some properties, such as PHOTO, LOGO, SOUND, TEL, may not make sense. Canadian French would be specified by this parameter by the following: -SUMMARY;LANGUAGE=fr-CA:... -Date and Time -The date and time values for all vCalendar properties are formatted as a string consistent with the ISO 8601 representation for combinations of dates and times. Either the basic or extended format is allowed. The use of UTC, rather than local time, should be used when ever possible in order to avoid time zone ambiguities. The format for the complete, basic representation of a date and time value is written in the following sequence of characters: -T -For example, 8:30 AM on April 15, 1996 local time would be written as: -19960415T083000 -And the same time in UTC based time would be written as: -19960415T083000Z -Where a value needs to specify a sequence of date and time values, then the property value is a string made up of a list of date and time values, separated by the field separator. For example: -19960101T090000Z; 19960201T090000Z; 19960301T090000Z; 19960401T090000Z; ... -Time Duration -The values for time duration or periods of time for all vCalendar properties are formatted as a string conformant with the ISO 8601 basic representation for duration of time. A given duration of a period of time is represented by a character string consisting of the designator "P", optionally including the number of years followed by the designator "Y", optionally including the number of months followed by the designator "M", optionally including the number of weeks followed by the designator "W", optionally including the number of days followed by the designator "D". The sequence can also contain a time component preceded by the designator "T", optionally including the number of hours followed by the designator "H", optionally including the number of minutes followed by the designator "M", optionally including the number of seconds followed by the designator "S". For example: -P6W -A period of six weeks; -PT15M -A period of 15 minutes; -PT1H30M -A period of 1 hour and thirty minutes; or -P2Y10M15DT10H30M20S -A period of 2 years, 10 months, 15 days, 10 hours, 30 minutes, and 20 seconds. -Value Location -The default location of the property values is inline with the property. However, for some properties, such as those that specify multimedia values, it is efficient to organize the property value as a separate entity (e.g., a file out on the network). The property parameter "VALUE" can be specified to override the "INLINE" location of the property value. In the case of the vCalendar being transported within a MIME email message, the property value can be specified as being located in a separate MIME entity with the "CONTENT-ID" value; or "CID" for shorthand. In this case, the property value is the Content-ID for the MIME entity containing the property value. In addition, the property value can be specified as being located out on the network using the "URL" value. In this case, the property value is the Uniform Resource Locator for the Internet resource containing the property value. This property parameter may be used on any property. However, the use of this parameter on some properties may not make sense; for example the Version, Time Zone, Status, Priority, Mail Reminder, etc. properties. The following specifies a value not located inline with the vCalendar but out in the Internet: -ATTACH;VALUE=URL:http://www.abc.com/dir_photos/my_photo.gif - -Binary Values -The vCalendar specification supports inclusion of binary information, such as computer graphic images (e.g., JPEG), digital audio (e.g., WAVE), or video graphic images (e.g., MPEG). The binary information can either be referenced with a Uniform Reference Locator (URL), referenced with a message using a MIME Content-ID of the MIME part that contains the content, or placed inline in the vCalendar as the value of a property. Inline binary information is included as a property value after being character encoded using Base 64 (default) or Quoted-Printable encoding. -Basic Recurrence Rule Grammar -The specification of recurring events can be simplified by the use of a grammar or rule notation. This specification makes use of the Base Recurrence Rule Grammar from the XAPIA's CSA Specification. -A recurrence rule is a string or clear-text encoding of a recurrence specification. A recurrence rule is composed of several components. A rule begins with a frequency which describes the type of repeating event (e.g., daily, weekly, etc.). This is followed by an interval which indicates how often the frequency repeats (i.e., daily, every third day, etc.). This can be followed by optional frequency modifier information and either an end date or a duration. -Below is the form of a typical rule. This example causes events to be generated every other week on Tuesday and Thursday, for 8 occurrences: -W2 TU TH #4 -Where, W is the Frequency, 2 is the Interval, TU and TH are the optional Frequency Modifiers, and #4 is the Duration. -The basic recurrence rule grammar supports six types of repetition. The six types follow the same form with only the frequency name and optional modifier information changing from one type of frequency to the next. -Daily Rule -The daily rule is used for specifying repeating events based on an interval of a day or more. These can range from every day to every 200th day and beyond. The daily rule begins with the letter D followed by an interval (representing days) and an optional duration or end date. -Some examples follow: -Daily for 10 occurrences: - D1 #10 -Daily until 12/24/94: - D1 19941224T000000Z -Every other day - forever: - D2 #0 -Every 10 days, 5 occurrences: - D10 #5 -Weekly Rule -The weekly rule is used for specifying repeating events based on an interval of a week or more. The basic weekly rule has the same form as the daily rule except that the rule begins with a W and can contain an optional list of weekdays the events are generated on. For weekly rules, the interval represents weeks. Some examples follow: -Weekly for 10 occurrences: - W1 #10 -Weekly until 12/24/94: - W1 19941224T000000Z -Every other week - forever: - W2 #0 -Weekly on Tuesday and -Thursday for 5 weeks: - W1 TU TH #5 -Every other week on Monday Wednesday and Friday until 12/24/94: - W2 MO WE FR 19941224T000000Z -Monthly Rule -The monthly rule is used for specifying repeating events base on an interval of a month or more. There are two types of monthly recurrence rules. One for by-position and one for by-day. The by-position rule allows weekdays in the month to be specified in relation to their occurrence in the month. An example would be to specify the third Sunday of the month or the last Friday of the month. An occurrence specifier may be used in monthly by-position rules. The occurrence specifiers control which occurrence of a weekday in a month an event occurs on: -1+, 2+, ... 5+ for the first occurrence, second, ...fifth occurrence of the month. -1-, 2-, ... 5- for the last occurrence, second to last occurrence, etc. -A 2+ FR SA would indicate the second occurrence of Friday and Saturday in the month. A 1- MO would indicate the first occurrence of Monday working from the end of the month backwards (i.e., the last occurrence). A 2- MO would be the second to the last Monday of the month. -A by-day rule allows actual day numbers to be specified such as the 12th day or 29th day. -The by-position rule begins with a MP and the by-day rule begins with a MD. The interval in monthly rules represents months. Some examples follow: -Monthly on the 1st Friday for ten occurrences: - MP1 1+ FR #10 -Monthly on the 1st Friday until 12/24/94: - MP1 1+ FR 19941224T000000Z -Every other month on the 1st and last -Sunday of the month for 10 occurrences: - MP2 1+ SU 1- SU #10 -Every six months on the 2nd Monday -thru Friday for 10 occurrences: - MP6 2+ MO TU WE TH FR #10 -Monthly on the second last Monday of the month for 6 months: - MP1 2- MO #6 -Monthly on the third to the last day of the month, forever: - MD1 3- #0 -Monthly on the 2nd and 15th of the month for 10 occurrences: - MD1 2 15 #10 -In the next example LD refers to "LastDay" in a monthly recurrence rule. Monthly on the 1st and last day of the month for 10 occurrences: - MD1 1 LD #10 or MD1 1 1- #10 -Every 18 months on the 10th thru 15th of the month for 10 occurrences: - MD18 10 11 12 13 14 15 #10 -Monthly on the second to the last day for 5 months. So, if the start date is August 1996, the event would repeat on 8/30/96, 9/29/96, 10/30/96, 11/29/96, and 12/30/96: - MD1 2- #5 -Yearly Rule -The yearly rule is used for specifying repeating events based on an interval of a year or more. There are two types of yearly recurrence rules. One for by-month and one for by-day. The by-month rule allows specific months out of the year to be specified. The by-day allows specific days to be specified. In the by-month rule, the day in the month the rule is to occur on is determined from the initial appointment. -The by-month rule begins with a YM and the by-day rule begins with a YD. The interval in yearly rules represents years. Some examples follow: -Yearly in June and July for 10 occurrences: - YM1 6 7 #10 -Every other year on January, Feb, and March for 10 occurrences: - YM2 1 2 3 #10 -Every 3rd year on the 1st, 100th and 200th day for 10 occurrences: - YD3 1 100 200 #10 -Grammar -{} 0 or more -[] 0 or 1 -start ::= [] | - [] | - [] | - [] | - [] | - [] -digit ::= <0|1|2|3|4|5|6|7|8|9> -digits ::= {} -enddate ::= ISO 8601_date_time value(e.g., 19940712T101530Z) -interval ::= -duration ::= # -lastday ::= LD -plus ::= + -minus ::= - -daynumber ::= <1-31> [|]| -daynumberlist ::= daynumber {} -month ::= <1-12> -monthlist ::= {} -day ::= <1-366> -daylist ::= {} -occurrence ::= <1-5> | <1-5> -occurrencelist ::= {} -weekday ::= -weekdaylist ::= {} -daily ::= D [] -weekly ::= W [] [] -monthlybypos ::= MP [ ] [] -monthlybyday ::= MD [] [] -yearlybymonth ::= YM [] [] -yearlybyday ::= YD [] [] -Glossary -enddate Controls when a repeating event terminates. The enddate is the last time an event can occur. -interval Defines the frequency in which a rule repeats. -duration Controls the number of events a rule generates. -lastday Can be used as a replacement to daynumber to indicate the last day of the month. -daynumber A number representing a day of the month. -month A number representing a month of the year. -day A number representing a day of the year. -occurrence Controls which week of the month a particular weekday event occurs. -weekday A symbol representing a day of the week. -daily Defines a rule that repeats on a daily basis. -weekly Defines a rule that repeats on a weekly basis. -monthlybypos Defines a rule that repeats on a monthly basis on a relative day and week. -monthlybyday Defines a rule that repeats on a monthly basis on an absolute day. -yearlybymonth Defines a rule that repeats on specific months of the year. -yearlybyday Defines a rule that repeats on specific days of the year. -Policies -The duration portion of a rule defines the total number of events the rule generates, including the first event. -Information, not contained in the rule, necessary to determine the next event time and date is derived from the Start Time entry attribute. -If an end date and a duration is specified in the rule, the recurring event ceases when the end date is reached or the number of events indicated in the duration occur; whichever comes first. -If the duration or an end date is not established in the rule (e.g., D4) the event occurs twice. That is D4 is equivalent to D4 #2. -A duration of #0 means repeat this event forever. -Using the occurrence specifier 5+ (e.g. 5th Friday) or 5- (e.g. 5th from last Friday) in a month that does not contain 5 weeks does not generate an event and thus does not count against the duration. The same applies to providing a day of the month that does not occur in the month. For example the 30th or 31st . -The start time and date of an entry must be synchronized with one of the repeating events defined by its recurrence rule. The following is not allowed: - - Initial Appt Date: 7/1/94 (Friday) - Recurrence Rule: W1 MO TH #5 - -The following is acceptable: - - Initial Appt Date: 7/1/94 (Friday) - Recurrence Rule: W1 MO FR #5 or W1 #5 -If the optional and information is missing from a occurrence the information is derived from the entry attributes. The used in the recurring event is a count from the beginning of the month to the entry date and the used is the day of the week the entry is scheduled to occur on. - -If the occurrence or occurrence does not list a week day (e.g., SU or day 10) in the rule, the week day is established from the entry attribute information. As an example the rule MP1 #3 used in an entry with a start date of 7/20/94 (which is the third Wednesday of the month) repeats on 8/17/94 which is the third Wednesday of the month. -vCalendar Properties -The following properties must appear after the BEGIN:VCALENDAR delimiter but before the occurrence of the BEGIN:VEVENT or BEGIN:VTODO delimiters. These properties apply to the vCalendar object as a whole; unless overridden by a property within the scope of an event or todo entity. -Daylight Savings Rule -This property is identified by the property name DAYLIGHT. This property defines the daylight savings time rule observed by the "home" calendar system that created the vCalendar entity. -Many locations adjust their standard time forward or backward by one hour, in order to accommodate seasonal changes in number of daylight hours. Standard time is also known as Winter Time. Daylight savings time is also known as Advanced Time, Summer Time, or Legal Time in certain countries. -The property value consists of a sequence of components that define the daylight savings time rule. The value consists of the daylight savings time flag, followed by the daylight savings time offset, followed by the date and time that the daylight savings time begins, followed by the date and time that the daylight savings time ends, followed by the standard time designation, followed by the daylight savings time designation. The daylight savings time flag is TRUE if daylight savings time is observed, otherwise it is FALSE and no other components are specified. The daylight savings time offset value is specified in a manner consistent with ISO 8601. The property value is a signed numeric indicating the number of hours and possibly minutes from UTC. The date and time that the daylight savings time begins and ends is specified in a manner consistent with ISO 8601 date and time format. The standard time and daylight savings time designations correspond to the customary character designations. -The following are examples of this property: -DAYLIGHT:TRUE;-06;19960407T025959;19961027T010000;EST;EDT -DAYLIGHT:FALSE -DAYLIGHT:TRUE;-09;19960407T115959;19961027T100000;PST;PDT -Support for this property is optional for implementations conforming to this specification. -Geographic Position -This property is identified by the property name GEO. This property specifies information related to the global position of the "home"system that created the vCalendar object. The property value specifies longitude and latitude. The longitude represents the location east and west of the prime meridian as a positive or negative real number, respectively. The latitude represents the location north and south of the equator as a positive or negative real number, respectively. The following is an example of this property: -GEO:37.24,-17.87 -Support for this property is optional for implementations conforming to this specification. -Product Identifier -This property is identified by the property name PRODID. This property specifies the identifier for the product that created the vCalendar object. The vendor of the implementation should assure that this is a globally unique identifier; using some technique such as an ISO 9070 FPI value. The following is an example of this property: -PRODID:-//ABC Corporation//NONSGML My Product//EN -Support for this property is optional for implementations conforming to this specification. -Time Zone -This property is identified by the property name TZ. This property specifies the standard time zone of the "home" system that created the vCalendar object. The property value is specified in a manner consistent with ISO 8601. The property value is a signed numeric indicating the number of hours and possibly minutes from UTC. Time zones east of UTC are positive numbers. Time zones west of UTC are negative numbers. The following are examples of this property: -TZ:-05 -TZ:+05:30 -Support for this property is optional for implementations conforming to this specification. -Version -This property specifies the identifier corresponding to the highest version number of the vCalendar Specification supported by the implementation that created the vCalendar object. The value of this property must be 1.0 to correspond to this specification.. -This property is identified by the property name VERSION. The following is an example of this property: -VERSION:1.0 -Support for this property is mandatory for implementations conforming to this specification. This property must appear within the vCalendar data stream. -vEvent and vTodo Properties -The following properties may appear within an event or todo calendaring and scheduling entity. -Attachment -This property is identified by the property name ATTACH. The property defines an attached object to the vCalendar entity. For example, a document to be reviewed at a scheduled event or the process steps for a todo. The property value can be a text string, a reference to another message body part or a reference to a URL based document. -Multiple attachments may be specified by including multiple ATTACH properties within the vCalendar entity. -The following are examples of this property: -ATTACH;VALUE=CONTENT-ID: -ATTACH;VALUE=URL:file://xyzCorp.com/pub/reports/r-960812.ps -Support for this property is optional for implementations conforming to this specification. -Attendee -This property is identified by the property name ATTENDEE. The property defines an attendee to a group event or todo. The default property value is an (RFC 822) address. The property may include property parameters ROLE, for the role of the attendee in the event or todo; STATUS, for the status of the attendee's participation in the event or todo, RSVP, for indicating whether the favor of a reply is requested, and EXPECT, to indicate the expectation of the attendee's participation by the originator. -Multiple attendees may be specified by including multiple ATTENDEE properties within the vCalendar entity. -The property value may reference a vCard object. This provides a useful mechanism to allow more than just the address of the attendee to be referenced. -The ROLE property parameter for each attendee can have the following values: - -Description -Property Value - -Indicates an attendee at the event or todo -ATTENDEE - -Indicates organizer of the event, but not owner -ORGANIZER - -Indicates owner of the event or todo. -OWNER - -Indicates a delegate of another attendee. -DELEGATE - - -The default value for this property parameter is ATTENDEE. -The STATUS property parameter for each attendee can have the following values: - -Description -Property Value - -Indicates todo was accepted by attendee -ACCEPTED - -Indicates event or todo requires action by attendee -NEEDS ACTION - -Indicates event or todo was sent out to attendee -SENT - -Indicates event is tentatively accepted by attendee -TENTATIVE - -Indicates attendee has confirmed their attendance at the event -CONFIRMED - -Indicates event or todo has been rejected by attendee -DECLINED - -Indicates todo has been completed by attendee -COMPLETED - -Indicates event or todo has been delegated by the attendee to another -DELEGATED - - -The default value for this property parameter is NEEDS ACTION. -The RSVP property parameter for each attendee can have the following values: - -Description -Property Value - -Indicates a reply is requested -YES - -Indicates a reply is not requested. -NO - - -The default value for this property parameter is NO. -The EXPECT property parameter for each attendee can have the following values: - -Description -Property Value - -Indicates request is for your information. -FYI - -Indicates presence is definitely required. -REQUIRE - -Indicates presence is being requested -REQUEST - -Indicates an immediate response needed. -IMMEDIATE - - -The default value for this property parameter is FYI. -The following is an example of this propertyís use for a todo: -ATTENDEE;ROLE=OWNER;STATUS=COMPLETED:jsmith@host1.com -The following is an example of this property used for specifying multiple attendees to an event: -ATTENDEE;ROLE=OWNER;STATUS=CONFIRMED:John Smith -ATTENDEE;ROLE=ATTENDEE;STATUS=TENTATIVE:Henry Cabot -ATTENDEE;ROLE=DELEGATE;STATUS=CONFIRMED:Jane Doe -The following is an example of this property with the value specified as an URL reference to a vCard that contains the information about the attendee: -ATTENDEE;ROLE=ATTENDEE;STATUS=CONFIRMED;VALUE=URL;TYPE=VCARD: - http://www.xyz.com/~myvcard.vcf -Support for this property is optional for implementations conforming to this specification. -Audio Reminder -This property is identified by the property name AALARM. The property defines an audio reminder for the vCalendar entity. An audio reminder is an alarm that is sounded for the event. -The value for the audio reminder consists of the Run Time, or the date and time that the reminder is to be executed; Snooze Time, or the duration of time after the Run Time that the reminder is to be dormant prior to being repeated; Repeat Count, or the number of times that the reminder is to be repeated; and the Audio Content, or the digital sound to be played when the reminder is executed. -The following are some examples of this property: -AALARM;TYPE=WAVE;VALUE=URL:19960415T235959; ; ; file:///mmedia/taps.wav -AALARM;TYPE=WAVE;VALUE=CONTENT-ID:19960903T060000;PT15M;4; -The property has the following additional property parameters: - -Description -Property Parameter Values - -TYPE - - -Indicates the MIME basic audio content type. -PCM - -Indicates the WAVE format for audio content. -WAVE - -Indicates the AIFF format for audio content. -AIFF - - -The Reminder properties are primarily provided as a means for allowing the capture of alarm information when accessing a calendar system. It may not be an appropriate property to send in an event or todo request. -Support for this property is optional for implementations conforming to this specification. -Categories -This property is identified by the property name CATEGORIES. This property defines the categories for the vCalendar entity. More than one category may be specified as a list of categories separated by the Semi-Colon character (ASCII decimal 59). -The following are some examples of this property: -CATEGORIES:APPOINTMENT;EDUCATION -CATEGORIES:MEETING -Some of the possible values for this property might include the following: - -Some Possible -Property Values - -APPOINTMENT - -BUSINESS - -EDUCATION - -HOLIDAY - -MEETING - -MISCELLANEOUS - -PERSONAL - -PHONE CALL - -SICK DAY - -SPECIAL OCCASION - -TRAVEL - -VACATION - - -Support for this property is mandatory for implementations conforming to this specification. -Classification -This property is identified by the property name CLASS. This property defines the access classification for the vCalendar entity. -A calendar entity access classification is only one component of the general security system within a calendar application. It provides a method of capturing the scope of the access the calendar owner intends for information within an individual calendar entry. The access classification of an individual vCalendar entity is useful when measured along with the other security components of a calendar system (e.g., user authorization, access rights, access role, etc.). Hence, the semantics of the individual access classifications can not be completely defined by this specification. Additionally, due to the "blind" nature of most exchange processes using this specification, these entity classifications can not serve as an enforcement statement for a system receiving a vCalendar data stream. Rather, they provide a method for capturing the intention of the calendar owner for the access to the calendar entry. -The following is an example of this property: -CLASS:PUBLIC -The property can have the following values: - -Description -Property Value - -Indicates general, public access. -PUBLIC - -Indicates restricted, private access. -PRIVATE - -Indicates very restricted, confidential access. -CONFIDENTIAL - - -The default value for this property is PUBLIC. -Support for this property is optional for implementations conforming to this specification. -Date/Time Created -This property is identified by the property name DCREATED. This property specifies the date and time that the vCalendar entity was created within the originating calendar system. This is not generally the same date and time that the vCalendar object was created. The date and time value is the local or UTC based time expressed in the complete representation, basic format as specified in ISO 8601. The following is example of this property: -DCREATED:19960329T083000 -Support for this property is optional for implementations conforming to this specification. -Date/Time Completed -This property is identified by the property name COMPLETED. This property defines the date and time that the todo was actually completed. The date and time value is expressed in the complete representation, basic format as specified in ISO 8601. The time can either be in local or UTC based time. The following is an example of this property: -COMPLETED:19960401T235959 -Support for this property is mandatory for implementations conforming to this specification. -Description -This property is identified by the property name DESCRIPTION. This property provides a more complete description of the vCalendar entity, than that provided by the SUMMARY property. The following is an examples of the property with formatted line breaks in the property value: -DESCRIPTION;ENCODING=QUOTED-PRINTABLE:Meeting to provide technical= - review for "Phoenix" design. =0D=0A= - Happy Face Conference Room. Phoenix design team= - must attend this meeting. RSVP to team leader. -The following is an examples of the property with folding of long lines: -DESCRIPTION:Last draft of the new novel is to be completed - for the editor's proof today. -Support for this property is mandatory for implementations conforming to this specification. -Display Reminder -This property is identified by the property name DALARM. The property defines a display reminder for the vCalendar entity. A display reminder is an alarm that is popped up into the user interface or otherwise visually displayed for the event. -The value for the display reminder consists of the Run Time, or the date and time that the reminder is to be executed; Snooze Time, or the duration of time after the Run Time that the reminder is to be dormant prior to being repeated; Repeat Count, or the number of times that the reminder is to be repeated; and the Display String, or the text to be displayed when the reminder is executed. -The following is an example of this property: -DALARM:19960415T235000;PT5M;2;Your Taxes Are Due !!! -The Reminder properties are primarily provided as a means for allowing the capture of alarm information when accessing a calendar system. It may not be an appropriate property to send in an event or todo request. -Support for this property is optional for implementations conforming to this specification. -Due Date/Time -This property is identified by the property name DUE. This property defines the date and time that the todo is due to be completed. The date and time value is expressed in the complete representation, basic format as specified in ISO 8601. The time can either be in local or UTC based time. The following is an example of this property: -DUE:19960401T235959Z -Support for this property is mandatory for implementations conforming to this specification. -End Date/Time -This property is identified by the property name DTEND. This property defines the date and time that the event will end. The date and time value is expressed in the complete representation, basic format as specified in ISO 8601. The time can either be in local or UTC based time. Events may have an end date/time but no start date/time. In that case, the event does not take up any time. The following is an example of this property: -DTEND:19960401T235959Z -Support for this property is mandatory for implementations conforming to this specification. -Exception Date/Times -This property is identified by the property name EXDATE. This property defines the list of date/time exceptions for a recurring vCalendar entity. The date and time values is expressed in the complete representation, basic format as specified in ISO 8601. The times can either be in local or UTC based time. The number of date/time exceptions is specified by the Number Exceptions property. The following is an exampCONFIRMED;VALUE=URL;TYPE=VCARD: - http://www.xyz.com/~myvcard.vcf -Support for this property is optional for implementations conforming to this specification. -Audio Reminder -This property is identified by the property name AALARM. The property defines an audio reminder for the vCalendar entity. An audio reminder is an alarm that is sounded for the event. -The value for the audio reminder consists of the Run Time, or the date and time that the reminder is to be executed; Snooze Time, or the duration of time after the Run Time that the reminder is to be dormant prior to being repeated; Repeat Count, or the number of times that the reminder is to be repeated; and the Audio Content, or the digital sound to be played when the reminder is executed. -The following are some examples of this property: -AALARM;TYPE=WAVE;VALUE=URL:19960415T235959; ; ; file:///mmedia/taps.wav -AALARM;TYPE=WAVE;VALUE=CONTENT-ID:19960903T060000;PT15M;4; -The property has the following additional property parameters: - -Description -Property Parameter Values - -TYPE - - -Indicates the MIME basic audio content type. -PCM - -Indicates the WAVE format for audio content. -WAVE - -Indicates the AIFF format for audio content. -AIFF - - -The Reminder properties are primarily provided as a means for allowing the capture of alarm information when accessing a calendar system. It may not be an appropriate property to send in an event or todo request. -Support for this property is optional for implementations conforming to this specification. -Categories -This property is identified by the property name CATEGORIES. This property defines the categories for the vCalendar entity. More than one category may be specified as a list of categories separated by the Semi-Colon character (ASCII decimal 59). -The following are some examples of this property: -CATEGORIES:APPOINTMENT;EDUCATION -CATEGORIES:MEETING -Some of the possible values for this property might include the following: - -Some Possible -Property Values - -APPOINTMENT - -BUSINESS - -EDUCATION - -HOLIDAY - -MEETING - -MISCELLANEOUS - -PERSONAL - -PHONE CALL - -SICK DAY - -SPECIAL OCCASION - -TRAVEL - -VACATION - - -Support for this property is mandatory for implementations conforming to this specification. -Classification -This property is identified by the property name CLASS. This property defines the access classification for the vCalendar entity. -A calendar entity access classification is only one component of the general security system within a calendar application. It provides a method of capturing the scope of the access the calendar owner intends for information within an individual calendar entry. The access classification of an individual vCalendar entity is useful when measured along with the other security components of a calendar system (e.g., user authorization, access rights, access role, etc.). Hence, the semantics of the individual access classifications can not be completely defined by this specification. Additionally, due to the "blind" nature of most exchange processes using this specification, these entity classifications can not serve as an enforcement statement for a system receiving a vCalendar data stream. Rather, they provide a method for capturing the intention of the calendar owner for the access to the calendar entry. -The following is an example of this property: -CLASS:PUBLIC -The property can have the following values: - -Description -Property Value - -Indicates general, public access. -PUBLIC - -Indicates restricted, private access. -PRIVATE - -Indicates very restricted, confidential access. -CONFIDENTIAL - - -The default value for this property is PUBLIC. -Support for this property is optional for implementations conforming to this specification. -Date/Time Created -This property is identified by the property name DCREATED. This property specifies the date and time that the vCalendar entity was created within the originating calendar system. This is not generally the same date and time that the vCalendar object was crearty is identified by the property name PALARM. The property defines a procedure reminder for the vCalendar entity. A procedure reminder is a procedure, or application executable that will be run as an alarm for the event. -While this property has many useful purposes, implementors should be aware of the security implications of sending a vCalendar data stream containing this property. The security implications are similar to those associated with active messages within electronic mail. -The value for the procedure reminder consists of the Run Time, or the date and time that the reminder is to be executed; Snooze Time, or the duration of time after the Run Time that the reminder is to be dormant prior to being repeated; Repeat Count, or the number of times that the reminder is to be repeated; and the Procedure Name, or the path to the procedure to be run when the reminder is executed. -The following is an example of this property: -PALARM;VALUE=URL:19960415T235000;PT5M;2;file:///myapps/shockme.exe -The Reminder properties are primarily provided as a means for allowing the capture of alarm information when accessing a calendar system. It may not be an appropriate property to send in an event or todo request. -Support for this property is optional for implementations conforming to this specification. -Related To -This property is identified by the property name RELATED-TO. The property is used to represent relationships or references between this vCalendar entity and another. The property value consists of the persistent, globally unique identifier of another vCalendar entity. This value would be represented in a vCalendar data stream by the UID property. -A linked relationship can be specified by a series of entities that each, in turn, refer to their parent entity. A group relationship can be specified by a number of entities that all refer to one common parent entity. -Changes to a calendar entity referenced by this property may impact the related calendar entity. For example, if a group event changes it start or end date or time, then the related, dependent events will need to have their start and end dates changed in a corresponding way. This property is intended only to provide information on the relationship of calendar entities. It is up to the target calendar system to maintain this relationship. -The following is an example of this property: -RELATED-TO: -RELATED-TO:19960401-080045-4000F192713-0052 -Support for this property is optional for implementations conforming to this specification. -Recurrence Date/Times -This property is identified by the property name RDATE. This property defines the list of date/times for a recurring vCalendar entity. The date and time values is expressed in the complete representation, basic format as specified in ISO 8601. The times can either be in local or UTC based time. The number of recurring date/times is specified by the Number Recurrences property. The following is an example of this property: -RDATE:19960402T010000Z;19960403T010000Z;19960404T010000Z -Support for this property is optional for implementations conforming to this specification. -Recurrence Rule -This property is identified by the property name RRULE. This property defines a rule or repeating pattern for a recurring vCalendar entity, based on the Basic Recurrence Rule Grammar of XAPIA's CSA. The value for the property is a pattern specification for the recurrence. The following is an example of this property: -RRULE:W2 TU TH // Every other week, on Tuesday and Thursday -RRULE:D1 #10 // Daily for 10 occurrences -RRULE:YM1 6 7 #8 // Yearly in June and July for 8 occurrences -Support for this property is optional for implementations conforming to this specification. -Resources -This property is identified by the property name RESOURCES. This property defines the equipment or resources needed in the vCalendar event. -Some of the values that the property may have include the following: - -Some Possible -Property Values - -CATERING - -CHAIRS - -COMPUTER PROJECTOR - -EASEL - -OVERHEAD PROJECTOR - -SPEAKER PHONE - -TABLE - -TV - -VCR - -VIDEO PHONE - -VEHICLE - - -The following is an example of this property: -RESOURCES:EASEL;PROJECTOR;VCR -Support for this property is optional for implementations conforming to this specification. -Sequence Number -This property is identified by the property name SEQUENCE. This property defines the instance of the vCalendar entity in a sequence of revisions. When a vCalendar entity is created its sequence number is zero (ASCII decimal 48). It is incremented each time it is revised. The following is an example of this property: -SEQUENCE:1 -Support for this property is optional for implementations conforming to this specification. -Start Date/Time -This property is identified by the property name DTSTART. This property defines the date and time that the event will start. The date and time value is expressed in the complete representation, basic format as specified in ISO 8601. The time can either be in local or UTC based time. Events may have a start date/time but no end date/time. In that case, the event does not take up any time. The following is an example of this property: -DTSTART:19960401T235959 -Support for this property is mandatory for implementations conforming to this specification. -Status -This property is identified by the property name STATUS. This property defines the status associated with the vCalendar entity. This property can be used when the ATTENDEE property is either not supported or not needed. The following is an example of this property: -STATUS:TENTATIVE -The property can have the following values: - -Description -Property Value - -Indicates todo was accepted -ACCEPTED - -Indicates event or todo requires action -NEEDS ACTION - -Indicates event or todo was sent out. -SENT - -Indicates event is tentatively accepted -TENTATIVE - -Indicates event is confirmed -CONFIRMED - -Indicates event or todo has been declined -DECLINED - -Indicates todo has been completed -COMPLETED - -Indicates event or todo has been delegated -DELEGATED - - -The default value for this property is NEEDS ACTION. -Support for this property is mandatory for implementations conforming to this specification. -Summary -This property is identified by the property name SUMMARY. This property defines a short summary or subject of the vCalendar entity. The following is an example of this property: -SUMMARY:Department Party -Support for this property is mandatory for implementations conforming to this specification. -Time Transparency -This property is identified by the property name TRANSP. This property defines whether the event is transparent to free time searches. The value of this property is a number. A value of zero (ASCII decimal 48) guaranttes that the entry will blocks time and will be factored into a free time search. A value of one (ASCII decimal 49) specifies that the entry will not block time and will not be factored into a free time search. Any values greater than "1" will provide implementation specific transparency semantics. Some implementations may treat values greater than one as non-blocking or transparent events. Other implementations may use the numeric value to provide a layering of levels of transparency. The default value is zero (ASCII decimal 48), the event is not transparent and will block free time searches. The following is an example of this property: -TRANSP:0 -Support for this property is optional for implementations conforming to this specification. -Uniform Resource Locator -This property is identified by the property name URL. This property defines a Uniform Resource Locator for an Internet location that can be used to obtain real-time information associated with the vCalendar entity. Valid values for this property are a string conforming to the IETF RFC 1738, Uniform Resource Locators. The following is an example of this property: -URL:http://abc.com/pub/calendars/jsmith/mytime.or3 -Support for this property is optional for implementations conforming to this specification. -Unique Identifier -This property is identified by the property name UID. This property defines a persistent, globally unique identifier associated with the vCalendar entity. Some examples of forms of unique identifiers would include ISO 9070 formal public identifiers (FPI), X.500 distinguished names, machine-generated "random" numbers with a statistically high likelihood of being globally unique and Uniform Resource Locators (URL). If an URL is specified, it is suggested that the URL reference a service which can render an updated version of the vCalendar for the object. The following is an example of this property: -UID:19960401-080045-4000F192713-0052 -This property is an important method for group scheduling applications to match calendar entities with later modification or deletion requests. Calendaring applications that do not generate this property in vCalendar entities may be limiting their interoperability with other group scheduling applications. -Support for this property is optional for implementations conforming to this specification. -Miscellaneous Properties -Extensions -The clear-text encoding provides a "standard mechanism for doing non-standard things". This extension support is provided for implementers to "push the envelope" on the existing version of the specification. Extension properties are specified by property and/or property parameter names that have the initial sub-string of X- (the two character sequence: Capital X character followed by the Dash character). It is recommended that vendors concatenate onto this sentinel an added short sub-string to identify the vendor. This will facilitate readability of the extensions and minimize possible collision of names between different vendors. All vCalendar Readers are expected to be able to interpret the extension properties and property parameters but may ignore them. The following might be the ABC vendor's extension for an audio-clip form of subject property: -X-ABC-MMSUBJ;TYPE=WAV; VALUE=URL: http://load.noise.org/mysubj.wav -At present, there is no registration authority for names of extension properties. -Support for this property is mandatory for implementations conforming to this specification. However, an implementation may not be able to act on the extension property. Conformance only requires that an implementation be able to parse vCalendar data streams with extensions. The implementation need not act on them. -Formal Definition -The following modified Backus-Naur Notation (BNF) is provided to assist developers in building parsers for the clear-text encoding. - -This syntax is written according to the form described in RFC 822, -but it references just this small subset of RFC 822 literals: - CR = ; ( 15, 13.) - LF = ; ( 12, 10.) - CRLF = CR LF - SPACE = ; ( 40, 32.) - HTAB = ; ( 11, 9.) - -All literal property names are valid as upper, lower, or mixed case. - -ws = 1*(SPACE / HTAB) - ; "whitespace," one or more spaces or tabs - -wsls = 1*(SPACE / HTAB / CRLF) - ; whitespace with line separators - -value = 7bit / 8bit / quoted-printable / base64 - ; The value must be in the encoding type specified for the property value. - -7bit = <7bit us-ascii printable chars, excluding CR LF> - -8bit = - -quoted-printable = - -base64 = - ; the end of the text is marked with two CRLF sequences - ; this results in one blank line before the start of the next - ; property - -groups = groups "." word - / word - -word = - -vcal_file = [wsls] vcal [wsls] - -vcal = "BEGIN" [ws] ":" [ws] "VCALENDAR" [ws] 1*CRLF - calprop calentities [ws] *CRLF - "END" [ws] ":" [ws] "VCALENDAR" [ws] 1*CRLF - -calentities = calentities *CRLF calentity - / calentity - -calentity = evententity - / todoentity - -evententity = "BEGIN" [ws] ":" [ws] "EVENT" [ws] 1*CRLF - entprops [ws] *CRLF - "END" [ws] ":" [ws] "EVENT" [ws] 1*CRLF - -todoentity = "BEGIN" [ws] ":" [ws] "TODO" [ws] 1*CRLF - entprops [ws] *CRLF - "END" [ws] ":" [ws] "TODO" [ws] 1*CRLF - -calprops = calprops *CRLF calprop - / calprop - -calprop = "DAYLIGHT" - [params] ":" value CRLF - / "GEO" - [params] ":" value CRLF - / "PRODID" - [params] ":" value CRLF - / "TZ" - [params] ":" value CRLF - / "VERSION" - [params] ":" "1.0" CRLF - ; The VERSION calendar property MUST appear in the vCalendar object. - -entprops = entprops *CRLF entprop - / entprop - -entprop = [ws] simprop - [params] ":" value CRLF - / [ws] "AALARM" - [params] ":" aalarmparts CRLF - / [ws] "CATEGORIES" - [params] ":" 1*catvals CRLF - / [ws] "CLASS" - [params] ":" classvals CRLF - / [ws] "DALARM" - [params] ":" dalarmparts CRLF - / [ws] "EXDATE" - [params] ":" xdatevals CRLF - / [ws] "MALARM" - [params] ":" malarmparts CRLF - / [ws] "PALARM" - [params] ":" palarmparts CRLF - / [ws] "RDATE" - [params] ":" rdatevals CRLF - / [ws] "RESOURCES" - [params] ":" 1*resvals CRLF - / [ws] "STATUS" - [params] ":" statvals CRLF - -simprop = "ATTACH" / "ATTENDEE" / "DCREATED" / "COMPLETED" - / "DESCRIPTION" / "DUE" / "DTEND" / EXRULE / LAST-MODIFIED - / "LOCATION" / "RNUM" / "PRIORITY" / "RELATED-TO" / "RRULE" - / "SEQUENCE" / "DTSTART" / "SUMMARY" / "TRANSP" / "URL" / "UID" - /"X-" word - -aalarmparts = 0*3(strnosemi ";") strnosemi - ; runTime, snoozeTime, repeatCount, audioContent - -catvals = "APPOINTMENT" / "BUSINESS" / "EDUCATION" / "HOLIDAY" / "MEETING" - / "MISCELLANEOUS" / "PERSONAL" / "PHONE CALL" / "SICK DAY" - / "SPECIAL OCCASION" / "TRAVEL" / "VACATION" / "X-" word / value - -classvals = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / "X-" word / value - -dalarmparts = 0*3(strnosemi ";") strnosemi - ; runTime, snoozeTime, repeatCount, displayString - -xdatevals = 1*value - ; One or more date/time values - -malarmparts = 0*4(strnosemi ";") strnosemi - ; runTime, snoozeTime, repeatCount, addressString, noteString - -palarmparts = 0*3(strnosemi ";") strnosemi - ; runTime, snoozeTime, repeatCount, procedureName - -rdatevals = 1*value - ; One or more date/time values - -resvals = "CATERING" / "CHAIRS" / "EASEL" / "PROJECTOR" / "VCR" - / "VEHICLE" / "X-" word / value - -statvals = "ACCEPTED" / "NEEDS ACTION" / "SENT" / "TENTATIVE" - / "CONFIRMED" / "DECLINED" / "COMPLETED" / "DELEGATED" - / "X-" word / value - -params = ";" [ws] paramlist - -paramlist = paramlist [ws] ";" [ws] param - / param - -param = "TYPE" [ws] "=" [ws] ptypeval - / ["VALUE" [ws] "=" [ws]] pvalueval - / ["ENCODING" [ws] "=" [ws]] pencodingval - / "CHARSET" [ws] "=" [ws] charsetval - / "LANGUAGE" [ws] "=" [ws] langval - / "ROLE" [ws] "=" [ws] roleval - / "STATUS" [ws] "=" [ws] statuval - / "X-" word [ws] "=" [ws] word - / knowntype - -ptypeval = knowntype / "X-" word - -knowntype = "WAVE" / "PCM" / "VCARD" / "X-" word / value - -pvalueval = "INLINE" / "URL" / "CONTENT-ID" / "CID" / "X-" word - -pencodingval = "7BIT" / "8BIT" / "QUOTED-PRINTABLE" / "BASE64" / "X-" word - -charsetval = - -langval = - -roleval = "ATTENDEE" / "ORGANIZER" / "OWNER" / "X-" word - -statusval = "ACCEPTED" / "NEEDS ACTION" / "SENT" / "TENTATIVE" / "CONFIRMED" - / "DECLINED" / "COMPLETED" / "DELEGATED" / "X-" word - -strnosemi = *(*nonsemi ("\;" / "\" CRLF)) *nonsemi - ; To include a semicolon in this string, it must be escaped - ; with a "\" character. - -nonsemi = - - - -Section 3 : Internet Recommendations -[DS3] 1 -Recommended Practice With SMTP/MIME -The vCalendar information can be transported through SMTP/MIME based electronic mail services. Interoperability of vCalendar information over SMTP/MIME transports can be better assured by following a common set of recommended practices for encapsulation of the vCalendar. -Text/Plain Content Type -Without any change to existing SMTP or MIME compliant user agents, a vCalendar object can be included within Internet email messages. This might be the case for an existing, simple user agent such as a legacy SMTP mail system. While this approach provides for transport of vCalendars over SMTP services, it does not allow for the end user to take advantage of the full capabilities of either the vCalendar or Internet email (i.e., MIME) functionality. -The following demonstrates how a vCalendar can be included as a SMTP message made up of a RFC 822 message. This may be an initial method for incorporating vCalendar objects into SMTP messages. -Date: Thr, 25 Jan 96 0932 EDT -From: john.smith@host.com -Subject: Re: RFC822 vCalendar Example -Sender: john.smith@host.com -To: smartin@host2.com -Message-ID: - -Steve: Thanks for the call earlier today. Let's get together -tomorrow at 8:30 AM EST to discuss your new proposal. Here is -the meeting notice for your PIM. -BEGIN:VCALENDAR -VERSION:1.0 -BEGIN:VEVENT -CATEGORIES:MEETING -STATUS:TENTATIVE -DTSTART:19960401T033000Z -DTEND:19960401T043000Z -SUMMARY:Your Proposal Review -DESCRIPTION:Steve and John to review newest proposal material -CLASS:PRIVATE -END:VEVENT -END:VCALENDAR -The following example demonstrates how a vCalendar can be included as a separate text/plain content portion within current MIME user agents. -Date: Fri, 26 Jan 1996 07:53:00 -0500 -From: smartin@host2.com -Subject: RE: Text/Plain MIME vCalendar Example -To: john.smith@host.com -Mime-Version: 1.0 -Content-Type: multipart/mixed; boundary=vCalendar -Message-ID: - ---vCalendar -Content-Type:text/plain; charset=us-ascii -Content-Transfer-Encoding: 7bit -John: I can't make that meeting at 8:30. How about doing it -over lunch at noon? Here is an action item for the meeting. ---vCalendar -Content-Type:text/plain; charset=us-ascii; name="MARTIN.VCS" - -BEGIN:VCALENDAR -VERSION:1.0 -BEGIN:VTODO -SUMMARY:John to pay for lunch -DUE:19960401T083000Z -STATUS:NEEDS ACTION -END:VTODO -END:VCALENDAR - ---vCalendar- -Text/X-vCalendar Content Type -The vCalendar object can also be passed as a non-standard MIME media type. This would be useful in order to clearly identify the vCalendar object in an electronic mail message body part. A non-standard, vCalendar object should be identified as the MIME type/subtype "text/x-vCalendar". -The following example demonstrates how a vCalendar containing both an event and a todo can be included as a separate text/x-vCalendar content portion within a MIME user agent. -Date: Fri, 26 Jan 1996 07:53:00 -0500 -From: smartin@host2.com -Subject: RE: Text/X-vCalendar MIME vCalendar Example -To: john.smith@host.com -Mime-Version: 1.0 -Content-Type: multipart/mixed; boundary=vCalendar -Message-ID: - ---vCalendar -Content-Type:text/plain; charset=us-ascii -Content-Transfer-Encoding: 7bit -John: I can't make that meeting at 8:30. How about doing it -over lunch at noon? Here is an event for your PIM. I have -also given you an action item for the meeting. ---vCalendar -Content-Type:text/x-vCalendar; charset=us-ascii; name="MARTIN.VCS" - -BEGIN:VCALENDAR -VERSION:1.0 -BEGIN:VEVENT -CATEGORIES:MEETING -STATUS:NEEDS ACTION -DTSTART:19960401T073000Z -DTEND:19960401T083000Z -SUMMARY:Steve's Proposal Review -DESCRIPTION:Steve and John to review newest proposal material -CLASS:PRIVATE -END:VEVENT -BEGIN:VTODO -SUMMARY:John to pay for lunch -DUE:19960401T083000Z -STATUS:NEEDS ACTION -END:VTODO -END:VCALENDAR - ---vCalendar- -Recommended Practice With HTTP/HTML -The vCalendar specification provides a useful format for conveying calendaring and scheduling information between a Web browser and a HTTP server. Homepages can be used as a web-based document for publishing public events. The events can be easily formatted into vCalendar objects for transfer between the server and a requesting browser. The following examples are provided to illustrate possible scenarios where a non-standard "text/x-vCalendar" MIME type/subtype corresponding the vCalendar can be used to transfer calendaring and scheduling information across the World Wide Web. -The following example demonstrates how a vCalendar object can be included in an HTML document or Web page. This may be an initial method for incorporating vCalendar objects into Web pages. This sample assumes that the Web Browser is capable of handling the OBJECT HTML 3.2 element. - - -HTTP/Web vCalendar Example - - -

Special New Events

-

The latest events to be added to the calendar of activities are:

-
-
- -Your browser does not support OBJECT or the text/x-vCalendar MIME type/subtype. Get the events' data here and manually use it. - -
-
-
- -
-
- - -The following table demonstrates a simple HTTP transaction between client and server that retrieves a vCalendar object from the Web Server. The entries under Client and Server are the actual HTTP headers and data that might be exchanged. - -Client -Direction -Server - -GET martin.vcs HTTP/1.0 -User-Agent: MyBrowser/1.0 -Accept: text/html, text/plain, image/gif, image/jpeg, */* --> - - - -<- -200 OK -Server: YourServer/1.1 -Date: 25 Jan 96 0932 EDT -Content-Type: text/x-vCalendar -Content-Length: 257 - -BEGIN:VCALENDAR -BEGIN:VEVENT -CATEGORIES:MEETING -STATUS:TENTATIVE -DTSTART:19960401T033000Z -DTEND:19960401T043000Z -SUBJECT:Your Proposal Review -DESCRIPTION:Steve and John to review newest proposal material -CLASS:PRIVATE -END:VEVENT -END:VCALENDAR - - -The following example illustrates how a ìmonth at a glanceî type of information can be displayed on a homepage with the events or todos being links to vCalendar objects. - - -HTTP/Web vCalendar Example - -

Calendar/Events for August

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

Monday

 -

Tuesday

 -

Wednesday

 -

Thursday

 -

Friday

 -

Saturday - Sunday

29:30:31:1:2:3:
4:
5:6: -

Meeting w/Martin

7:8:9:10:
11:
12:13:14:15:16:17:
18:
19:20:21: -

vCal/vCard Seminar

22:23:24:
25:
26:27: -

versit Conference

28: -

versit Conference

-		29: -

versit Conference

30: -

versit Conference

31:
1:
-
-
- - - -Section 4 : UI Support Recommendations -[DS4] -When integrating vCalendar support into an application, an implementor needs to consider a number of user interface (UI) implications. Most applications provide some levels of support for interacting with other applications. This is usually accomplished in three ways. These include the File System, Clipboard, and Drag/Drop. The full potential of the vCalendar technology can be better utilized if an application supports the vCalendar in each of these UI actions. -File System -It is recommended that applications integrating support for vCalendar specification provide support for importing and exporting vCalendar objects from the operating system's file system. In operating systems that support file types, it is recommended that a file type of VCS be used to distinguish the vCalendar objects. Applications should make use of the file system capabilities to support the FileOpen and FileSaveAs, or their equivalent function, of a vCalendar object. -Clipboard -It is recommended that applications integrating support for the vCalendar specification provide UI capabilities for exchanging vCalendar objects through the operating system's clipboard. In operating systems that provide support for registering clipboard format types, it is recommended that the vCalendar object be registered using the string +//ISBN 1-887687-00-9::versit::PDI//vCalendar. This string is an ISO 9070 Formal Public Identifier (FPI). Applications should make use of the operating system's clipboard capability to support the Cut, Copy, and Paste, or their equivalent function, of a vCalendar object. Applications copying a vCalendar to the clipboard should put the vCalendar object on to the clipboard in both the vCalendar registered format and a plain text format. -Drag/Drop -It is recommended that applications integrating support for the vCalendar specification provide UI capabilities for exchanging vCalendar objects through the operating system's drag/drop capability. In operating systems that provide support for registering drag/drop object types, it is recommended that the vCalendar object be registered using the string +//ISBN 1-887687-00-9::versit::PDI//vCalendar. This string is an ISO 9070 Formal Public Identifier (FPI). Applications should make use of the operating system's drag/drop capability to enable the application to act as either a Drag Source and Drag Target, or their equivalent function, of a vCalendar object. Applications acting as a Drag Source should advertise their ability to render the vCalendar in both the vCalendar registered format and a plain text format. -Where an operating system environment provided multiple drag/drop protocols (e.g., file specification or clipboard based), it is recommended that an implementation provide negotiated support for both. For example, the file specification based drag/drop protocol is useful when dragging a desktop file object or a web based URL to a target application. In addition, the clipboard based drag/drop protocol is useful when dragging an event or todo from a source within an application to a target in another application. Supporting just one of these mechanisms will unnecessarily lead to a lack of interoperability between applications supporting this specifications. -Section 5 : Conformance -[DS5] -In order for a vCalendar Reader or Writer to conform to this specification it must meet the following criteria: -All properties must be implemented as defined. Statements elsewhere in the specification which describe features as optional or with exceptions take precedence over this criterion. -Character set support is up to the underlying implementation. However, support for the default character set (i.e., US ASCII) is required. Optionally, other character sets may be supported. -All extensions are optional. It is requested that any vendor-specific extensions include the vendor identification sub-string in the extension name. For example, the extension name X-ABC- for an extension created by the ABC organization. -All vendor defined extensions must declare the minimum conformance for that extension. - -Section 6 : Extended Recurrence Grammar -[DS6] - -The material in this section is included in this specification for reference information.It is copied, with permission of the XAPIA, from the XAPIA Calendaring and Sceduling API (CSA) Specification. This section defines an extended recurrence rule grammar that may be useful to implementations wishing to extend the capability of the basic recurrence rule defined by this specification. The material is equally applicable to extended support of the exception rules for repeating events. -Rule Introduction -A recurrence rule is made up of one or more recurrence frequencies. The frequencies express the granularity of the repeating event. The smallest granularity is based on minutes, the largest is based on years. Each frequency is immediately followed by an interval. The interval helps to define how often the frequency repeats (daily, every third day, etc): -D2 -Where, where D is the Frequency and 2 is the Interval. -M5 Repeat every five minutes -D1 Repeat daily -D2 Repeat every other day -D3 Repeat every third day -W1 Repeat weekly -W2 Repeat every other week -W3 Repeat every third week -The meaning of the interval depends on the frequency. As an example, the 5 in M5 is in minutes while the 3 in D3 is in days. -A rule can end with the duration symbol, #, followed by a number. This defines the number of times the repetition occurs (including the first time). -D2 #5 -Where, #5 is the Duration. In this example, the event occurs every other day and the duration indicates it occur 5 times. -There may be other information between the frequency and the duration that supplements the meaning of the rule: -D2 1200 1600 #5 -In this example, the event occurs every other day at 1200 and 1600 for a total of 10 occurrences. The duration controls the number of times the rule occurs. In this case the rule defines two occurrences (1200 and 1600) so a total of 10 (2 x 5) occurrences are generated. -A rule can be made up of several recurrence rules: -MP6 1+ MO #5 D2 1200 1600 #5 M5 #3 -This recurrence rule is made up of three recurrence rules. Every time the first rule executes (every 6 months) it executes the next rule to the right. If there is not a rule to the right an event is generated. In this case there is a daily frequency rule to the right of the monthly frequency rule. It executes twice a day; starting on the first Monday of the month. The daily frequency rule executes a total of ten times. Since there is a rule following the daily rule it executes it each time the daily frequency rule executes. The minute frequency rule is executed three times, every time the daily frequency rule executes, for a total of six times a day. The ROWSPAN="2" WIDTH="17%">19: -20: -21: -

vCal/vCard Seminar

-22: -23: -24: - - -25: - - -26: -27: -

versit Conference

-28: -

versit Conference

- -29: -

versit Conference

-30: -

versit Conference

-31: - - -1: - - - -
- - - -Section 4 : UI Support Recommendations -[DS4] -When integrating vCalendar support into an application, an implementor needs to consider a number of user interface (UI) implications. Most applications provide some levels of support for interacting with other applications. This is usually accomplished in three ways. These include the File System, Clipboard, and Drag/Drop. The full potential of the vCalendar technology can be better utilized if an application supports the vCalendar in each of these UI actions. -File System -It is recommended that applications integrating support for vCalendar specification provide support for importing and exporting vCalendar objects from the operating system's file system. In operating systems that support file types, it is recommended that a file type of VCS be used to distinguish the vCalendar objects. Applications should make use of the file system capabilities to support the FileOpen and FileSaveAs, or their equivalent function, of a vCalendar object. -Clipboard -It is recommended that applications integrating support for the vCalendar specification provide UI capabilities for exchanging vCalendar objects through the operating system's clipboard. In operating systems that provide support for registering clipboard format types, it is recommended that the vCalendar object be registered using the string +//ISBN 1-887687-00-9::versit::PDI//vCalendar. This string is an ISO 9070 Formal Public Identifier (FPI). Applications should make use of the operating system's clipboard capability to support the Cut, Copy, and Paste, or their equivalent function, of a vCalendar object. Applications copying a vCalendar to the clipboard should put the vCalendar object on to the clipboard in both the vCalendar registered format and a plain text format. -Drag/Drop -It is recommended that applications integrating support for the vCalendar specification provide UI capabilities for exchanging vCalendar objects through the operating system's drag/drop capability. In operating systems that provide support for registering drag/drop object types, it is recommended that the vCalendar object be registered using the string +//ISBN 1-887687-00-9::versit::PDI//vCalendar. This string is an ISO 9070 Formal Public Identifier (FPI). Applications should make use of the operating system's drag/drop capability to enable the application to act as either a Drag Source and Drag Target, or their equivalent function, of a vCalendar object. Applications acting as a Drag Source should advertise their ability to render the vCalendar in both the vCalendar registered format and a plain text format. -Where an operating system environment provided multiple drag/drop protocols (e.g., file specification or clipboard based), it is recommend days of the year. -Policies -The duration portion of a rule defines the total number of occurrences the rule generates, including the first event. As an example, the rule MP1 #3 W1 #3 starting on 1/1/94 would generate occurrences on 1/1/94, 1/8, 1/15, 2/5/94, 2/12, 2/19, 3/5/94, 3/12, 3/19. -The duration granularity is defined by the recurrence frequency immediately preceding the duration portion of the rule. For example, D1 #5 M15 #4 establishes a repeating event which happens for five days, four times per day. -Information, not contained in the rule, necessary to determine the next event time and date is derived from the event start time. -If no specific time is indicated in the recurrence rule it is taken from the event. -If an end date and a duration for the first rule in a nested rule are specified in the rule, then the recurring event ceases when the end date is reached or the number of occurrences indicated in the duration occur; whichever comes first. -If the duration or and end date is not established in the rule (e.g. ``D2'') the event occurs twice. That is D2 is equivalent to D2 #2. -If an endmark is used in a second or later rule of a nested rule, then the endmark is applied each time that rule is executed by the previous rule. YM1 1 6 #1 MD1 7$ 14 generates occurrences on 1/7 1/14 2/7 6/7 6/14 7/7. -If an endmark is used on a day of the week which is followed by several times (TU$ 1200 1300) or an endmark is used on a week occurrence that is followed by several weekdays (1+$ TU WE) the repeating event stops after the last time or week day in the list is executed. -If a rule has an ambiguity with respect to whether it will repeat on a specific day (12th of the month) vs on a relative day (2nd Friday of the month), the specific day takes precedence. The only exception to this policy is policy 14. -A duration of #0 means repeat this event forever. -Nested rules can not have a duration of 0. These are not allowed: - - YM1 6 #10 MP1 1+ SA #0 - D5 0600 0800 #5 M5 #0 -Using the occurrence specifier 5+ (e.g. 5th Friday) or 5- (e.g. 5th from last Friday) in a month that does not contain 5 weeks does not generate an event and thus does not count against the duration. The same applies to providing a day of the month that does not occur in the month: 31st. -The start time and date of an event must be in-sync with one of the event slots defined by its ocurrence rule. The following are not allowed: - - Initial Appt Time: 1300 - Recurrence Rule: D1 1400 #5 - Initial Appt Date: 7/1/94 (Friday) - Recurrence Rule: W1 MO TH #5 - -The following are acceptable: - - Initial Appt Time: 1300 - Recurrence Rule: D1 #5 or D1 1300 #5 - Initial Appt Date: 7/1/94 (Friday) - Recurrence Rule: W1 MO FR #5 or W1 #5 -If the optional information is missing from a frequency, the information is derived from the initial event. The used in the recurring event is a count from the beginning of the month to the event date and the used is the day of the week the initial event is scheduled to occur on. If the frequency does not list a week day (e.g. SU) in the rule, then the week day is established from the initial event information. As an example, the rule MP1 #3 used in an event with a start date of 7/20/94 (which is the third Wed of the month) will repeat on 8/17/94 which is the third Wed of the month. -The next event of a higher order rule does not execute until all the occurrences of a subrule are generated. If the next event of a higher order rule comes earlier in time than the last event of a subrule then the missed occurrences are not generated. In other words, subrules can not interleave occurrences with other subrules. The following results in indeterminate results because the minute subrule which begins to execute at 0630 generates occurrences beyond 0700 which is when the daily subrule begins executing again: - - D1 0630 0700 #4 M45 #5 - -Another incorrect rule: - - MP1 1+ 1- #3 W2 TU TH #5 - -Examples -Hourly for 12 hours (12:00, 1:00,...10:00, 11:00): -M60 #12 -Every 5 minutes for 1 hour (1:00, 1:05, 1:10,...1:50, 1:55): -M5 #12 -Daily, for 5 days: -D1 #5 -Daily, for 5 days repeating at 10 minute intervals for 1 hour. e.g. 6/1 at 12:00, 12:10, 12:20, ... 12:50; 6/2 at 12:00, 12:10, ... -D1 #5 M10 #6 -Every other day, two times: -D2 -Every other day at 6AM, 12noon and 3PM for a duration of two occurrences (span of three days). e.g. 6/1/94 at 6, 12 and 3PM and 6/3/94 at 6, 12 and 3PM. -D2 0600 1200 1500 #2 -Every other day at 6AM, 12noon and 3PM for a duration of three occurrences (a span of 5 days) stopping at noon on the fifth day. e.g. 6/1/94 at 6, 12, and 3, 6/3/94 at 6, 12 and 3 and 6/5/94 at 6 and 12. -D2 0600 1200$ 1500 #3 -Weekly at 6 AM (repeat every 15 minutes for an hour) for five weeks. e.g. 6:00, 6:15, 6:30, 6:45 on 6/1, 6/8, 6/15, 6/22 and 6/29. -D7 0600 #5 M15 #4 -Weekly at 6 AM (repeat every 15 minutes for an hour) for four weeks stopping at 6AM on the last event day. e.g. 6:00, 6:15, 6:30, 6:45 on 6/1, 6/8, 6/15 and 6:00 on 6/22. -D7 0600$ #4 M15 #4 -Weekly at 6 AM (repeat every 15 minutes for an hour) for 1 week stopping at 6:45AM. e.g. 6:00, 6:15, 6:30, 6:45 on 6/1. -D7 0600 #1 M15 #4 or -D7 #1 M15 #4 /* start time defined in appt entry */ or -M15 #4 /* start time defined in appt entry */ -Weekly for four weeks: -W1 #4 -Biweekly on Monday and Tuesday for 2 occurrences ending on a Monday: -W2 MO$ TU #2 -Weekly on Tuesday and Thursday at the time specified in the appt and repeated at time + 5 minutes: -W1 TU TH #3 M5 #2 -Weekly on Tuesday at 1200 and 1230 and Thursday at 1130 and 1200 for 10 weeks: -W1 TU 1200 TH 1130 #10 M30 or -W1 TU 1200 1230 TH 1130 1200 #10 -Weekly on Tuesday at 1200 and 1230 and Thursday at 1130 and 1200 for 10 weeks stopping on the last TU at 1230: -W1 TU$ 1200 TH 1130 #10 M30 or -W1 TU$ 1200 1230 TH 1130 1200 #10 -Weekly on Tuesday at 1200 and 1230 and Thursday at 1130 and 1200 for 10 weeks stopping on the last Tuesday at 1200: -W1 TU 1200$ 1230 TH 1130 1200 #10 -Monthly for 1 year: -MP1 #12 -Every other month on the first and last Friday of the month for 5 months: -MP2 1+ 1- FR #3 -Monthly on the second to the last day of the month for 5 months: -MD1 2- #5 -Monthly on the second to the last Monday of the month for 6 months: -MP1 2- MO #6 -Monthly on the third to the last day of the month for forever: -MD1 3- #0 -Monthly on the seventh to the last day of the month for 12 months: -MD1 7- #12 -Every other month on the first and last Friday of the month for 5 months stopping on the first Friday in the fifth month: -MP2 1+$ 1- FR #3 -Every six months on the first Monday of the month (repeat for 5 days) for 24 months: -MP6 1+ MO #5 D1 #5 -Every six months on the first Monday of the month (repeat every other day at 0600, 1200 and 1500 for 20 days) for 24 months: -MP6 1+ MO #5 D2 0600 1200 1500 #10 -Every six months on the first Monday of the month (repeat every other day at 0600, 1200 and 1500 for 20 days (repeat every 5 minutes for 3 times)) for 24 months: -MP6 1+ MO #5 D2 0600 1200 1500 #10 M5 #3 -Every six months on the first Monday of the month and the second to last Thursday of the month (repeat five minutes later) for 24 months: -MP6 1+ MO 2- TH #5 M5 #2 -Every six months on the first SU and MO at Noon, the second TU and WE at 1:00PM and the third TH and FR at 2:00PM: -MP6 1+ SU MO 1200 2+ TU WE 1300 3+ TH FR 1400 #4 -Every month on the 7th for 12 months: -MD1 7 #12 -Every month on the 7th, 14th, 21st, 28th for 12 months -MD1 7 14 21 28 #12 -Every month on the 10th and 20th for 24 months - daily for 5 days at 0600, 1200 and 1600 - every 15 minutes for an hour: -MD1 10 20 #24 D1 0600 1200 1600 #5 M15 #4 -Yearly on the 1st, 6th and 12 month on the first Monday and last Friday of the month: -YM1 1 6 12 #5 MP1 1+ MO 1- FR -Every other year on the 6th month (on the 12th day) for 5 years. -YM2 6 #3 MD1 12 -Yearly on the 7th 14th 21st and 28th of the 1st 3rd and 8th month and on the 7th and 14th of the 2nd, 4th and 9th months ending on the 4th month, 14th day of the 5th year: -YM1 1 3$ 8 #5 MD1 7 14$ 21 28 -Yearly on the 6th, 9th and 10th month on all weekends of the month: -YM1 6 9 10 #10 MP1 1+ 2+ 3+ 4+ 1- SA SU #1 -Yearly on the 6th month for 10 years, weekly on Tuesday and Thursday at 1100 and 1300 for 4 weeks: -YM1 6 #10 W1 TU TH 1100 1300 #4 -Yearly on the 1st, 100th, 200th and 300th day for 4 years: -YD1 1 100 200 300 #4 -Yearly on the 1st - 5th days and 100th - 104th days: -YD1 1 100 #5 D1 #5 -Yearly on the 1st - 5th days and 100th - 104th days stopping on 1/2/99: -YD1 1 100 D1 #5 19990102T000000Z - -[DS1]This entry/line in the section is assigned the style for the level 1 heading. This is done so that a section number can be given in the chapter title (style ìchptr_titleî) and so that ìheading 1î (more specifically, the format/heading numbering of the form ì1. Overviewî) can be ìskipped,î and the appropriate form for the next-level of heading can be properly displayed (eg., "1.1 Overview"). It is, and must be, formatted as "hidden text" prior to pagination and/or printing. -[DS2]This entry/line in the section is assigned the style for the level 1 heading. This is done so that a section number can be given in the chapter title (style ìchptr_titleî) and so that ìheading 1î (more specifically, the format/heading numbering of the form ì1. Overviewî) can be ìskipped,î and the appropriate form for the next-level of heading can be properly displayed (eg., "1.1 Overview"). It is, and must be, formatted as "hidden text" prior to pagination and/or printing. -[DS3]This entry/line in the section is assigned the style for the level 1 heading. This is done so that a section number can be given in the chapter title (style ìchptr_titleî) and so that ìheading 1î (more specifically, the format/heading numbering of the form ì1. Overviewî) can be ìskipped,î and the appropriate form for the next-level of heading can be properly displayed (eg., ì1.1 Overview"). It is, and must be, formatted as "hidden text" prior to pagination and/or printing. -[DS4]This entry/line in the section is assigned the style for the level 1 heading. This is done so that a section number can be given in the chapter title (style ìchptr_titleî) and so that ìheading 1î (more specifically, the format/heading numbering of the form ì1. Overviewî) can be ìskipped,î and the appropriate form for the next-level of heading can be properly displayed (eg., ì1.1 Overview"). It is, and must be, formatted as "hidden text" prior to pagination and/or printing. -[DS5]This entry/line in the section is assigned the style for the level 1 heading. This is done so that a section number can be given in the chapter title (style ìchptr_titleî) and so that ìheading 1î (more specifically, the format/heading numbering of the form ì1. Overviewî) can be ìskipped,î and the appropriate form for the next-level of heading can be properly displayed (eg., ì1.1 Overview"). It is, and must be, formatted as "hidden text" prior to pagination and/or printing. -[DS6]This entry/line in the section is assigned the style for the level 1 heading. This is done so that a section number can be given in the chapter title (style ìchptr_titleî) and so that ìheading 1î (more specifically, the format/heading numbering of the form ì1. Overviewî) can be ìskipped,î and the appropriate form for the next-level of heading can be properly displayed (eg., ì1.1 Overviewî). It is, and must be, formatted as "hidden text" prior to pagination and/or printing. - - - - - - - -Copyrights - - - - - - - -Trademarks -vi vCalendar Specification, v0.4 - -Reference Information v - -versit Update vii - - - - - - - -4 vCalendar Specification, v0.4 - -Contents ix - - - - -Section 1 : Introduction 3 - - diff --git a/etc/vcard-21.2.ps b/etc/vcard-21.2.ps deleted file mode 100644 index 351b710..0000000 Binary files a/etc/vcard-21.2.ps and /dev/null differ diff --git a/etc/vcard-21.4.ps b/etc/vcard-21.4.ps deleted file mode 100644 index f7f92ed..0000000 Binary files a/etc/vcard-21.4.ps and /dev/null differ diff --git a/etc/vcard-21.bnf b/etc/vcard-21.bnf deleted file mode 100644 index 56605b4..0000000 --- a/etc/vcard-21.bnf +++ /dev/null @@ -1,115 +0,0 @@ -Formal Definition - -The following modified Backus-Naur Notation (BNF) is provided to assist -developers in building parsers for the vCard. - -This syntax is written according to the form described in RFC 822, but it -references just this small subset of RFC 822 literals: - - CR = ; ( 15, 13.) - LF = ; ( 12, 10.) - CRLF = CR LF - SPACE = ; ( 40, 32.) - HTAB = ; ( 11, 9.) - -All literal property names are valid as upper, lower, or mixed case. - -ws = 1*(SPACE / HTAB) - ; "whitespace," one or more spaces or tabs - -wsls = 1*(SPACE / HTAB / CRLF) - ; whitespace with line separators - -word = - -groups = groups "." word - / word - -vcard_file = [wsls] vcard [wsls] - -vcard = "BEGIN" [ws] ":" [ws] "VCARD" [ws] 1*CRLF - items *CRLF "END" [ws] ":" [ws] "VCARD" - -items = items *CRLF item - / item - ; these may be "folded" - -item = [groups "."] name [params] ":" value CRLF - / [groups "."] "ADR" [params] ":" addressparts CRLF - / [groups "."] "ORG" [params] ":" orgparts CRLF - / [groups "."] "N" [params] ":" nameparts CRLF - / [groups "."] "AGENT" [params] ":" vcard CRLF - ; these may be "folded" - -name = "LOGO" / "PHOTO" / "LABEL" / "FN" / "TITLE" - / "SOUND" / "VERSION" / "TEL" / "EMAIL" / "TZ" / "GEO" / "NOTE" - / "URL" / "BDAY" / "ROLE" / "REV" / "UID" / "KEY" - / "MAILER" / "X-" word - ; these may be "folded" - -value = 7bit / quoted-printable / base64 - -7bit = <7bit us-ascii printable chars, excluding CR LF> - -8bit = - -quoted-printable = - -base64 = - ; the end of the text is marked with two CRLF sequences - ; this results in one blank line before the start of the next property - -params = ";" [ws] paramlist - -paramlist = paramlist [ws] ";" [ws] param - / param - -param = "TYPE" [ws] "=" [ws] ptypeval - / "VALUE" [ws] "=" [ws] pvalueval - / "ENCODING" [ws] "=" [ws] pencodingval - / "CHARSET" [ws] "=" [ws] charsetval - / "LANGUAGE" [ws] "=" [ws] langval - / "X-" word [ws] "=" [ws] word - / knowntype - -ptypeval = knowntype / "X-" word - -pvalueval = "INLINE" / "URL" / "CONTENT-ID" / "CID" / "X-" word - -pencodingval = "7BIT" / "8BIT" / "QUOTED-PRINTABLE" / "BASE64" / "X-" word - -charsetval = - -langval = - -addressparts = 0*6(strnosemi ";") strnosemi - ; PO Box, Extended Addr, Street, Locality, Region, Postal Code, - Country Name - -orgparts = *(strnosemi ";") strnosemi - ; First is Organization Name, remainder are Organization Units. - -nameparts = 0*4(strnosemi ";") strnosemi - ; Family, Given, Middle, Prefix, Suffix. - ; Example:Public;John;Q.;Reverend Dr.;III, Esq. - -strnosemi = *(*nonsemi ("\;" / "\" CRLF)) *nonsemi - ; To include a semicolon in this string, it must be escaped - ; with a "\" character. - -nonsemi = - -knowntype = "DOM" / "INTL" / "POSTAL" / "PARCEL" / "HOME" / "WORK" - / "PREF" / "VOICE" / "FAX" / "MSG" / "CELL" / "PAGER" - / "BBS" / "MODEM" / "CAR" / "ISDN" / "VIDEO" - / "AOL" / "APPLELINK" / "ATTMAIL" / "CIS" / "EWORLD" - / "INTERNET" / "IBMMAIL" / "MCIMAIL" - / "POWERSHARE" / "PRODIGY" / "TLX" / "X400" - / "GIF" / "CGM" / "WMF" / "BMP" / "MET" / "PMB" / "DIB" - / "PICT" / "TIFF" / "PDF" / "PS" / "JPEG" / "QTIME" - / "MPEG" / "MPEG2" / "AVI" - / "WAVE" / "AIFF" / "PCM" - / "X509" / "PGP" - - diff --git a/etc/vcard-21.doc b/etc/vcard-21.doc deleted file mode 100644 index f92a438..0000000 Binary files a/etc/vcard-21.doc and /dev/null differ diff --git a/etc/vcard-21.pdf b/etc/vcard-21.pdf deleted file mode 100644 index 3a0ee1d..0000000 Binary files a/etc/vcard-21.pdf and /dev/null differ diff --git a/etc/vcard-21.ps b/etc/vcard-21.ps deleted file mode 100644 index cb21c41..0000000 Binary files a/etc/vcard-21.ps and /dev/null differ diff --git a/etc/vcard-21.txt b/etc/vcard-21.txt deleted file mode 100644 index 6d3dd45..0000000 --- a/etc/vcard-21.txt +++ /dev/null @@ -1,1622 +0,0 @@ -vCard -The Electronic Business Card -Version 2.1 - -A versit Consortium Specification -September 18, 1996 - - -Copyrights - -© 1996, International Business Machines Corp., Lucent Technologies, Inc., and Siemens. All rights reserved. - -Permission is granted to copy and distribute this publication provided that it -is reproduced in its entirety without modification and includes the above -copyright notice and this permission notice. No licenses, express or implied, -are granted with respect to any of the technology described in this -publication. International Business Machines Corp., Lucent Technologies, Inc., -and Siemens retain all their intellectual property rights in the technology -described in this publication. Even though International Business Machines -Corp., Lucent Technologies, Inc., and Siemens have reviewed this specification, -INTERNATIONAL BUSINESS MACHINES CORP., LUCENT TECHNOLOGIES, INC, AND SIEMENS, -MAKE NO WARRANTY OR REPRESENTATION, EITHER EXPRESS OR IMPLIED, WITH RESPECT TO -THIS PUBLICATION, ITS QUALITY OR ACCURACY, NONINFRINGEMENT, MERCHANTABILITY, OR -FITNESS FOR A PARTICULAR PURPOSE. AS A RESULT, THIS SPECIFICATION IS DELIVERED -"AS IS" AND THE READER ASSUMES THE ENTIRE RISK AS TO ITS QUALITY, ACCURACY OR -SUITABILITY FOR ANY PARTICULAR PURPOSE.. IN NO EVENT WILL INTERNATIONAL -BUSINESS MACHINES CORP., LUCENT TECHNOLOGIES, INC, AND SIEMENS, BE LIABLE FOR -DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES RESULTING FROM -ANY DEFECT OR INACCURACY IN THIS PUBLICATION, EVEN IF ADVISED OF THE -POSSIBILITY OF SUCH DAMAGES. This publication is provided with RESTRICTED -RIGHTS. Use, duplication, or disclosure by the Government are subject to -restrictions set forth in DFARS 252.227-7013 or 48 CFR 52.227-19, as -applicable. - - -Trademarks -versit, the versit logo, versitcard, vCard, and vCalendar are trademarks of Apple Computer, Inc., AT&T Corp., International Business Machines Corp., and Siemens. -Apple, is a trademarks of Apple Computer, Inc. registered in the U.S. and other countries. -AT&T and ATTMail are registered trademarks of AT&T Corp. -IBM, IBM Mail, and OS/2 are registered trademarks of International Business Machines Corporation. -America Online is a registered trademark of America Online, Inc. -CompuServe, CompuServe Information Services are registered trademarks of Compuserve Incorporated. -MCIMail is a registered trademark of MCI Communications Corporation. -Microsoft is a registered trademark, and Microsoft Windows is a trademark of Microsoft Corporation. -Prodigy is a registered trademark of Prodigy Services Company. -Unicode is a registered trademark of Unicode, Inc. - - -Contributors -Roland Alden -Greg Ames, Ames & Associates -Masanari Arai, Puma Technologies -Stephen W. Bartlett -Donal Carroll -Liang-Jye Chang, Starfish Software -Frank Dawson, IBM Corporation -Ken Dobson, IntelliLink Inc. -Scott Feldstein, Nimble Software, Inc. -Anik Ganguly, OnTime/Division of FTP Software. -Beijing Goo, Microsoft -Arvind K. Goyal, Lotus Development Corporation -Gary Hand, IBM Corporation -Tim Howes, Netscape Communications Corporation -Mark Joseph, Attachmate Corporation -Kerry Kelly, Now Software, Inc. -Phac Letuan, Apple Computer, Inc. -Pat Megowan, Counterpoint Sytems Foundry Inc. -Tohri Mori, IBM Japan/Salutation Consortium -Ravi Pandya, NetManage, Inc. -Geoff Ralston, Four11 Corporation -Steven Rummel, Lucent Technologies -Michael Santullo, Four11 Corporation -Vinod Seraphin, Lotus Development Corporation -Dexter Seely, Corex Technologies, Inc. -Vlad Shmunis, Ring Zero Systems Inc. -Dean Stevens, Now Software, Inc. -Michelle Watkins, Netscape Communications Corporation -Horst Widlewski, Siemens - - -Reference Information -The cited references contain provisions which, through reference in this specification, constitute provisions of this specification. At the time of publication, the indicated versions in the following references were valid. Parties to agreements based on this specification are encouraged to research the possibility of revised standards. -* ANSI X3.4-1977, Code for Information Interchange, American National Standards Institute, 1977. -* CCITT (ITU) Recommendation E.163, Numbering Plan for The International Telephone Service, CCITT Blue Book, Fascicle II.2, pp. 128-134, November, 1988. -* CCITT (ITU) Recommendation G.721, 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM), CCITT Red Book, Fascicle III.4, November, 1988. -* CCITT (ITU) Recommendation X.121, International Numbering Plan for Public Data Networks, CCITT Blue Book, Fascicle VIII.3, pp. 317-332, November, 1988. -* CCITT (ITU) Recommendations X.500-X.521, Data Communication Networks: Directory, CCITT Blue Book, Fascicle VIII.8, November, 1988. -* CCITT Recommendation X.520, The Directory-Selected Attribute Types, 1988. -* CCITT Recommendation X.521, The Directory-Selected Object Classes, 1988. -* IETF RFC 1738, Universal Resource Locator, December 1994. -* IETF Network Working Group RFC 1766, Tags for the Identification of Languages, March 1995. -* IETF Network Working Group Draft, A MIME Content-Type for Directory Information, January 1996. Available from the University of Michigan, 535 W. William St., Ann Arbor, MI 48103-4943, FTP://ds.internic.net/Internet-Drafts/draft-ietf-asid-mime-direct-01.txt. -* IETF Network Working Group Draft, An Application/Directory MIME Content-Type Electronic Business Card Profile, May 1996. Available FTP://ds.internic.net/Internet-Drafts/draft-ietf-asid-mime-vcard-00.txt. -* IETF Network Working Group Draft, UTF-8, A Transformation Format of UNICODE and ISO 10646, July 1996. Available from FTP://ds.internic.net/Internet-Drafts/draft-yergeau-utf8-01.txt. -* ISO 639, Code for The Representation of names of languages, International Organization for Standardization, April, 1988. -* ISO 3166, Codes for The Representation of names of countries, International Organization for Standardization, December, 1993. -* ISO 8601, Data elements and interchange formats-Information interchange-Representation of dates and times, International Organization for Standardization, June, 1988. -* ISO 8601, Technical Corrigendum 1, Data elements and interchange formats-Information interchange-Representation of dates and times, International Organization for Standardization, May, 1991. -* ISO 8859-1, Information Processing-8-Bit single-byte coded graphic character sets-Part 1: Latin Alphabet No. 1, International Organization for Standardization, February, 1987. -* ISO 9070, Information Processing-SGML support facilities-Registration Procedures for Public Text Owner Identifiers, 1990-02-01.[DS1] -ï ISO/IEC 9070, Information TechnologyóSGML Support FacilitiesóRegistration Procedures for Public Text Owner Identifiers, Second Edition, International Organization for Standardization, April, 1991. -ï ISO/IEC 11180, Postal addressing, International Organization for Standardization, 1993. -ï Appleís Representation of a Canonical Static DeviceID in The Telephony Suite, version 1.0, Apple Computer, Inc., 1993. -* Microsoft TAPI in Microsoft Windows 3.1 Telephony Programmers' Guide, version 1.0, Microsoft Corporation, 1993. -* RFC1521, MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies, Network Working Group, September, 1993. -* The Unicode Standard, Version 1.1: Version 1.0, Volume 1 (ISBN 0-201-56788-1), version 1.0, volume 2 (ISBN 0-20-60845-6) and Unicode Technical Report #4, The Unicode Standard, version 1.1, The Unicode Consortium, October, 1991. Both references to be published by Addison-Wesley. - - -versit Update -versit is a multivendor development initiative of the communication and computer industries, founded by Apple, AT&T, IBM and Siemens. The versit parties believe that great potential exists in improving the nature of communications in the business world-permitting companies to better manage their quality, productivity, customer satisfaction and cost of operations, while expanding the market opportunities for a variety of product and service vendors. versit parties will jointly define and support open specifications that facilitate and promote the interoperability of advanced personal information and communication devices, networks and services. -The versit vision is to enable diverse communication and computing devices, applications and services from competing vendors to interoperate in all environments. Through developing a series of specifications for interoperability among diverse communications and computing devices, applications, networks and services, versit 's vision will become a reality. -versit 's primary development areas are in: -* Personal Data Interchange (PDI) -* Computer Telephone Integration (CTI) -* Conferencing and Messaging (C&M) -* Wired and Wireless connectivity -versit specifications are directed at both the decision makers and the implementation teams of: -* Equipment Manufacturers -* Independent Software Vendors -* Information Service Providers -* Online Service Providers -* Software Houses -* Users -versit specifications are made available to any interested party. In turn, versit encourages the support of our goals by soliciting feedback on versit specifications. - -All comments relating to versit or the material within this specification should be submitted to: -versit -(800) 803-6240 -+1 (201) 327-2803 (Outside USA) -pdi@versit.com -http://www.versit.com/pdi - - -Contents -Section 1 : Introduction -1.1 Overview -1.2 Scope -1.3 Contents -1.4 Definitions and Abbreviations -Section 2 : vCard Specificiation -2.1 Encoding Characteristics -2.1.1 vCard Object -2.1.2 Property -2.1.3 Delimiters -2.1.4 Grouping -2.1.4.1 vCard Grouping -2.1.4.2 Property Grouping -2.1.5 Encodings -2.1.6 Character Set -2.1.7 Language -2.1.8 Value Location -2.1.9 Binary Values -2.2 Identification Properties -2.2.1 Formatted Name -2.2.2 Name -2.2.3 Photograph -2.2.3.1 Photo Format Type -2.2.4 Birthdate -2.3 Delivery Addressing Properties -2.3.1 Delivery Address -2.3.1.1 Delivery Address Type -2.3.2 Delivery Label -2.3.2.1 Delivery Label Type -2.4 Telecommunications Addressing Properties -2.4.1 Telephone Number -2.4.1.1 Telephone Type -2.4.2 Electronic Mail -2.4.2.1 Electronic Mail Type -2.4.3 Mailer -2.4.4 Geographical Properties -2.4.5 Time Zone -2.4.6 Geographic Position -2.5 Organizational Properties -2.5.1 Title -2.5.2 Business Category -2.5.3 Logo -2.5.3.1 Logo Format Type -2.5.4 Agent -2.5.5 Organization Name and Organizational Unit -2.6 Explanatory Properties -2.6.1 Comment -2.6.2 Last Revision -2.6.3 Sound -2.6.3.1 Sound Digital Audio Type -2.6.4 Uniform Resource Locator -2.6.5 Unique Identifier -2.6.6 Version -2.7 Security Properties -2.7.1 Public Key -2.7.2 Key Type -2.8 Miscellaneous Properties -2.8.1 Extensions -2.9 Formal Definition -Section 3 : Internet Recommendations -3.1 Recommended Practice with SMTP/MIME -3.1.1 Text/Plain Content Type -3.1.2 Text/X-vCard Content Type -3.1.3 Application/Directory Content Type -3.2 Recommended Practice with HTTP/HTML -3.2.1 Form Element Usage -3.2.2 Mapping To INPUT Element Attribute Names -3.2.3 Example HTML Code -Section 4 : UI Support Recommendations -4.1 File System -4.2 Clipboard -4.3 Drag/Drop -Section 5 : Conformance - - - -Section 1 : Introduction -[DS2] -Personal Data Interchange (PDI) occurs every time two or more individuals communicate, in either a business or personal context, face-to-face, or across space and time. Such interchanges frequently include the exchange of informal information, such as business cards, telephone numbers, addresses, dates and times of appointments, etc. Augmenting PDI with electronics and telecommunications can help ensure that information is quickly and reliably communicated, stored, organized and easily located when needed. -Personal information, by nature, is complex and diverse. Currently, proprietary standards exist to structure some types of PDI information, but no single, open specification comprehensively addresses the needs of collecting and communicating PDI information across many common communication channels such as telephones, voice-mail, e-mail, and face-to-face meetings. versit is developing a comprehensive family of PDI technologies based on open specifications and interoperability agreements to help meet this technology need. -Overview -This specification defines a format for an electronic business card, or vCard. The format is suitable as an interchange format between applications or systems. The format is defined independent of the particular method used to transport it. The transport for this exchange might be a file system, point-to-point asynchronous communication, wired-network transport, or some form of unwired transport. -A vCard is a data stream consisting of one or more vCard objects. The individual vCard definitions can be identified and parsed within the datastream. The vCard data stream may exist as a persistent form in a file system, document management system, network connection between two network endpoints, or in any other digital transport that has an abstraction of a stream of bytes. -Conceptually, a vCard Writer creates vCard data streams and a vCard Reader interprets vCard data streams. The vCard Reader and Writer may be implemented as a single application or as separate applications. It is not the intent of this specification to define the implementation of these processes beyond some fundamental capabilities related to the format of the vCard data stream and a common set of conformance requirements . -This specification provides for a clear-text encoding that is intended to be based on the syntax used by the MIME specification (RFC 1521). -The encoding of this specification can be used in environments which are constrained to 7-bit transfer encodings, short line lengths, and low bandwidth. In addition, the encoding is simple in order to facilitate the implementation of reader and writer applications on small platforms, such as Personal Digital Assistants (PDA), cellular telephones, or alphanumeric pagers. -Scope -The vCard is intended to be used for exchanging information about people and resources. In today's business environment, this information is typically exchanged on business cards. It is appropriate, then that this specification define this information in terms of a paradigm based on an electronic business card object. -The ultimate destination for this information is often a collection of business cards, Rolodex® file, or electronic contact manager. Prior to the introduction of the vCard specification, users of such applications typically had to re-key the original information, often transcribing it from paper business cards. With the advent of the vCard specification, this information can be exchanged in an automated fashion. -The basis for the data types supported by this specification have their origin in openly defined, international standards and in additional capabilities based on enhancements suggested by the demonstration of the exchange of prototypical vCards using the Internet based World-Wide-Web, Infra-red data transport, and simultaneous voice and data (SVD) modems. -The "person" object defined by the CCITT X.500 Series Recommendation for Directory Services was the primary reference for the properties that are defined by this specification. Every attempt was made to make it possible to map the X.520/X.521 attributes and objects into and out of an instance of a vCard. The vCard specification has extended the capabilities that have been defined within the CCITT X.500 Series Recommendation to allow the exchange of additional information often recorded on business cards and electronic contact managers. For example, this specification provides support for exchanging graphic images representing company logos, photographs of individuals, geo-positioning information, and other extensions to properties defined by the X.500 Recommendation. -The specification of all date and time values are defined in terms of the ISO 8601 standard for representation of dates and times. ISO 8601 supersedes all other international standards defined at the time this specification was drafted. -The paradigm of an electronic business card is related to the concepts of an entry in a LAN/WAN directory or an electronic mail address book or distribution list. However, the requirements of the electronic business card go beyond the definitions of a "person" object found in either the CCITT X.500 Series Recommendation, network directory services, or electronic mail address book products. The vCard specification is needed to address the requirements for an interchange format for the "person" personal data type or object. -Personal data applications such as Personal Information Managers (PIM) often provide an import/export capability using Comma Separated Value (CSV) or Tab Delimited Files (TDF) formats. However, these solutions do not preserve the intent of the originating application. When a CSV and TDF format is used by a PIM, the meta-data or semantics of the originating object are only apparent to a similar version of the originating application. Exchange of data between such applications is another important application of an industry-standard specification for an electronic business card interchange format, such as the vCard specification. -Contents -This specification is separated into eight sections: -* "Section 1 : Introduction" introduces PDI and the vCard specification with an overview, scope statement and section on definitions and abbreviations. -* "Section 2 : vCard Specification" defines the semantics and syntax for the vCard. -* "Section 3 : Internet Recommendations" specifies a set of guidelines to facilitate the exchange of vCard objects over Internet protocols such as HTTP using HTML and SMTP using MIME. -* "Section 4 : UI Support Recommendations" specifies a set of guidelines to facilitate the exchange of vCard objects at the desktop user interface using the file system, clipboard and drag/drop capabilities of the operating system. -* "Section 5 : Conformance" defines minimum conformance requirements to consider while developing support for this vCard specification. -Definitions and Abbreviations -Definitions and abbreviations used within this specification follow. -Electronic Business Card: Also known as vCard. -FPI: Formal Public Identifier. A string expression that represents a public identifier for an object. FPI syntax is defined by ISO 9070. -GUID: Globally Unique IDentifier -Internet: A WAN connecting thousands of disparate networks in industry, education, government, and research. The Internet uses TCP/IP as the standard for transmitting information. -ISO: Organization for International Standardization; a worldwide federation of national standards bodies (ISO Member bodies). -MIME: Multipurpose Internet Mail Extensions, as defined in RFC1521. -PDA: Personal Digital Assistant computing device -PDI: Personal Data Interchange, a collaborative application area which involves the communication of data between people who have a business or personal relationship, but do not necessarily share a common computing infrastructure. -PIM: Personal Information Manager -RFC#### documents: Internet "Request For Comment" documents (i.e., RFC822, RFC1521, etc.). -URL: Uniform Resource Locator; a string expression that can represent any resource on the Internet or local system. RFC 1738 defines the syntax for an URL. -UTC: Universal Time Coordinated; also known as UCT, for Universal Coordinated Time. -vCard: The generic term for an electronic, virtual information card that can be transferred between computers, PDAs, or other electronic devices through telephone lines, or e-mail networks, or infrared links. How, when, why, and where vCard are used depends on the applications developed utilizing a vCard. -versitcard: a vCard. -WAN: Wide-Area Network - - -Section 2 : vCard Specificiation -[DS3] -This section defines the semantics and syntax for the vCard. -A vCard is a collection of one or more properties. A property is a uniquely named value. A set of properties can be grouped within a vCard. For example, the properties for a telephone number and comment can be grouped in order to preserve the coupling of the annotation with the telephone number. In addition to property groupings, a vC. versit is developing a comprehensive family of PDI technologies based on open specifications and interoperability agreements to help meet this technology need. -Overview -This specification defines a format for an electronic business card, or vCard. The format is suitable as an interchange format between applications or systems. The format is defined independent of the particular method used to transport it. The transport for this exchange might be a file system, point-to-point asynchronous communication, wired-network transport, or some form of unwired transport. -A vCard is a data stream consisting of one or more vCard objects. The individual vCard definitions can be identified and parsed within the datastream. The vCard data stream may exist as a persistent form in a file system, document management system, network connection between two network endpoints, or in any other digital transport that has an abstraction of a stream of bytes. -Conceptually, a vCard Writer creates vCard data streams and a vCard Reader interprets vCard data streams. The vCard Reader and Writer may be implemented as a single application or as separate applications. It is not the intent of this specification to define the implementation of these processes beyond some fundamental capabilities related to the format of the vCard data stream and a common set of conformance requirements . -This specification provides for a clear-text encoding that is intended to be based on the syntax used by the MIME specification (RFC 1521). -The encoding of this specification can be used in environments which are constrained to 7-bit transfer encodings, short line lengths, and low bandwidth. In addition, the encoding is simple in order to facilitate the implementation of reader and writer applications on small platforms, such as Personal Digital Assistants (PDA), cellular telephones, or alphanumeric pagers. -Scope -The vCard is intended to be used for exchanging information about people and -resources. In today's business environment, this information is typically -exchanged on business cards. It is appropriate, then that this specification -define this information in terms of a paradigm based on an electronic business -card object. - -The ultimate destination for this information is often a collection of business -cards, Rolodex® file, or electronic contact manager. Prior to the introduction -of the vCard specification, users of such applications typically had to re-key -the original information, often transcribing it from paper business cards. With -the advent of the vCard specification, this information can be exchanged in an -automated fashion. - -The basis for the data types supported by this specification have their origin in openly defined, international standards and in additional capabilities based on enhancements suggested by the demonstration of the exchange of prototypical vCards using the Internet based World-Wide-Web, Infra-red data transport, and simultaneous voice and data (SVD) modems. - -The "person" object defined by the CCITT X.500 Series Recommendation for Directory Services was the primary reference for the properties that are defined by this specification. Every attempt was made to make it possible to map the X.520/X.521 attributes and objects into and out of an instance of a vCard. The vCard specification has extended the capabilities that have been defined within the CCITT X.500 Series Recommendation to allow the exchange of additional information often recorded on business cards and electronic contact managers. For example, this specification provides support for exchanging graphic images representing company logos, photographs of individuals, geo-positioning information, and other extensions to properties defined by the X.500 Recommendation. - -The specification of all date and time values are defined in terms of the ISO 8601 standard for representation of dates and times. ISO 8601 supersedes all other international standards defined at the time this specification was drafted. - -The paradigm of an electronic business card is related to the concepts of -a - - -Quoted-Printable lines of text must also be limited to less than 76 characters. -The 76 characters does not include the CRLF (RFC 822) line break sequence. For -example a multiple line LABEL property value of: - -123 Winding Way -Any Town, CA 12345 -USA - -Would be represented in a Quoted-Printable encoding as: -LABEL;ENCODING=QUOTED-PRINTABLE:123 Winding Way=0D=0A= - Any Town, CA 12345=0D=0A= - USA - -Property parameter substrings are delimited by a field delimiter, specified by the Semi-colon character (ASCII decimal 59). A Semi-colon in a property parameter value must be escaped with a Backslash character (ASCII 92). -Compound property values are property values that also make use of the Semi-colon, field delimiter to separate positional components of the value. For example, the Name property is made up of the Family Name, Given Name, etc. components. A Semi-colon in a component of a compound property value must be escaped with a Backslash character (ASCII 92). -Grouping -There are two forms of grouping or collections supported within the vCard. A collection of vCard objects can be grouped and a collection of properties within an individual vCard can be grouped. -vCard Grouping -The vCard data stream can consist of multiple vCard objects. The vCard data stream can, sequentially, contain one or more vCard objects., In addition, the vCard data stream can contain a property whose value is a nested vCard. In both of these cases, each vCard object will be delimited by the vCard Delimiters. The vCard Reader conforming to this specification must be able to parse and process any of these combinations of vCard Groupings. The support for vCard Grouping is optional for a vCard Writer conforming to this specification. -Property Grouping -A Property Grouping is the definition of a method for specifying a collection of related properties within a vCard object. There is no requirement on a vCard reader that it preserve the property group name. However, the vCard reader is required to preserve the grouping of the properties. -The Property Grouping is identified by a character string prefix to the property name; separated by the Period character (ASCII decimal 46). -The grouping of a comment property with a telephone property is shown in the following example: -A.TEL;HOME:+1-213-555-1234 -A.NOTE:This is my vacation home. -The vCard Reader conforming to this specification must be able to parse and process the property grouping. The support for Property Grouping is optional for a vCard Writer conforming to this specification. - -Encodings - -The default encoding for the vCard object is 7-Bit. The default encoding can be -overridden for an individual property value by using the "ENCODING" property -parameter. This parameter value can be either "BASE64", "QUOTED-PRINTABLE", or -"8BIT". This parameter may be used on any property. - -Some transports (e.g., MIME based electronic mail) may also provide an encoding -property at the transport wrapper level. This property can be used in these -cases for transporting a vCard data stream that has been defined using a -default encoding other than 7-bit (e.g., 8-bit). - -Character Set - -The default character set is ASCII. The default character set can be overridden for an individual property value by using the "CHARSET" property parameter. This property parameter may be used on any property. However, the use of this parameter on some properties may not make sense. -Any character set registered with the Internet Assigned Numbers Authority (IANA) can be specified by this property parameter. For example, ISO 8859-8 or the Latin/Hebrew character set is specified by: -ADR;CHARSET=ISO-8859-8:... -Some transports (e.g., MIME based electronic mail) may also provide a character -set property at the transport wrapper level. This property can be used in these -cases for transporting a vCard data stream that has been defined using a -default character set other than ASCII (e.g., UTF-8). - -Language - -The default language is "en-US" (US English). The default language can be -overridden for an individual property value by using the "LANGUAGE" property -parameter. The values for this property are a string consistent with RFC 1766, -Tags for the Identification of Languages. This property parameter may be used -on any property. However, the use of this parameter on some properties, such as -PHOTO, LOGO, SOUND, TEL, may not make sense. Canadian French would be specified -by this parameter by the following: -ADR;LANGUAGE=fr-CA:... -Value Location -The default location of the property value is inline with the property. -However, for some properties, such as those that specify multimedia values, it -is efficient to organize the property value as a separate entity (e.g., a file -out on the network). The property parameter "VALUE" can be specified to -override the "INLINE" location of the property value. In the case of the vCard -being transported within a MIME email message, the property value can be -specified as being located in a separate MIME entity with the "Content-ID" -value, or "CID" for short. In this case, the property value is the Content-ID -for the MIME entity containing the property value. In addition, the property -value can be specified as being located out on the network within some Internet -resource with the "URL" value. In this case, the property value is the Uniform -Resource Locator for the Internet resource containing the property value. This -property parameter may be used on any property. However, the use of this -parameter on some properties may not make sense; for example the Version, Time -Zone, Comment, Unique Identifier, properties . The following specifies a value -not located inline with the vCard but out in the Internet: -PHOTO;VALUE=URL;TYPE=GIF:http://www.abc.com/dir_photos/my_photo.gif -SOUND;VALUE=CONTENT-ID: ; ( 15, 13.) - LF = ; ( 12, 10.) - CRLF = CR LF - SPACE = ; ( 40, 32.) - HTAB = ; ( 11, 9.) -All literal property names are valid as upper, lower, or mixed case. -ws = 1*(SPACE / HTAB) - ; "whitespace," one or more spaces or tabs -wsls = 1*(SPACE / HTAB / CRLF) - ; whitespace with line separators -word = -groups = groups "." word - / word -vcard_file = [wsls] vcard [wsls] -vcard = "BEGIN" [ws] ":" [ws] "VCARD" [ws] 1*CRLF - items *CRLF "END" [ws] ":" [ws] "VCARD" -items = items *CRLF item - / item - ; these may be "folded" -item = [groups "."] name - [params] ":" value CRLF - / [groups "."] "ADR" - [params] ":" addressparts CRLF - / [groups "."] "ORG" - [params] ":" orgparts CRLF - / [groups "."] "N" - [params] ":" nameparts CRLF - / [groups "."] "AGENT" - [params] ":" vcard CRLF - ; these may be "folded" -name = "LOGO" / "PHOTO" / "LABEL" / "FN" / "TITLE" - / "SOUND" / "VERSION" / "TEL" / "EMAIL" / "TZ" / "GEO" / "NOTE" - / "URL" / "BDAY" / "ROLE" / "REV" / "UID" / "KEY" - / "MAILER" / "X-" word - ; these may be "folded" -value = 7bit / quoted-printable / base64 -7bit = <7bit us-ascii printable chars, excluding CR LF> -8bit = -quoted-printable = -base64 = - ; the end of the text is marked with two CRLF sequences - ; this results in one blank line before the start of the next property -params = ";" [ws] paramlist -paramlist = paramlist [ws] ";" [ws] param - / param -param = "TYPE" [ws] "=" [ws] ptypeval - / "VALUE" [ws] "=" [ws] pvalueval - / "ENCODING" [ws] "=" [ws] pencodingval - / "CHARSET" [ws] "=" [ws] charsetval - / "LANGUAGE" [ws] "=" [ws] langval - / "X-" word [ws] "=" [ws] word - / knowntype -ptypeval = knowntype / "X-" word -pvalueval = "INLINE" / "URL" / "CONTENT-ID" / "CID" / "X-" word -pencodingval = "7BIT" / "8BIT" / "QUOTED-PRINTABLE" / "BASE64" / "X-" word -charsetval = -langval = -addressparts = 0*6(strnosemi ";") strnosemi - ; PO Box, Extended Addr, Street, Locality, Region, Postal Code, - Country Name -orgparts = *(strnosemi ";") strnosemi - ; First is Organization Name, remainder are Organization Units. -nameparts = 0*4(strnosemi ";") strnosemi - ; Family, Given, Middle, Prefix, Suffix. - ; Example:Public;John;Q.;Reverend Dr.;III, Esq. -strnosemi = *(*nonsemi ("\;" / "\" CRLF)) *nonsemi - ; To include a semicolon in this string, it must be escaped - ; with a "\" character. -nonsemi = -knowntype = "DOM" / "INTL" / "POSTAL" / "PARCEL" / "HOME" / "WORK" - / "PREF" / "VOICE" / "FAX" / "MSG" / "CELL" / "PAGER" - / "BBS" / "MODEM" / "CAR" / "ISDN" / "VIDEO" - / "AOL" / "APPLELINK" / "ATTMAIL" / "CIS" / "EWORLD" - / "INTERNET" / "IBMMAIL" / "MCIMAIL" - / "POWERSHARE" / "PRODIGY" / "TLX" / "X400" - / "GIF" / "CGM" / "WMF" / "BMP" / "MET" / "PMB" / "DIB" - / "PICT" / "TIFF" / "PDF" / "PS" / "JPEG" / "QTIME" - / "MPEG" / "MPEG2" / "AVI" - / "WAVE" / "AIFF" / "PCM" - / "X509" / "PGP" - - -Section 3 : Internet Recommendations -[DS4] 1 -Recommended Practice with SMTP/MIME -The vCard information can be transported through SMTP/MIME based electronic mail services. Interoperability of vCard information over SMTP/MIME transports can be better assured by following a common set of recommended practices for encapsulation of the vCard. -Text/Plain Content Type -Without any change to existing SMTP or MIME compliant user agents, a vCard can be included within Internet email messages. This might be the case for an existing, simple user agent such as a legacy SMTP mail system. While this approach provides for transport of vCards over SMTP services, it does not allow for the end user to take advantage of the full capabilities of either the vCard or Internet email (i.e., MIME) functionality. -The following demonstrates how a vCard can be included as an epilog to a SMTP message made up of a RFC 822 message. This may be an initial method for incorporating vCard objects into SMTP messages. -Date: Thr, 25 Jan 96 0932 EDT -From: john.smith@host.com -Subject: Re: RFC822 vCard Example -Sender: john.smith@host.com -To: smartin@host2.com -Message-ID: - -Steve: Thanks for the call earlier today. I am unable to -use your material at this time. Please feel free to contact -me in the future. -BEGIN:VCARD -VERSION:2.1 -N:Smith;John;M.;Mr.;Esq. -TEL;WORK;VOICE;MSG:+1 (919) 555-1234 -TEL;WORK;FAX:+1 (919) 555-9876 -ADR;WORK;PARCEL;POSTAL;DOM:Suite 101;1 Central St.;Any Town;NC;27654 -END:VCARD -The following example demonstrates how a vCard can be included as a separate text/plain content portion within current MIME user agents. -Date: Fri, 26 Jan 1996 07:53:00 -0500 -From: smartin@host2.com -Subject: RE: Text/Plain MIME vCard Example -To: fdawson@VNET.IBM.COM -Mime-Version: 1.0 -Content-Type: multipart/mixed; boundary=vcard -Message-ID: - ---vcard -Content-Type:text/plain; charset=us-ascii -Content-Transfer-Encoding: 7bit -John: I have looked over my material and feel that you may -have over looked a couple of appropriate pieces. Please give -me a call so that we can discuss further. ---vcard -Content-Type:text/plain; charset=us-ascii; name="MARTIN.VCF" - -BEGIN:VCARD -VERSION:2.1 -N:Martin;Stephen -TEL;HOME;VOICE:+1 (210) 555-1357 -TEL;HOME;FAX:+1 (210) 555-0864 -ADR;WORK;PARCEL;POSTAL;DOM:123 Cliff Ave.;Big Town;CA;97531 -END:VCARD ---vcard-- -Text/X-vCard Content Type -A vCard object may also be transferred in a (RFC 1521) MIME entity as a non-standard "text/x-vCard" content-type. This (RFC 1521) MIME type maybe useful in those cases where the MIME compliant messaging service does not yet support the "application/directory" and "multipart/related" MIME content-types and yet the specificity of a calendaring and scheduling media type is required. -The following example demonstrates how a vCard can be included as a separate non-standard text/x-vCard content portion within current MIME user agents. -Date: Fri, 26 Jan 1996 07:53:00 +0000 -From: smartin@host2.com -Subject: RE: Text/x-vCard MIME vCard Example -To: fdawson@VNET.IBM.COM -Mime-Version: 1.0 -Content-Type: multipart/mixed; boundary=vcard -Message-ID: - ---vcard -Content-Type:text/plain; charset=us-ascii -Content-Transfer-Encoding: 7bit -John: I have looked over my material and feel that you may -have over looked a couple of appropriate pieces. Please give -me a call so that we can discuss further. ---vcard -Content-Type:text/x-vCard; charset=us-ascii; name="MARTIN.VCF" - -BEGIN:VCARD -VERSION:2.1N:Martin;Stephen -TEL;HOME;VOICE:+1 (210) 555-1357 -TEL;HOME;FAX:+1 (210) 555-0864 -ADR;WORK;PARCEL;POSTAL;DOM:123 Cliff Ave.;Big Town;CA;97531 -END:VCARD ---vcard-- -Application/Directory Content Type -The Internet Engineering Task Force (IETF) Access and Searching of Internet Directories (ASID) working group has produced an Internet Draft defining the "application/directory" MIME content type. The current draft name is draft-ietf-asid-mime-direct-01.txt. This specification is intended to be aligned with this work. Internet Drafts are working documents of an IETF working group, valid for at most six months, and should be considered "works in progress". -This MIME content type was designed to be used to transport directory information across MIME based electronic mail services. The internet draft is directly applicable to the exchange of business card data, such as that defined by the vCard specification. -The versit PDI Team has worked within the IETF ASID Working Group to draft an application/directory profile that registers the method for transporting a vCard as an application/directory Content-Type. The current draft name is draft-ietf-asid-mime-vcard-00.txt. This work is expected to be progressed to a Request For Comment after the publication of this version of the vCard specification. In the interim, the following guidelines are provided to describe how a vCard might be conveyed using the application/directory draft specification. -A vCard should be included in a MIME message that has a Content-Type header field value of "multipart/related". The vCard is included in the message as the primary body part. The position of the body part entity can also be specified with the "start=" parameter. This MIME body part entity has a Content-Type body part header field value of "application/directory" with a "profile" parameter value of "vcard". Any vCard binary information, such as a logo, picture, or digital audio pronunciation can be included inline within the vCard, as is specified by the vCard specification. Preferably, the binary information should be extracted from the vCard object and contained in the MIME message as secondary body part entities. The binary content in the secondary body part entities can be referenced from within the vCard object through the use of the "VALUE=" property parameter. In this latter case, the binary information should be transformed into a content type nominally supported by MIME user agents. For image content, this would be the Graphics Image Format (GIF) or Joint Picture Encoding Group (JPEG) formats. For audio content, this would be the 8-bit mu-law (PCM) format specified by the MIME specification. -The following example defines how this might be specified: -Date: Mon, 29 Jan 96 0830 EDT -From: john.smith@host.com -Subject: Re: MIME application/directory vCard Example -Sender: john.smith@host.com -To: smartin@host2.com -Message-ID: -Content-Type: multipart/related; boundary="vcard"; - type=application/directory; - start= ---vcard -Content-Type: application/directory; charset=us-ascii; - source="file://versit.or2"; profile="vcard" -Content-ID: < -BEGIN:VCARD -VERSION:2.1 -N:Smith;John;M.;Mr.;Esq. -TEL;WORK;VOICE;MSG:+1 (919) 555-1234 -TEL;CELL:+1 (919) 554-6758 -TEL;WORK;FAX:+1 (919) 555-9876 -PHOTO;GIF;MIME:< -ADR;WORK;PARCEL;POSTAL;DOM:Suite 101;1 Central St.;Any Town;NC;27654 -END:VCARD ---vcard -Content-Type: text/plain; charset=us-ascii -Content-ID: < -Steve: -I am not in the office today. You may want to try -reaching me either on my cellular telephone or fax your -new ideas to my office. -Let's setup a face-to-face meeting later this week, after I review -your updated material. I am including a picture in my business card -data, since we have not met yet. --- John ---vcard -Content-Type: image/gif -Content-ID: < -...image data would go here... ---vcard-- -Recommended Practice with HTTP/HTML -A vCard object should be transferred over HTTP with the non-standard MIME type/subtype value of "text/x-vCard". The non-standard subtype should be used because the vCard has not been registered as a MIME media type with the IANA. -The vCard information can be captured with a FORM type of HTML document. Interoperability of of vCard information can be better assured by following a common set of recommended practices for mapping vCard information into and out of HTML documents. -Form Element Usage -The HTML FORM element is a useful method for capturing data intended for input into individual vCard property values. The following recommended practices are provided for such use. -Mapping To INPUT Element Attribute Names -An HTML form data set is a useful mechanism for capturing vCard data within the Internet WWW. The use of a consistent naming scheme for the name attributes within a form element will permit implementations to support automatic fill-in of forms with existing vCard data. In addition, such a consistent naming scheme will provide a greater assurance of interoperability between HTML based applications that use vCard data. -The following table provides a recommended mapping of vCard properties and name attributes within a form element. -Identification Properties -Description -Attribute Name -Comment - -Formatted Name -FN - - -Name -N -Individual components of name property are captured as separate input elements with the names N.Family, N.First, N.Middle, N.Prefix, N.Suffix. - -Photograph -PHOTO -Only the URL based specification is supported by this mapping. Value is the URL for the graphic. - -Photograph Format Type -PHOTO.Type -Where the value is one of the enumerated strings defined by the vCard specification. - -Birthdate -BDAY - - - -Delivery Addressing Properties -Description -Attribute Name -Comment - -Delivery Address -ADR -TYPE=TEXTAREA - -Address Type -ADR.x -TYPE=CHECKBOX. Separate input elements are used to capture the possible delivery types. The elements are named ADR.x, where x is one of the enumerated strings defined by the vCard specification. - -Delivery Label -LABEL - - -Label Type -LABEL.x -TYPE=CHECKBOX. Separate input elements are used to capture the possible delivery types. The elements are named LABEL.x, where x is one of the enumerated strings defined by the vCard specification. - - -Telecommunications Addressing Properties -Description -Attribute Name -Comment - -Telephone Number -TEL - - -Telephone Type -TEL.x -TYPE=CHECKBOX. Separate input elements are used to capture the possible telephone types. The elements are named TEL.x, where x is one of the enumerated strings defined by the vCard specification. - -Electronic Mail Address -EMAIL - - -Electronic Mail Address Type -EMAIL.Type -Selection option from a list of alternatives. - -Mailer -MAILER - - - -Geographical Properties -Description -Attribute Name -Comment - -Time Zone -TZ - - -Geographic Position -GEO - - - -Organizational Properties -Description -Attribute Name -Comment - -Title -TITLE - - -Business Category -ROLE - - -Logo -LOGO -Only the URL based specification is supported by this mapping. Value is the URL for the graphic. - -Logo Format Type -LOGO.Type -Where the value is one of the enumerated strings defined by the vCard specification. - -Agent - -Captured through a separate form element using the mapping defined in these tables. - -Organization -ORG -TYPE=TEXT. Separate input elements for the organizational name and unit. The name ORG.Name is used to capture the organizational name. The name ORG.UNIT is used to capture the organizational unit. If there are multiple organizational units, it is captured in a form with name attributes ORG.UNIT1, ORG.UNIT2, etc. - - -Explanatory Properties -Description -Attribute Name -Comment - -Comment -NOTE -TYPE=TEXT - -Last Revision -REV -A hidden field. - -Version -VERSION -A hidden field with the value set to the string ì2.1î. - -Language -LANG -A hidden field with the value set to the string associated with the default language used in the form (e.g., US-eng). - -Sound -SOUND -TYPE=TEXT - -Sound Type -N/A - - -Uniform Resource Locator -URL -TYPE=TEXT - -Unique Identifier -UID -TYPE=TEXT - -Binary Encoding -BE.x -Where x is one of the enumerated encoding types defined by the vCard specification. - - -Security Properties -Description -Attribute Name -Comment - -Public Key -KEY - - -Key Type -KEY.Type.x -Where x is one of the enumerated encoding types defined by the vCard specification. - -MISCELLANEOUS PROPERTIES - - - -Extensions -X-x -Where x is a string defined by the extension author. - - -Where multiple properties (e.g., telephone numbers) appear, a label prefix should be used. For example, telephone #1 might have a name attribute of ìA.TELî, telephone #2 might have a name attribute of ìB.TELî, etc. -Example HTML Code -The following HTML code is an example of the use of the mapping of INPUT element attributes names to vCard property names. The code can be used to capture input data for creating a vCard on a Web homepage. - - -Create Your Own Versitcard - - -

Create Your Own Versitcard

-

Fill out this form and we'll -create a Versitcard for you and send it to the email address of your choice, -along with more information on the Versitcard format.

-
-
-Formatted Name:
-Phoenetic Pronunciation:
-Company Name:
-Company Unit:
-Title: -
-Family Name:
-Given Name:
-Middle Name:
-Name Prefix:
-Name Suffix:
-
-Delivery Label:

-Post Office Address:
-Extended Address:
-Street Address:
-City: -Region: -Postal Code:
-Country Name: -Work -Home -Parcel Postal
-
-TimeZone: -Location:
-
- -Telephone #1:
-Work -Home -Voice -Msg Fax Preferred
-
-Telephone #2:
-Work Home -Voice Msg -Fax -Preferred
-
-Telephone #3:
-Work -Home Voice Msg -Fax Preferred
-
-EmailAddress: -Work Home
-
-Send my Versitcard to this internet email address: -
Press to send the form now. Or, press to reset values to the form defaults. -
- - - -Section 4 : UI Support Recommendations -[DS5] -When integrating vCard support into an application, an implementor needs to consider a number of user interface (UI) implications. Most appliss Type -ADR.x -TYPE=CHECKBOX. Separate input elements are used to capture the possible delivery types. The elements are named ADR.x, where x is one of the enumerated strings defined by the vCard specification. - -Delivery Label -LABEL - - -Label Type -LABEL.x -TYPE=CHECKBOX. Separate input elements are used to capture the possible delivery types. The elements are named LABEL.x, where x is one of the enumerated strings defined by the vCard specification. - - -Telecommunications Addressing Properties -Description -Attribute Name -Comment - -Telephone Number -TEL - - -Telephone Type -TEL.x -TYPE=CHECKBOX. Separate input elements are used to capture the possible telephone types. The elements are named TEL.x, where x is one of the enumerated strings defined by the vCard specification. - -Electronic Mail Address -EMAIL - - -Electronic Mail Address Type -EMAIL.Type -Selection option from a list of alternatives. - -Mailer -MAILER - - - -Geographical Properties -Description -Attribute Name -Comment - -Time Zone -TZ - - -Geographic Position -GEO - - - -Organizational Properties -Description -Attribute Name -Comment - -Title -TITLE - - -Business Category -ROLE - - -Logo -LOGO -Only the URL based specification is supported by this mapping. Value is the URL for the graphic. - -Logo Format Type -LOGO.Type -Where the value is one of the enumerated strings defined by the vCard specification. - -Agent - -Captured through a separate form element using the mapping defined in these tables. - -Organization -ORG -TYPE=TEXT. Separate input elements for the organizational name and unit. The name ORG.Name is used to capture the organizational name. The name ORG.UNIT is used to capture the organizational unit. If there are multiple organizational units, it is captured in a form with name attributes ORG.UNIT1, ORG.UNIT2, etc. - - -Explanatory Properties -Description -Attribute Name -Comment - -Comment -NOTE -TYPE=TEXT - -Last Revision -REV -A hidden field. - -Version -VERSION -A hidden field with the value set to the string ì2.1î. - -Language -LANG -A hidden field with the value set to the string associated with the default language used in the form (e.g., US-eng). - -Sound -SOUND -TYPE=TEXT - -Sound Type -N/A - - -Uniform Resource Locator -URL -TYPE=TEXT - -Unique Identifier -UID -TYPE=TEXT - -Binary Encoding -BE.x -Where x is one of the enumerated encoding types defined by the vCard specification. - - -Security Properties -Description -Attribute Name -Comment - -Public Key -KEY - - -Key Type -KEY.Type.x -Where x is one of the enumerated encoding types defined by the vCard specification. - -MISCELLANEOUS PROPERTIES - - - -Extensions -X-x -Where x is a string defined by the extension author. - - -Where multiple properties (e.g., telephone numbers) appear, a label prefix should be used. For example, telephone #1 might have a name attribute of ìA.TELî, telephone #2 might have a name attribute of ìB.TELî, etc. -Example HTML Code -The following HTML code is an example of the use of the mapping of INPUT element attributes names to vCard property names. The code can be used to capture input data for creating a vCard on a Web homepage. - - -Create Your Own Versitcard - - -

Create Your Own Versitcard

-

Fill out this form and we'll -create a Versitcard for you and send it to the email address of your choice, -along with more information on the Versitcard format.

-
-
-Formatted Name:
-Phoenetic Pronunciation:
-Company Name:
-Company Unit:
-Title: -
-Family Name: - - img-inline-value = binary-value - ;Value MUST be "b" encoded image content - - img-inline-param - - img-inline-param = ("VALUE" "=" "binary") - / ("ENCODING" "=" "b") - / ("TYPE" "=" param-value - ;TYPE value MUST be an IANA registered image type - - img-refer-value = uri - ;URI MUST refer to image content of given type - - img-refer-param = ("VALUE" "=" "uri") - / ("TYPE" "=" param-value) - ;TYPE value MUST be an IANA registered image type - - adr-param = ("TYPE" "=" adr-type *("," adr-type)) - / (text-param) - - adr-type = "dom" / "intl" / "postal" / "parcel" / "home" - / "work" / "pref" / iana-type / x-name - - adr-value = 0*6(text-value ";") text-value - ; PO Box, Extended Address, Street, Locality, Region, Postal - ; Code, Country Name - - ;******************************************* - ; vCard Type Value Definition - ;******************************************* - - text-value-list = 1*text-value *("," 1*text-value) - - text-value = *(SAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) - - ESCAPED-CHAR = "\\" / "\;" / "\," / "\n" / "\N") - ; \\ encodes \, \n or \N encodes newline - ; \; encodes ;, \, encodes , - - binary-value = - - date-value = - - time-value = - - date-time-value = - - phone-number-value = - - uri-value = - - utc-offset-value = ("+" / "-") time-hour ":" time-minute - time-hour = 2DIGIT ;00-23 - time-minute = 2DIGIT ;00-59 diff --git a/etc/vcard-maker-design.txt b/etc/vcard-maker-design.txt deleted file mode 100644 index a269e4e..0000000 --- a/etc/vcard-maker-design.txt +++ /dev/null @@ -1,231 +0,0 @@ -Vcard maker API. Partially motivated by: - - http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodAPIDesign - - See "Many arguments? Lose 'em" - -Partially motivated by ruby1.8's rss/maker API: - - rss = RSS::Maker.make("0.9") do |maker| - maker.channel.title = "title" - maker.channel.link = "link" - maker.channel.description = "description" - maker.channel.language = "language" - - maker.image.url = "maker.image.url" - maker.image.title = "maker.image.title" - - item = maker.items.new_item - item.title = "item title" - item.link = "link" - end - - puts rss.to_s - -And partly by discussion with Dane G. Avilla. - - -** Goals - -Something I don't like about rss/maker is it returns nil if a mandatory -field was not set... very difficult to use. - -I like it to be hard to do things wrong, this can lead to APIs with lots of -mandatory args: - - #add_name(family, given, additional, prefix, suffix) - -But this sucks because I can never remember the order, and not all of the -fields are mandatory anyhow... - -So, given these desires, here's a sketch of an API for vCard creation. - -One thing I try to address is that often the attributes associated with a vCard -field are all implemented by adding something to the 'type' parameter, even -though the stuff getting jammed in there is (arguably) logically different. - - ADR;type=preferred,work,parcel:... - -Most people would think of this as being better modelled by: - - ADR;location=work;delivery=parcel;preferred=true:... - -I try and present things this way in the API, letting the underlying -representation be an implementation detail. - - -** Questions: - -Q: Does Apple support PHOTO and LOGO in OS 10.3? - - -Q: Apple AB 3.0.3 doesn't do round-trip.. so any field it doesn't "get" is dumped into the NOTE field, - and comes out that way. Play with this, what about PHOTO and KEY and PRODID? - - -Q: big problem with this kind of 'maker" API is it doesn't deal with adding new -fields to an existing vCard. Or modifying fields. Maybe it needs an alternate constructor, -one which takes a Vcard object, and will allow modifying that object? Would need a "delete_field" -method, too, then. - - -Q: find X.500, and it's telephone number format! - - -Q: how to set value and encoding... - If it is supposed to be TEXT, escape it? - If it is allowed to be binary, encode it? - -value says "this is a date/uri/date-time/text/etc." encoding says this -is base-64 encoded, or quoted-printable, etc. - -Especially it's hard to tell the difference between TEXT (where , and ; should -be escaped) and more structured fields, and particularly URIs. They are all String... - - -Q: Which fields can occur multiple times? N, for example? Does it say, anywhere? - -** Design/Use Cases - - -Here's how I'd like it to work. This was developed while reading through and -describing the fields that the RFC specifies for vCards, and trying to map them -to useful APIs. - -# Only FN and N are mandatory in a vCard (well, except for BEGIN, END and VERSION). -card = Maker.make(full_name) do |maker| - # FN: TEXT - # - mandatory, only one, set to +full_name+ - - # N: Family Name; Given Name; Additional Names; Honorific Prefixes; Honorific Suffixes - # - field is mandatory, so raise error if not set - # - all components are optional, can be N:;;;; - # - all compoenents can be set multiple times (.suffixes = RN,BFA) - # - block is mandatory, so you can't not notice it takes a block, but you can not - # set any name component, that is allowed - # - Maker.make will raise an error if name is not added. - maker.add_name do |name| - name.family = String - name.given = String - name.additional = String - name.prefix = String - name.suffix = String - end - - - # NICKNAME: TEXT, ... - # - multiple components allowed - # - allow it to be set multiple times, each one is concatenated to the - # same field - # - allow an Array of String? - maker.nickname = String - - - # PHOTO - can be of two varieties: - # uri -> PHOTO;value=uri[,type=IANA]:URI - # image -> PHOTO;encoding=b[,type=IANA]:DATA - # - IANA is a "IANA registered image formats or a non-standard image - # format" - # - types is never required. I think its pretty important for inline binary. For - # a URI, I guess it could be implied by the Content-Type, for HTTP URIs, - # anyhow. - # - technically, if a photos format was just text, it doesn't have to be - # base-64 encoded, but I think I should always encode it - - # You are allowed to put in nil yourself, but you have to actively choose not - # to have the type specified. - maker.add_photo_image(data, type) do |photo| - # or - maker.add_photo_link(uri, type = nil) do |photo| - photo.type = ... - end - - - # BDAY: DATE - # Can also be DATE-TIME, but the value is supposed to be changed... - # - should only be one! - maker.birthday = Date - maker.birthday = DateTime - maker.birthday = Time - - - # ADR:post office box;extended address; street address; locality; region; postal-code; country - # - can have multiple - # - common values of type param are, by related function: - # location: home, work - # delivery: postal, parcel - # delivery: dom (domestic), intl (international) - # preferred: true/false - # - components are allowed to have multiple values, region could be "shiga zone, hakumatsu region" - # - apple note: it is using '\n' in it's street address, but you are allowed to use ',', what's going on? - # - should it take 'steet address' as an arg, the common case, or maybe even stree, city, province? - make.add_addr do |adr| - adr.location = 'home' - adr.location = 'work' - adr.location = [ 'home', 'work' ] - adr.work = true - adr.home = true - - adr.preferred = true # false - - adr.delivery = parcel - end - - # LABEL:TEXT - # - this is like ADR, in the sense that FN is like N. It's a preformatted with '\n' address label, I - # guess that usually it can be put together from ADR. - # - I suspect it was added for apps that are importing addresses from some other format, and they have - # the address text, but can't break it down into all the parts that ADR needs, so this is their back-door. - # - it takes all the type params that ADR does - # - maybe it should be a sub-thing of ADR? And if both .label is assigned - # and anything else both LABEL and ADR will be generated, with the same type - # field? Maybe even in a group....? Or is that getting a bit much... - - make.add_addr do |adr| - adr.label = "30 Here\na street\na town" - # ... - end - - - # TEL:phone-number - # - spec says its supposed to be in a canonica form, as described by X.500 Telephone Number, - # but doesn't say what that form is! - # - attributes, trying to organize them... - # location: home, work, msg, cell, car, pager - # are these all locations? msg is arguably a capability, for home numbers anyhow, - # but doctors, for eg, sometimes have a special number to call to leave messages - # in case of emergencies - # capability: voice,fax,video,bbs,modem,isdn,pcs - make.add_tel do |tel| - tel.location = ... - tel.capability = ... - tel.preferred = ... - end - - # EMAIL:TEXT - # - attributes: - # protocol: internet, x400 (I guess this could also be uucp, fido, etc.) - # spec says default is internet, so doesn't have to be specified unless - # its NOT internet - # preferred: - # - - # MAILER:TEXT - # TZ: - # GEO: - # TITLE: - # ROLE: - # LOGO: - this is like PHOTO, but is for the card, it's kind of cool, does Apple support it in 10.3? - # AGENT - # ORG - # CATEGORY: - this could have all of Apples's "groups", but does it? Arguably it would be a personal - # info leak. - # NOTE: apple supports this - # PRODID: - I'm putting this in iCaledars, maybe I should put it in vCards, too? - # REV, SORT-STRING, SOUND, UID, CLASS, KEY - # URL:URL - - -end - - diff --git a/etc/vcf-api-notes.txt b/etc/vcf-api-notes.txt deleted file mode 100644 index 3e6b89d..0000000 --- a/etc/vcf-api-notes.txt +++ /dev/null @@ -1,53 +0,0 @@ -VCARD - -Should I find the version field, then create a Vcard3 class? - -Internal data structure .. hash of field to a Line, that will allow cacheing. - - #delete_if(name) yield Line, true/false means delete - - #address - #addresses - #photo - #photos - #tel - #tels - #nickname (first of first) - #nicknames (array of all) - ... - -Parameters: - -(from rfc2425) - -ENCODING - -VALUE - - values must not be "," repeated except in N, NICKNAME, ADR, CATEGORIES - - value=TEXT, ";" must be escaped, + the ones in 2425 - - PHONE-NUMBER, value is a ..., for TEL - - UTC-OFFSET, for TZ - - , must be escaped with a backslash in all values - -LANGUAGE - -CHARSET - -CONTEXT - - ?? - -(rfc2426) - -TYPE - - -Properties: - -(rfc2426) -