Skip to content

Commit 6846c5b

Browse files
ronaldtseronaldtse
committed
vObject/vObject-integrity update to 01
1 parent caceb35 commit 6846c5b

15 files changed

Lines changed: 216 additions & 205 deletions

‎draft-calconnect-vobject-integrity.adoc‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,14 @@
11
= Integrity Protection for vObject, vCard and iCalendar
22
:doctype: internet-draft
3-
:name: draft-calconnect-vobject-integrity-00
3+
:name: draft-calconnect-vobject-integrity-01
44
:abbrev: vObject Integrity
55
:status: standard
66
:ipr: trust200902
77
:submissionType: IETF
88
:area: internet
99
:intended-series: full-standard
1010
:workgroup: Calendaring Extensions
11-
:revdate: 2018-04-18T00:00:00Z
11+
:revdate: 2018-04-19T00:00:00Z
1212
:updates: 5545,6321,6350,6351,7953,7265,7095
1313
:fullname: Ronald Henry Tse
1414
:lastname: Tse

‎references/informative/reference.RFC.7953.xml‎

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
<?xml version='1.0' encoding='UTF-8'?>
2+
3+
<reference anchor='RFC7953' target='https://www.rfc-editor.org/info/rfc7953'>
4+
<front>
5+
<title>Calendar Availability</title>
6+
<author initials='C.' surname='Daboo' fullname='C. Daboo'><organization /></author>
7+
<author initials='M.' surname='Douglass' fullname='M. Douglass'><organization /></author>
8+
<date year='2016' month='August' />
9+
<abstract><t>This document specifies a new iCalendar (RFC 5545) component that allows the publication of available and unavailable time periods associated with a calendar user. This component can be used in standard iCalendar free-busy lookups, including the iCalendar Transport-independent Interoperability Protocol (iTIP; RFC 5546) free-busy requests, to generate repeating blocks of available or busy time with exceptions as needed.</t><t>This document also defines extensions to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) and the associated scheduling protocol (RFC 6638) to specify how this new calendar component can be used when evaluating free-busy time.</t></abstract>
10+
</front>
11+
<seriesInfo name='RFC' value='7953'/>
12+
<seriesInfo name='DOI' value='10.17487/RFC7953'/>
13+
</reference>

references/informative/reference.I-D.calconnect-vobject-vformat.xml renamed to references/normative/reference.I-D.calconnect-vobject-vformat.xml

File renamed without changes.

‎references/normative/reference.RFC.8126.xml‎

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,15 @@
1+
<?xml version='1.0' encoding='UTF-8'?>
2+
3+
<reference anchor='RFC8126' target='https://www.rfc-editor.org/info/rfc8126'>
4+
<front>
5+
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
6+
<author initials='M.' surname='Cotton' fullname='M. Cotton'><organization /></author>
7+
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
8+
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></author>
9+
<date year='2017' month='June' />
10+
<abstract><t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t><t>This is the third edition of this document; it obsoletes RFC 5226.</t></abstract>
11+
</front>
12+
<seriesInfo name='BCP' value='26'/>
13+
<seriesInfo name='RFC' value='8126'/>
14+
<seriesInfo name='DOI' value='10.17487/RFC8126'/>
15+
</reference>

‎sections/00-abstract.adoc‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -3,9 +3,9 @@
33
This document specifies an integrity checking mechanism and related
44
properties for:
55

6-
* vObject <<I-D.calconnect-vobject-vformat>>
7-
* vCard version 4 (vCard v4) <<RFC6350>>; and
6+
* vObject (I-D.calconnect-vobject-vformat)
7+
* vCard version 4 (vCard v4) (RFC 6350); and
88
* iCalendar (Internet Calendaring and Scheduling Core Object
9-
Specification) <<RFC5545>>
9+
Specification) (RFC 5545)
1010
1111
This work is produced by the CalConnect TC-VCARD and TC-CALENDAR committees.

‎sections/01-intro.adoc‎

Lines changed: 16 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -22,15 +22,18 @@ data integrity.
2222

2323
In reality, people are known to exchange vCard and iCalendar data
2424
through unreliable means, which could affect data integrity during
25-
transport, such as Internet mail <<RFC5322>> and QR Codes
26-
<<ISO-IEC-18004>>. On the other hand, there are implementations that
27-
store vCard and/or iCalendar content on disk, which could be subject to
28-
silent corruption.
25+
its data lifecycle:
2926

30-
Previous standards were created in a time where integrity concerns were
27+
* transport of vObject data, such as over Internet mail <<RFC5322>> and
28+
QR Codes <<ISO-IEC-18004>>;
29+
* storage of vObject content, such as on disk, can be subject to silent
30+
corruption.
31+
32+
Previous standards were established in a time where integrity concerns were
3133
less widespread, and relied solely on data transport, application and
3234
storage integrity without considering on whether the content
33-
transmitted, processed or retrieved was as intended without corruption.
35+
transmitted, processed or retrieved was as intended without modification or
36+
corruption.
3437

3538
This document specifically deals with information integrity in face of
3639
the following risks:
@@ -42,12 +45,13 @@ the following risks:
4245

4346
The standards subject to such risks include:
4447

45-
* vCard version 2.1 <<vCard21>>;
46-
* vCard version 3 <<RFC2425>>, <<RFC2426>>;
47-
* vCard version 4 <<RFC6350>>; and
48-
* iCalendar <<RFC5545>>.
49-
50-
// <!-- TODO: add iCalendar formats-->
48+
* vObject <<I-D.calconnect-vobject-vformat>>;
49+
* vCard versions 2.1 <<vCard21>>, 3 <<RFC2425>> <<RFC2426>> and 4 <<RFC6350>>;
50+
* iCalendar <<RFC5545>>;
51+
* Calendar Availability Extensions <<RFC7953>>;
52+
* alternative formats for iCalendar and vCard, including
53+
xCal <<RFC6321>>, jCal <<RFC7265>>,
54+
xCard <<RFC6351>>, and jCard <<RFC7095>>.
5155

5256
This document provides:
5357

‎sections/02-conventions.adoc‎

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -9,5 +9,25 @@ document are to be interpreted as described in BCP 14
99
<<RFC2119>> <<RFC8174>> when, and only when, they appear in
1010
all capitals, as shown here.
1111

12+
The key words "*Private Use*", "*Experimental Use*",
13+
"*Hierarchical Allocation*", "*First Come First Served*",
14+
"*Expert Review*", "*Specification Required*", "*RFC Required*",
15+
"*IETF Review*", "*Standards Action*" and "*IESG Approval*" in
16+
this document are to be interpreted as described in <<RFC8126,4>>.
17+
1218
The definitions from <<I-D.calconnect-vobject-vformat>> are inherited
1319
in this document unless explicitly overriden.
20+
21+
=== Definitions
22+
23+
Implementation Supported Checksum:: An implementation is considered to
24+
support checksum calculation if it is able to calculate the checksum
25+
without external aid, i.e., it supports the parameters specified to
26+
calculate the checksum value.
27+
28+
Source Preferred Checksum Value (SPCV)::
29+
A CHECKSUM property that includes a PREF property parameter.
30+
31+
Receiver Preferred Checksum Value (RPCV)::
32+
The CHECKSUM property that uses the implementation's preferred
33+
checksum parameters.

0 commit comments

Comments
 (0)