This document defines the Internet Calendar Scheduling Protocol (iSchedule), which is a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to the Hypertext Transfer Protocol (HTTP) to enable interoperability between calendaring and scheduling systems over the Internet.
© 2017 The Calendaring and Scheduling Consortium, Inc.
This document is not a CalConnect Standard. It is distributed for review and comment, and is subject to change without notice and may not be referred to as a Standard. Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from the address below.
The Calendaring and Scheduling Consortium, Inc.
4390 Chaffin Lane
McKinleyville
California 95519
United States of America
www.calconnect.org
This document defines the Internet Calendar Scheduling Protocol (iSchedule), which is a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to the Hypertext Transfer Protocol (HTTP) to enable interoperability between calendaring and scheduling systems over the Internet.
This binding document provides the transport specific information necessary to convey iCalendar Transport-independent Interoperability Protocol (iTIP)
The Internet Calendar Scheduling Protocol (iSchedule) enables interoperability between different calendaring and scheduling systems. Calendaring and scheduling systems that provide support for iSchedule allow their users to perform scheduling transactions such as schedule, reschedule, respond to scheduling request or cancel scheduled calendar components, as well as search for busy time information with users of other calendaring and scheduling systems on the Internet.
Discussion of this Internet-Draft is taking place on the mailing list <>.
The iCalendar Message-Based Interoperability Protocol (iMIP)
A binding to an email-based transport is clearly inadequate to search for busy time information since users need and expect to get an immediate response. As such, some calendaring and scheduling systems allow users to publish their free busy information in a resource accessible to others on the Internet. In the absence of a standardized mechanism to locate the resource that provides the free busy information of a user, one thus needs to know the location of this resource in addition to the calendar user address of the users one wishes to schedule with.
With an email-based transport, the transparent processing of incoming scheduling messages on the server is only possible when the calendaring and scheduling system is integrated with the email system. Commonly, the processing of incoming scheduling messages occurs on the client and requires user intervention, which yields the following consequences:
The processing of incoming scheduling messages and the corresponding updates to the calendar only occur when the client is active. As a result, free busy information may be inaccurate (e.g., user still appears busy when the organizer actually rescheduled or canceled the meeting).
Calendaring and scheduling systems generally restrain the number of updates sent to users to reduce the number of messages that will clutter their email inbox. As a result, attendees rarely obtain up to date participation status of other attendees.
The client becomes responsible for verification of the authenticity and integrity of the scheduling message.
Implementers will need to be familiar with other documents that, along with this document, form a framework for Internet calendaring and scheduling standards.
This document specifies a binding from iTIP to HTTP.
This document does not attempt to repeat the specification of concepts or definitions from these other documents. Where possible, references are made to the document that provides the specification of these concepts or definitions.
This document defines the Internet Calendar Scheduling Protocol (iSchedule), which is a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to the Hypertext Transfer Protocol (HTTP) to enable interoperability between calendaring and scheduling systems over the Internet.
For the purposes of this document, the following terms and definitions apply.
This specification reuses much of the same terminology as
An
The calendar user who is sending a scheduling message to one or more other calendar users.
A calendar user to whom a scheduling message is being sent.
The iSchedule service responsible for sending scheduling messages.
The iSchedule service responsible for receiving scheduling messages.
The iSchedule design can be pictured as:
When an iSchedule Sender has a scheduling message to transmit, it determines the iSchedule Receivers to which to deliver the message and sends the appropriate iSchedule message. The iSchedule Receiver verifies the authenticity and content of the iSchedule message and delivers it to the Calendar Service.
The means by which a Calendar Store or User Agent instructs a Calendar Service, acting as an iSchedule Sender, to transmit scheduling messages is outside the scope of this document. A Calendar Service could provide support for a standard calendar access protocol, such as CalDAV
Likewise, the actual processing of scheduling messages received by a Calendar Service, acting as an iSchedule Receiver, is also outside the scope of this document. Some Calendar Service implementations may decide to process some or all received scheduling messages, while other implementations may decide to leave that work to Calendar User Agent implementations.
This section provides an overview of the various steps involved for iSchedule Senders and Receivers to transmit scheduling messages between Calendar Services. It references later sections describing the precise details of each step.
A Calendar Service will generate an iTIP
The iSchedule Sender MUST verify the authenticity of the Originator and the Originator’s authorization to send the scheduling message. In particular the “ORGANIZER” iCalendar property value MUST match the Originator calendar user address. The process by which this authentication and authorization is done is outside the scope of this document.
For each Recipient, the iSchedule Sender will attempt to lookup a matching iSchedule Receiver to which the iSchedule message can be sent, following the rules in
The iSchedule Sender MUST group together Recipients for whom the iSchedule Receiver is the same, so that a single scheduling message is sent for multiple Recipients, within the limits of the
For each group of Recipients handled by the same iSchedule Receiver, the iSchedule Sender will construct an HTTP request, as per
The iSchedule Sender then sends the HTTP request to the iSchedule Receiver handling the Recipient group, and receives the HTTP response, which will be an XML document with either an IS:schedule-response or IS:error element as the root element.
The iSchedule Sender aggregates the results for each Recipient group receiving an iSchedule message, and returns the resulting status information for each Recipient to the Calendar Service that generated the schedule message. The process by which this is done is outside the scope of this document.
iSchedule Receivers MUST provide a capabilities document to Senders, as per
Once the authenticity of the message is confirmed, the iSchedule Receiver delivers the scheduling message to the indicated recipients, collects and aggregates the delivery status for each recipient, and returns the result in the HTTP response body.
In the event of a processing error related to the overall request, iSchedule Receivers MUST return an error response as per
This section describes how an iSchedule Sender can discover the host name, port, and the path to use to submit an HTTP request to an iSchedule Receiver.
For each Recipient to whom a scheduling message is being sent, the iSchedule Sender will “resolve” the associated calendar user address into a domain name, as per
The iSchedule Sender then uses the extracted domain name to issue a DNS SRV query for the
The result of an SRV record lookup will be a target host name and a port, as per
Since an iSchedule Receiver is an HTTP server, an iSchedule Sender needs to supply a Request-URI in the HTTP request it makes to the iSchedule Receiver, in addition to the host name and port information. iSchedule Senders MUST use the path specified in any TXT records accompanying the SRV record (as per
To deliver a scheduling message via the iSchedule protocol, an iSchedule Sender needs to determine which iSchedule Receiver to use for a particular recipient. Each recipient’s calendar user address is specified in one or more Recipient request headers.
A calendar user address as defined by iCalendar is simply a URI. This is typically a mailto URI, but could potentially be any URI type. However, only URIs containing a “host” element can be used to extract the necessary information to locate an iSchedule Receiver.
To get the SRV record name to query for a given mailto URI, the “domain” portion of the mailto URI is extracted and appended to the service label “_ischedules._tcp.”.
In cases where the “domain” portion of the mailto URI contains one or more levels of sub-domain, iSchedule Senders MAY choose to remove successive levels of “sub-domain” if queries for that sub-domain fail to return any SRV records. For example, a mailto URI with the full domain “host.calendar.example.com” would first trigger a query using the domain “host.calendar.example.com”, then if that failed, the domain “calendar.example.com” would be tried, then if that failed the domain “example.com” would be tried.
This specification adds an SRV service label for use with iSchedule:
Identifies an iSchedule Receiver that uses HTTP with transport layer security (
service record for iSchedule Receiver with transport layer security
When SRV RRs are used to advertise iSchedule services, it is also convenient to be able to specify a “context path” in the DNS to be retrieved at the same time. To enable that, this specification uses a TXT RR that follows the syntax defined in
A site might provide TXT records in addition to SRV records for the service. When present, iSchedule Senders MUST use the “path” value as the “context path” for the service in HTTP requests. When not present, iSchedule Senders use the “.well-known” URI approach described next.
text record for service with TLS
This specification registers a well-known URI
iSchedule Receivers supporting the features described in this document MUST
allow iSchedule Senders to query their capabilities by accepting GET requests
targeted at the Request-URI found during discovery ( Informative rationale: The GET method was favored over the POST method to allow iSchedule Senders to query capabilities with “conditional GET” requests (see
iSchedule Receivers SHOULD use normal HTTP expiration mechanisms (as per
iSchedule Senders SHOULD use the information in the capabilities to determine whether the iSchedule Receiver supports a version of the protocol that the iSchedule Sender can use, and if not, not issue any iSchedule requests with scheduling messages to the iSchedule Receiver. iSchedule Senders SHOULD verify that the scheduling message to be sent to the iSchedule Receiver is in line with the restrictions on scheduling messages indicated by the capabilities before sending the scheduling message.
This section defines how an iSchedule Sender can use the HTTP POST method to submit a scheduling message to an iSchedule Receiver.
The POST method submits a scheduling message to one or more Recipients by targeting the request at the Request-URI of an iSchedule Receiver. The request body of a POST method MUST contain a scheduling message (i.e., an iCalendar object that follows the iTIP semantic).
The submitted scheduling message will be delivered to the Recipients, with status information about per-recipient delivery returned in the HTTP response. However, when the scheduling message is a request for free-busy time, the iSchedule Receiver will immediately execute the free-busy request for the Recipients and return per-recipient iCalendar data in the response for successful free-busy queries.
Every POST request MUST include the
Every POST request SHOULD include the
Every POST request MUST include the “Cache-Control” HTTP general header containing the cache-directives “no-cache” and “no-transform” to prevent intermediary caches from caching or transforming responses.
Every POST request MUST include a single
| Method | Originator Requirement |
|---|---|
| PUBLISH | MUST match ORGANIZER |
| REQUEST | MUST match ORGANIZER iTIP does allow an Attendee to forward a “METHOD:REQUEST” scheduling message to another attendee. However, due to complexity of managing the authorization of such requests, this specification does not allow scheduling message forwarding. |
| REPLY | MUST match ATTENDEE |
| ADD | MUST match ORGANIZER |
| CANCEL | MUST match ORGANIZER |
| REFRESH | MUST match ATTENDEE |
| COUNTER | MUST match ATTENDEE |
| DECLINECOUNTER | MUST match ORGANIZER |
Every POST request MUST include one or more
| Method | Recipient Requirement |
|---|---|
| PUBLISH | None iTIP does allow an Organizer to send scheduling message to calendar users who are not listed as Attendees, e.g., to inform other calendar users of an event taking place. However, due to complexity of managing the authorization of such requests, this specification does not allow such scheduling messages. |
| REQUEST | MUST match ATTENDEE iTIP does allow an Organizer to send scheduling message to calendar users who are not listed as Attendees, e.g., to inform other calendar users of an event taking place. However, due to complexity of managing the authorization of such requests, this specification does not allow such scheduling messages. |
| REPLY | MUST match ORGANIZER |
| ADD | MUST match ATTENDEE iTIP does allow an Organizer to send scheduling message to calendar users who are not listed as Attendees, e.g., to inform other calendar users of an event taking place. However, due to complexity of managing the authorization of such requests, this specification does not allow such scheduling messages. |
| CANCEL | MUST match ATTENDEE iTIP does allow an Organizer to send scheduling message to calendar users who are not listed as Attendees, e.g., to inform other calendar users of an event taking place. However, due to complexity of managing the authorization of such requests, this specification does not allow such scheduling messages. |
| REFRESH | MUST match ORGANIZER |
| COUNTER | MUST match ORGANIZER |
| DECLINECOUNTER | MUST match ATTENDEE |
The Content-Type general header MUST include the type parameters “component” and “method” defined in
A POST request may deliver a scheduling message to one or more calendar users specified in the Recipient request header. Since the behavior of each recipient may vary, it is useful to get response status information for each recipient in the overall POST response. This specification defines a new XML response to convey multiple recipient status.
A response to a POST method that indicates status for one or more recipients MUST be an XML document with IS:schedule-response as its root element. This MUST contain one or more response elements for each recipient, with each of those containing elements that indicate which recipient they correspond to, the scheduling status of the request for that recipient, any error codes and an optional description.
In the case of a free-busy request, the response elements can also contain calendar-data elements which contain free busy information (e.g., an iCalendar VFREEBUSY component) indicating the busy state of the corresponding recipient, assuming that the free-busy request for that recipient succeeded.
Every POST response MUST include the “Cache-Control” HTTP general header containing the cache-directives “no-cache” and “no-transform” to prevent intermediary caches from caching or transforming responses.
When there is an overall, as opposed to per-recipient, failure of the POST request, the iSchedule Receiver SHOULD return an XML document with IS:error as its root element. The child elements of the IS:error element are used to indicate an error code and description, primarily meant for service administrators.
The following XML elements are error codes which can be used within an IS:error element to represent errors:
The POST request was either missing an “iSchedule-Version” header, or had an “iSchedule-Version” header value for a version not supported by the iSchedule Receiver, as advertised in the IS:versions capability.
The resource submitted in the POST request was not a supported media type (i.e. text/calendar) for scheduling or free-busy messages;
The resource submitted in the POST request was not valid data for the media type being specified;
The resource submitted in the POST request did not obey all restrictions specified for the POST request, violating the IS:scheduling-message capability element, or the requirements of iTIP;
The POST request did not include an “Originator” request header specifying the calendar user address of the Originator of the scheduling message.
The POST request contained more than one “Originator” request header.
The “Originator” header in the POST request did not include a valid calendar user address for the Originator of the scheduling message.
The calendar user identified by the “Originator” header in the POST request is not allowed to use this service.
The POST request did not include one or more valid “Recipient” request headers specifying the calendar user address of users to whom the scheduling message will be delivered.
The POST request did not include “Recipient” request header values which exactly match the list of “ATTENDEE” property values in a “VFREEBUSY” request.
The POST request had too many calendar user addresses specified in “Recipient” request headers, violating the IS:max-recipients capability.
The scheduling message submitted in the POST request had iCalendar data with “ATTACH” properties whose value type is not supported, violating the IS:attachments capability.
The scheduling message submitted in the POST request had iCalendar data violating the IS:max-content-length capability.
The scheduling message submitted in the POST request had iCalendar data violating the IS:min-date-time capability.
The scheduling message submitted in the POST request had iCalendar data violating the IS:max-date-time capability.
The scheduling message submitted in the POST request had iCalendar data violating the IS:max-instances capability.
The following are examples of response codes one would expect to be used for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a response. Typically a 403 response code would be used when an XML document with an IS:error element as its root is also returned.
The command succeeded.
The Sender has provided an invalid scheduling message, or invalid iSchedule request headers.
The Sender cannot submit a scheduling message to the specified Request-URI.
The URL in the Request-URI was not present.
The server did not have sufficient space to record the scheduling message.
This section defines the syntax and semantics of additional HTTP/1.1 header fields.
The header’s syntax uses the optional whitespace (OWS) rule defined as follows:
The “iSchedule-Version” general header field MUST be specified by the iSchedule Sender on requests, and by the iSchedule Receiver on responses. It SHOULD be included in a response to any “OPTIONS *” HTTP request targeting the iSchedule Receiver, or any “OPTIONS” request on a resource supporting the iSchedule behaviors described in this specification (e.g., the .well-known resource or any resource that .well-known redirects to).
The “iSchedule-Capabilities” response header field MUST be specified by the iSchedule Receiver on all responses. iSchedule Senders SHOULD cache this value and use it to detect a change in the iSchedule Receiver capabilities that cause the iSchedule Sender to reload capabilities. The value of this header is maintained by the iSchedule Receiver as described in
The “iSchedule-Message-ID” request header field SHOULD be specified by the iSchedule Sender on requests. This header provides a unique identifier that refers to the specific iSchedule request in which it is included. The uniqueness of this identifier is guaranteed by the iSchedule Sender that generates it. This identifier is intended to be machine readable and not necessarily meaningful to humans.
The “Originator” request header value is a URI which specifies the calendar user address of the originator of the scheduling message. Note that the absoluteURI rule is defined in
The “Recipient” request header value is a URI which specifies the calendar user address of the recipients to which the POST method should deliver the submitted scheduling message. Note that the absoluteURI rule is defined in
schedule-response
urn:ietf:params:xml:ns:ischedule
Contains the set of responses for a POST method request.
See
response
urn:ietf:params:xml:ns:ischedule
Contains a single response for a POST method request.
See
recipient
urn:ietf:params:xml:ns:ischedule
The calendar user address (recipient header value) that the enclosing response for a POST method request is for.
See
request-status
urn:ietf:params:xml:ns:ischedule
The iTIP REQUEST-STATUS property value for this response.
See
calendar-data
urn:ietf:params:xml:ns:ischedule
An iCalendar object in a response to a search for busy time information.
See
error
urn:ietf:params:xml:ns:ischedule
Error responses sometimes need more information to indicate what went wrong.
See
response-description
urn:ietf:params:xml:ns:ischedule
Contains information about a status response
See
query-result
urn:ietf:params:xml:ns:ischedule
Contains result of a query request.
A generic container for the result of a query request, such as a query of the capabilities of an iSchedule Receiver.
capabilities
urn:ietf:params:xml:ns:ischedule
Contains iSchedule Receiver capabilities.
The capabilities element contains capabilities of the iSchedule Receiver.
serial-number
urn:ietf:params:xml:ns:ischedule
Identifies the version of the capabilities information.
This is a numeric value maintained by the iSchedule Receiver. The value is incremented by the iSchedule Receiver each time there has been a substantive change to the capabilities that would require an iSchedule Sender to reload the capabilities to adjust its behavior. The value of this element MUST be returned by the iSchedule Receiver in all HTTP requests via the
versions
urn:ietf:params:xml:ns:ischedule
Identifies the iSchedule versions supported by the iSchedule Receiver.
An iSchedule Receiver MAY advertise support for multiple versions of the iSchedule protocol. iSchedule Senders check this value to ensure they can send iSchedule messages with a matching version.
version
urn:ietf:params:xml:ns:ischedule
Identifies an iSchedule protocol version.
scheduling-messages
urn:ietf:params:xml:ns:ischedule
Identifies the type of supported scheduling messages.
An iSchedule Receiver advertises which iCalendar component types it will accept for iTIP messages sent to it. In addition, for each component, it can specify the allowed iTIP “METHOD” property values.
component
urn:ietf:params:xml:ns:ischedule
Identifies a calendar component type.
Used to specify a supported iCalendar component type for scheduling messages. If a IS:method child element is not present, then any iTIP “METHOD” property value can be used in iTIP messages sent to the iSchedule Receiver. If one or more IS:method elements are present, then those indicate the allowed set of iTIP “METHOD” property values.
method
urn:ietf:params:xml:ns:ischedule
Identifies an iCalendar method type.
See IS:component.
calendar-data-types
urn:ietf:params:xml:ns:ischedule
Identifies what formats of iCalendar data are acceptable.
calendar-data-type
urn:ietf:params:xml:ns:ischedule
Identifies a supported media type and version for iTIP messages.
attachments
urn:ietf:params:xml:ns:ischedule
Identifies the attachment values supported.
iSchedule Receivers might restrict what form of attachments are allowed in iTIP messages that are sent to it, for performance, or security reasons. In iCalendar data, attachments can either be specified using “inline” data in the form of a base64 encoded property value, or “external” data in the form of a URI property value. With this capability, an iSchedule Receiver can specify which of “inline” or “external” values it will accept in iTIP messages. See
inline
urn:ietf:params:xml:ns:ischedule
Identifies “inline” attachments as a supported attachment value.
external
urn:ietf:params:xml:ns:ischedule
Identifies “external” attachments as a supported attachment value.
rscales
urn:ietf:params:xml:ns:ischedule
Identifies the “RSCALE” values supported.
iSchedule Receivers might support the
rscale
urn:ietf:params:xml:ns:ischedule
Indicates a supported “RSCALE” value.
max-content-length
urn:ietf:params:xml:ns:ischedule
Identifies the maximum size allowed for a scheduling message in octets.
min-date-time
urn:ietf:params:xml:ns:ischedule
A DATE-TIME value indicating the earliest date and time in UTC that the iSchedule Receiver is willing to accept for any DATE or DATE-TIME value in a scheduling message.
max-date-time
urn:ietf:params:xml:ns:ischedule
A DATE-TIME value indicating the latest date and time in UTC that the iSchedule Receiver is willing to accept for any DATE or DATE-TIME value in a scheduling message.
max-instances
urn:ietf:params:xml:ns:ischedule
The maximum number of recurrence instances allowed in a scheduling message.
max-recipients
urn:ietf:params:xml:ns:ischedule
The maximum number of recipients allowed for a scheduling message.
administrator
urn:ietf:params:xml:ns:ischedule
Provides contact information for the administrator of the iSchedule Receiver.
The process of scheduling involves the sending and receiving of scheduling messages. As a result, the security problems related to messaging in general are relevant here. In particular the authenticity of the scheduling messages needs to be verified.
iSchedule Senders and iSchedule Receivers MUST use an HTTP connection protected with TLS
DNS security issues are addressed by DNSSEC
iCalendar data can include “inline” attachment data in the form of a base64-encoded “ATTACH” property value. iSchedule Receivers MUST take care when allowing “inline” attachments in scheduling messages as such data might contain malicious content, and SHOULD use some form of content scanner on the attachment data to verify its safety (e.g., a content scanner used for email messages). In addition, “inline” attachment data is likely to be much larger than the actual calendar-related data in a scheduling message, and thus could adversely affect the performance of an iSchedule Receiver processing it. If an iSchedule Receiver allows “inline” attachment data, it MUST apply a limit on the size of acceptable scheduling messages to prevent possible denial-of-service attacks using large “inline” attachment data. In general, it is best for iSchedule Receivers to simply disable the ability for scheduling messages to contain “inline” attachment data, and instead rely solely on “external” attachments in the form of URI attachment values.
This specification registers a new URN to identify a new XML namespace as per
Registration request for the iSchedule namespace:
urn:ietf:params:xml:ns:ischedule
See the “Authors’ Addresses” section of this document.
None. Namespace URIs do not represent an XML specification.
This specification registers new headers for use with HTTP as per
iSchedule-Version
http
standard
IETF
this specification
none
iSchedule-Capabilities
http
standard
IETF
this specification
none
iSchedule-Message-ID
http
standard
IETF
this specification
none
Originator
http
standard
IETF
this specification
none
Recipient
http
standard
IETF
this specification
none
This specification registers a new well-known URI as per
ischedule
IETF.
this specification
none
The authors would like to thank the following individuals for contributing their ideas and support for writing this specification: Mattias Amnefelt, Mike Douglass, Tomas Hnetila, Ciny Joy, Barry Leiba, Ken Murchison, Simon Pilette, Arnaud Quillaud, Simon Vaillancourt, and Wilfredo Sanchez Vega.
The authors would also like to thank CalConnect, The Calendaring and Scheduling Consortium, for advice with this specification, and for organizing interoperability testing events to help refine it.
This section describes some example scheduling transactions that give a general idea of how scheduling is carried out between an iSchedule Sender and an iSchedule Receiver.
In the following example, the iSchedule Sender requests the iSchedule Receiver to deliver a meeting invitation (scheduling REQUEST) to the calendar user mailto:cyrus@example.org. The response indicates that delivery of the scheduling message was successful.
In the following example, the iSchedule Sender requests the iSchedule Receiver to determine the busy information of the calendar users mailto:cyrus@example.org and mailto:mike@example.org, over the time range specified by the scheduling message sent in the request. The response includes VFREEBUSY components with the busy time for one calendar user, and an error for the other calendar user.
In the following example, the iSchedule Sender requests the iSchedule Sender to deliver a task assignment (scheduling REQUEST) to the calendar user mailto:cyrus@example.org. For some reason the verification of the request fails as is indicated by the error response.
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]
This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.
This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.
A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]
The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]
Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]
This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]
This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. [STANDARDS-TRACK]
This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems.
The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. [STANDARDS-TRACK]
This memo defines a path prefix for “well-known locations”, “/.well-known/”, in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK]
This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the “http” and “https” Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.
The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.
This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the “calendar-access” feature of CalDAV. [STANDARDS-TRACK]
This document, “iCalendar Message-Based Interoperability Protocol (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 (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC 2046, RFC 2047, and RFC 2049), and then transported over SMTP. [STANDARDS-TRACK]
This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) “calendar-access” feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the “calendar-auto-schedule” feature of CalDAV. [STANDARDS-TRACK]
This document defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC 5545) to support use of non-Gregorian recurrence rules. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers and clients can be extended to support these new recurrence rules.