draft-ietf-calext-ical-relations-00.txt   draft-ietf-calext-ical-relations-01.txt 
Network Working Group M. Douglass Network Working Group M. Douglass
Internet-Draft Spherical Cow Group Internet-Draft Spherical Cow Group
Intended status: Standards Track August 24, 2016 Updates: 5545 (if approved) February 3, 2017
Expires: February 25, 2017 Intended status: Standards Track
Expires: August 7, 2017
Support for Icalendar Relationships Support for iCalendar Relationships
draft-ietf-calext-ical-relations-00 draft-ietf-calext-ical-relations-01
Abstract Abstract
This specification updates RELATED-TO and introduces new iCalendar This specification updates RELATED-TO and introduces new iCalendar
properties LINK, STRUCTURED-CATEGORY and REFID to allow better properties LINK, STRUCTURED-CATEGORY and REFID to allow better
linking and grouping of iCalendar components and related data. linking and grouping of iCalendar components and related data.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 25, 2017. This Internet-Draft will expire on August 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Structured iCalendar relationships . . . . . . . . . . . 3 1.1. Structured iCalendar relationships . . . . . . . . . . . 3
1.2. Grouped iCalendar relationships . . . . . . . . . . . . . 3 1.2. Grouped iCalendar relationships . . . . . . . . . . . . . 3
1.3. Structured category relationships . . . . . . . . . . . . 3 1.3. Structured category relationships . . . . . . . . . . . . 3
1.4. Linked relationships . . . . . . . . . . . . . . . . . . 3 1.4. Linked relationships . . . . . . . . . . . . . . . . . . 3
1.5. Caching and offline use . . . . . . . . . . . . . . . . . 4 1.5. Caching and offline use . . . . . . . . . . . . . . . . . 4
1.6. Conventions Used in This Document . . . . . . . . . . . . 4 1.6. Conventions Used in This Document . . . . . . . . . . . . 4
2. Reference Types . . . . . . . . . . . . . . . . . . . . . . . 4 2. Reference Types . . . . . . . . . . . . . . . . . . . . . . . 5
3. Link Relation Types . . . . . . . . . . . . . . . . . . . . . 5 3. Link Relation Types . . . . . . . . . . . . . . . . . . . . . 5
4. Redefined Relation Type Value . . . . . . . . . . . . . . . . 5 4. Redefined Relation Type Value . . . . . . . . . . . . . . . . 5
5. New Property Parameters . . . . . . . . . . . . . . . . . . . 8 5. New Property Parameters . . . . . . . . . . . . . . . . . . . 8
5.1. Rel . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Rel . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Gap . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Gap . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. New Value Data Types . . . . . . . . . . . . . . . . . . . . 9 6. New Value Data Types . . . . . . . . . . . . . . . . . . . . 9
7. New Properties . . . . . . . . . . . . . . . . . . . . . . . 9 7. New Properties . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Structured-Category . . . . . . . . . . . . . . . . . . . 9 7.1. Structured-Category . . . . . . . . . . . . . . . . . . . 10
7.2. Link . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. Link . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. Refid . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.3. Refid . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Redefined RELATED-TO Property . . . . . . . . . . . . . . . . 12 8. Redefined RELATED-TO Property . . . . . . . . . . . . . . . . 13
8.1. RELATED-TO . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. RELATED-TO . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10.1. iCalendar Property Registrations . . . . . . . . . . . . 15 10.1. iCalendar Property Registrations . . . . . . . . . . . . 16
10.2. iCalendar Property Parameter Registrations . . . . . . . 15 10.2. iCalendar Property Parameter Registrations . . . . . . . 16
10.3. iCalendar Value Data Type Registrations . . . . . . . . 15 10.3. iCalendar Value Data Type Registrations . . . . . . . . 16
10.4. iCalendar RELTYPE Value Registrations . . . . . . . . . 16 10.4. iCalendar RELTYPE Value Registrations . . . . . . . . . 17
10.5. New Reference Type Registration . . . . . . . . . . . . 16 10.5. New Reference Type Registration . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
12. Normative References . . . . . . . . . . . . . . . . . . . . 17 12. Normative References . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Icalendar entities often need to be related to each other or to iCalendar entities often need to be related to each other or to
associated meta-data. These relationships can take the following associated meta-data. These relationships can take the following
forms forms
Structured iCalendar: Icalendar entities are related to each other Structured iCalendar: iCalendar entities are related to each other
in some structured way, for example as parent, sibling, before, in some structured way, for example as parent, sibling, before,
after. after.
Grouped iCalendar: Icalendar entities are related to each other as a Grouped iCalendar: iCalendar entities are related to each other as a
group. CATEGORIES are often used for this purpose but are group. CATEGORIES are often used for this purpose but are
problematic for application developers. problematic for application developers.
Linked: Entities are linked to each other through typed references. Linked: Entities are linked to each other through typed references.
1.1. Structured iCalendar relationships 1.1. Structured iCalendar relationships
The currently existing iCalendar [RFC5545] RELATED-TO property has no The currently existing iCalendar [RFC5545] RELATED-TO property has no
support for temporal relationships as used by standard project support for temporal relationships as used by standard project
management tools. management tools.
The RELTYPE parameter is extended to take new values defining The RELTYPE parameter is extended to take new values defining
temporal relationships, a GAP parameter is defined to provide lead temporal relationships, a GAP parameter is defined to provide lead
and lag values and RELATED-TO is extended to allow URI values. These and lag values and RELATED-TO is extended to allow URI values. These
changes allows the RELATED-TO property to define a richer set of changes allow the RELATED-TO property to define a richer set of
relationships useful for project management. relationships useful for project management.
1.2. Grouped iCalendar relationships 1.2. Grouped iCalendar relationships
This specification defines a new REFID property which allows This specification defines a new REFID property which allows
arbitrary groups of entities to be associated with the same key arbitrary groups of entities to be associated with the same key
value. The presence of a REFID property imparts no meaning to the value. The presence of a REFID property imparts no meaning to the
event. It is merely a key to allow retrieval. event. It is merely a key to allow retrieval.
1.3. Structured category relationships 1.3. Structured category relationships
The introduction of STRUCTURED-CATEGORY allows a more structured The introduction of STRUCTURED-CATEGORY allows a more structured
approach to categorization, with the possibility of namespaced and approach to categorization, with the possibility of namespaced and
path-like values. Unlike REFID the category imparts some meaning. path-like values. Unlike REFID the category imparts some meaning.
It is assumed that the value of this property will reference a well It is assumed that the value of this property will reference a well
defined category. defined category.
The current [RFC5545] CATEGORY property is used as a free form
'tagging' field. As such it is difficult to establish formal
relationships between components based on their category.
Rather than attempt to add semantics to the current property it
seeems best to continue its usage as an informal tag and establish a
new property with more constraints.
1.4. Linked relationships 1.4. Linked relationships
The currently existing iCalendar standard [RFC5545] lacks a general The currently existing iCalendar standard [RFC5545] lacks a general
purpose method for referencing additional, external information purpose method for referencing additional, external information
relating to calendar components. relating to calendar components.
This document proposes a method for referencing typed external This document proposes a method for referencing typed external
information that can provide additional information about an information that can provide additional information about an
iCalendar component. This new LINK property is closely aligned to iCalendar component. This new LINK property is closely aligned to
the LINK header defined in [RFC5988] the LINK header defined in [RFC5988]
skipping to change at page 4, line 22 skipping to change at page 4, line 30
Beyond the need to relate elements temporally, project management Beyond the need to relate elements temporally, project management
tools often need to be able to specify the relationships between the tools often need to be able to specify the relationships between the
various events and tasks which make up a project. The LINK property various events and tasks which make up a project. The LINK property
provides such a mechanism. provides such a mechanism.
The LINK property SHOULD NOT be treated as just another attachment. The LINK property SHOULD NOT be treated as just another attachment.
The ATTACH property is being extended to handle server-side The ATTACH property is being extended to handle server-side
management and stripping of inline data. Clients may choose to management and stripping of inline data. Clients may choose to
handle attachments differently as they are often an integral part of handle attachments differently as they are often an integral part of
the message - for example, the agenda. the message - for example, the agenda. See
[I-D.daboo-caldav-attachments]
1.5. Caching and offline use 1.5. Caching and offline use
To facilitate offline display the link type may identify important To facilitate offline display the link type may identify important
pieces of data which should be downloaded in advance. pieces of data which should be downloaded in advance.
In general, the calendar entity should be self explanatory without In general, the calendar entity should be self explanatory without
the need to download referenced meta-data such as a web page. the need to download referenced meta-data such as a web page.
1.6. Conventions Used in This Document 1.6. Conventions Used in This Document
skipping to change at page 5, line 24 skipping to change at page 5, line 36
The relation types defined here will be registered with IANA in The relation types defined here will be registered with IANA in
accordance with the specifications in [RFC5988]. accordance with the specifications in [RFC5988].
4. Redefined Relation Type Value 4. Redefined Relation Type Value
Relationship parameter type values are defined in section 3.2.15. of Relationship parameter type values are defined in section 3.2.15. of
[RFC5545]. This specification redefines that type to include the new [RFC5545]. This specification redefines that type to include the new
temporal relationship values FINISHTOSTART, FINISHTOFINISH, temporal relationship values FINISHTOSTART, FINISHTOFINISH,
STARTTOFINISH and STARTTOSTART. It also adds the DEPENDS-ON value to STARTTOFINISH and STARTTOSTART. It also adds the DEPENDS-ON value to
provide a link to an component upon which the current component provide a link to a component upon which the current component
depends. depends.
Format Definition: Format Definition:
This property parameter is defined by the following notation: This property parameter is defined by the following notation:
reltypeparam = "RELTYPE" "=" reltypeparam = "RELTYPE" "="
("PARENT" ; Parent relationship - Default ("PARENT" ; Parent relationship - Default
/ "CHILD" ; Child relationship / "CHILD" ; Child relationship
/ "SIBLING" ; Sibling relationship / "SIBLING" ; Sibling relationship
skipping to change at page 6, line 8 skipping to change at page 6, line 33
Description: This parameter can be specified on a property that Description: This parameter can be specified on a property that
references another related calendar component. The parameter may references another related calendar component. The parameter may
specify the hierarchical relationship type of the calendar specify the hierarchical relationship type of the calendar
component referenced by the property when the value is PARENT, component referenced by the property when the value is PARENT,
CHILD or SIBLING. If this parameter is not specified on an CHILD or SIBLING. If this parameter is not specified on an
allowable property, the default relationship type is PARENT. allowable property, the default relationship type is PARENT.
Applications MUST treat x-name and iana-token values they don't Applications MUST treat x-name and iana-token values they don't
recognize the same way as they would the PARENT value. recognize the same way as they would the PARENT value.
It defines the temporal relationship when the value is one of the This parameter defines the temporal relationship when the value is
project management standard relationships FINISHTOSTART, one of the project management standard relationships
FINISHTOFINISH, STARTTOFINISH or STARTTOSTART. This property will FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH or STARTTOSTART.
be present in the predecessor entity and will refer to the This property will be present in the predecessor entity and will
successor entity. The GAP parameter specifies the lead or lag refer to the successor entity. The GAP parameter specifies the
time between the predecessor and the successor. In the lead or lag time between the predecessor and the successor. In
description of each temporal relationship below we refer to Task-A the description of each temporal relationship below we refer to
which contains and controls the relationship and Task-B the target Task-A which contains and controls the relationship and Task-B the
of the relationship. target of the relationship.
RELTYPE=PARENT: See [RFC5545] section 3.2.15. RELTYPE=PARENT: See [RFC5545] section 3.2.15.
RELTYPE=CHILD: See [RFC5545] section 3.2.15. RELTYPE=CHILD: See [RFC5545] section 3.2.15.
RELTYPE=SIBLING: See [RFC5545] section 3.2.15. RELTYPE=SIBLING: See [RFC5545] section 3.2.15.
RELTYPE=DEPENDS-ON: Indicates that the current calendar component RELTYPE=DEPENDS-ON: Indicates that the current calendar component
depends on the referenced calendar component in some manner. For depends on the referenced calendar component in some manner. For
example a task may be blocked waiting on the other, referenced, example a task may be blocked waiting on the other, referenced,
skipping to change at page 10, line 8 skipping to change at page 10, line 37
Within the "VEVENT", "VTODO", or "VJOURNAL" calendar components, Within the "VEVENT", "VTODO", or "VJOURNAL" calendar components,
more than one formal category can be specified by using multiple more than one formal category can be specified by using multiple
properties. properties.
This categorization is distinct from the more informal "tagging" This categorization is distinct from the more informal "tagging"
of components provided by the existing CATEGORIES property. It is of components provided by the existing CATEGORIES property. It is
expected that the value of the STRUCTURED-CATEGORY property will expected that the value of the STRUCTURED-CATEGORY property will
reference an external resource which provides information about reference an external resource which provides information about
the categorization. the categorization.
Possible category resources are the various proprietary systems,
for example Library of Congress, or an open source such as
dmoz.org.
In addition, a structured URI value allows for hierarchical In addition, a structured URI value allows for hierarchical
categorization of org.bedework.util.jms.events. categorization of events.
Format Definition: Format Definition:
This property is defined by the following notation: This property is defined by the following notation:
structured-category = "STRUCTURED-CATEGORY" structcatparam ":" uri CRLF structured-category = "STRUCTURED-CATEGORY" structcatparam ":" uri CRLF
structcatparam = *( structcatparam = *(
; ;
; The following is OPTIONAL, ; The following is OPTIONAL,
skipping to change at page 11, line 13 skipping to change at page 12, line 7
component. component.
Description: When used in a component the value of this property Description: When used in a component the value of this property
points to additional information related to the component. For points to additional information related to the component. For
example, it may reference the originating web server. example, it may reference the originating web server.
Format Definition: Format Definition:
This property is defined by the following notation: This property is defined by the following notation:
link = "LINK" linkparam ":" ( ":" uri ) / link = "LINK" linkparam /
(
";" "VALUE" "=" "TEXT"
":" text
)
( (
";" "VALUE" "=" "REFERENCE" ";" "VALUE" "=" "REFERENCE"
":" text ":" text
) )
(
";" "VALUE" "=" "URI"
":" uri
)
CRLF CRLF
linkparam = *( linkparam = *(
; the following is MANDATORY ; the following is MANDATORY
; and MAY occur more than once ; and MAY occur more than once
(";" relparam) / (";" relparam) /
; the following are MANDATORY ; the following are MANDATORY
skipping to change at page 13, line 11 skipping to change at page 14, line 11
REFID:itinerary-2014-11-17 REFID:itinerary-2014-11-17
8. Redefined RELATED-TO Property 8. Redefined RELATED-TO Property
8.1. RELATED-TO 8.1. RELATED-TO
Property name: RELATED-TO Property name: RELATED-TO
Purpose: This property is used to represent a relationship or Purpose: This property is used to represent a relationship or
reference between one calendar component and another. The reference between one calendar component and another. The
definition here extends the definition in Section 3.8.4.5. of definition here extends the definition in Section 3.8.4.5. of
[RFC5545] by allowing URI values and a GAP parameter. [RFC5545] by allowing URI or UID values and a GAP parameter.
Value type: URI or TEXT Value type: URI, UID or TEXT
Property Parameters: Non-standard, reference type, gap, value or Property Parameters: Non-standard, reference type, gap, value or
format type parameters can be specified on this property. format type parameters can be specified on this property.
Conformance: This property MAY be specified in any iCalendar Conformance: This property MAY be specified in any iCalendar
component. component.
Description: By default or when VALUE=UID is specified, the property Description: By default or when VALUE=UID is specified, the property
value consists of the persistent, globally unique identifier of value consists of the persistent, globally unique identifier of
another calendar component. This value would be represented in a another calendar component. This value would be represented in a
skipping to change at page 15, line 35 skipping to change at page 16, line 35
| REFID | Current | Section 7.3 | | REFID | Current | Section 7.3 |
| STRUCTURED-CATEGORY | Current | Section 7.1 | | STRUCTURED-CATEGORY | Current | Section 7.1 |
+---------------------+---------+-------------+ +---------------------+---------+-------------+
10.2. iCalendar Property Parameter Registrations 10.2. iCalendar Property Parameter Registrations
The following iCalendar property parameter names have been added to The following iCalendar property parameter names have been added to
the iCalendar Parameters Registry defined in Section 8.3.3 of the iCalendar Parameters Registry defined in Section 8.3.3 of
[RFC5545] [RFC5545]
+---------------------+---------+-------------+ +-----------+---------+-------------+
| Parameter | Status | Reference | | Parameter | Status | Reference |
+---------------------+---------+-------------+ +-----------+---------+-------------+
| REL | Current | Section 5.1 | | REL | Current | Section 5.1 |
| GAP | Current | Section 5.2 | | GAP | Current | Section 5.2 |
| STRUCTURED-CATEGORY | Current | Section 7.1 | +-----------+---------+-------------+
+---------------------+---------+-------------+
10.3. iCalendar Value Data Type Registrations 10.3. iCalendar Value Data Type Registrations
The following iCalendar property parameter names have been added to The following iCalendar property parameter names have been added to
the iCalendar Value Data Types Registry defined in Section 8.3.4 of the iCalendar Value Data Types Registry defined in Section 8.3.4 of
[RFC5545] [RFC5545]
+-----------------+---------+-----------+ +-----------------+---------+-----------+
| Value Data Type | Status | Reference | | Value Data Type | Status | Reference |
+-----------------+---------+-----------+ +-----------------+---------+-----------+
| UID | Current | Section 6 | | UID | Current | Section 6 |
skipping to change at page 16, line 20 skipping to change at page 17, line 20
10.4. iCalendar RELTYPE Value Registrations 10.4. iCalendar RELTYPE Value Registrations
The following iCalendar "RELTYPE" values have been added to the The following iCalendar "RELTYPE" values have been added to the
iCalendar Relationship Types Registry defined in Section 8.3.8 of iCalendar Relationship Types Registry defined in Section 8.3.8 of
[RFC5545] [RFC5545]
+---------------------+---------+-----------+ +---------------------+---------+-----------+
| Parameter | Status | Reference | | Parameter | Status | Reference |
+---------------------+---------+-----------+ +---------------------+---------+-----------+
| REL | Current | Section 4 |
| DEPENDS-ON | Current | Section 4 | | DEPENDS-ON | Current | Section 4 |
| REFID | Current | Section 4 | | REFID | Current | Section 4 |
| STRUCTURED-CATEGORY | Current | Section 4 | | STRUCTURED-CATEGORY | Current | Section 4 |
| FINISHTOSTART | Current | Section 4 | | FINISHTOSTART | Current | Section 4 |
| FINISHTOFINISH | Current | Section 4 | | FINISHTOFINISH | Current | Section 4 |
| STARTTOFINISH | Current | Section 4 | | STARTTOFINISH | Current | Section 4 |
| STARTTOSTART | Current | Section 4 | | STARTTOSTART | Current | Section 4 |
+---------------------+---------+-----------+ +---------------------+---------+-----------+
10.5. New Reference Type Registration 10.5. New Reference Type Registration
skipping to change at page 16, line 47 skipping to change at page 17, line 46
+--------+---------+-------------+ +--------+---------+-------------+
| SOURCE | Current | Section 5.1 | | SOURCE | Current | Section 5.1 |
+--------+---------+-------------+ +--------+---------+-------------+
11. Acknowledgements 11. Acknowledgements
The author would like to thank the members of the Calendaring and The author would like to thank the members of the Calendaring and
Scheduling Consortium technical committees and the following Scheduling Consortium technical committees and the following
individuals for contributing their ideas, support and comments: individuals for contributing their ideas, support and comments:
Adrian Apthorp, Cyrus Daboo, Marten Gajda Adrian Apthorp, Cyrus Daboo, Marten Gajda, Ken Murchison
The authors would also like to thank the Calendaring and Scheduling The author would also like to thank the Calendaring and Scheduling
Consortium for advice with this specification. Consortium for advice with this specification.
12. Normative References 12. Normative References
[I-D.daboo-caldav-attachments]
Daboo, C. and A. Quillaud, "CalDAV Managed Attachments",
draft-daboo-caldav-attachments-03 (work in progress),
February 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
 End of changes. 26 change blocks. 
54 lines changed or deleted 79 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/