Reorganize the encodings into separate directories

sources/cc-ioptest-rules-0401.adoc → sources/cc-0401-ioptest-rules/document.adoc

@@ -12,7 +12,6 @@
 :mn-output-extensions: xml,html,pdf,rxl
 :local-cache-only:
 
-
 .Foreword
 
 This document incorporates by reference the CalConnect Intellectual Property Rights,

sources/cc-report-roundtable-1.adoc → sources/cc-0404-report-roundtable-1/document.adoc

@@ -12,7 +12,6 @@
 :mn-output-extensions: xml,html,pdf,rxl
 :local-cache-only:
 
-
 .Foreword
 The Calendaring and Scheduling Consortium ("`CalConnect`") is a global non-profit
 organization with the aim to facilitate interoperability of technologies across

sources/cc-overview-0508.adoc → sources/cc-0508-pres-overview/document.adoc

@@ -11,7 +11,7 @@
 :mn-document-class: cc
 :mn-output-extensions: xml,html,pdf,rxl
 :local-cache-only:
-:imagesdir: images/overview-0508
+:imagesdir: images
 
 .Foreword
 

sources/cc-questionnaire-results-timezone.adoc → sources/cc-0510-questionnaire-results-timezone/document.adoc

@@ -95,33 +95,33 @@ result received.
 | CONSUME(y) | CONSUME(n) | CONSUME(o) | *CONSUME %* | PRODUCE(y) | PRODUCE(n) | PRODUCE(o) | *PRODUCE*
 | h| Components supported: 8+|
 
-| Q1 | VTIMEZONE | 12 | 0 | 7 | *100%* | 11 | 1 | 7 | *92%*
-| Q1.1 | STANDARD | 12 | 0 | 7 | *100%* | 11 | 1 | 7 | *92%*
-| Q1.2 | DAYLIGHT | 12 | 0 | 7 | *100%* | 11 | 1 | 7 | *92%*
+| Q1 | `VTIMEZONE` | 12 | 0 | 7 | *100%* | 11 | 1 | 7 | *92%*
+| Q1.1 | `STANDARD` | 12 | 0 | 7 | *100%* | 11 | 1 | 7 | *92%*
+| Q1.2 | `DAYLIGHT` | 12 | 0 | 7 | *100%* | 11 | 1 | 7 | *92%*
 | h| Properties supported: 8+|
-| h| In VTIMEZONE 8+|
-| Q2.1 | TZID | 11 | 1 | 7 | *92%* | 11 | 1 | 7 | *92%*
-| Q2.2 | LAST-MODIFIED | 6 | 6 | 7 | *50%* | 6 | 6 | 7 | *50%*
-| Q2.3 | TZURL | 5 | 7 | 7 | *42%* | 2 | 10 | 7 | *17%*
-| Q2.4 | XPROP | 5 | 7 | 7 | *42%* | 1 | 11 | 7 | *8%*
-| h| In STANDARD 8+|
-| Q3.1 | DTSTART | 11 | 1 | 7 | *92%* | 10 | 2 | 7 | *83%*
-| Q3.2 | TZOFFSETTO | 12 | 0 | 7 | *100%* | 11 | 1 | 7 | *92%*
-| Q3.3 | TZOFFSETFROM | 12 | 0 | 7 | *100%* | 11 | 1 | 7 | *92%*
-| Q3.4 | COMMENT | 5 | 7 | 7 | *42%* | 4 | 8 | 7 | *33%*
-| Q3.5 | RDATE | 8 | 4 | 7 | *67%* | 5 | 7 | 7 | *42%*
-| Q3.6 | RRULE | 12 | 0 | 7 | *100%* | 10 | 2 | 7 | *83%*
-| Q3.7 | TZNAME | 6 | 6 | 7 | *50%* | 8 | 4 | 7 | *67%*
-| Q3.8 | XPROP | 6 | 6 | 7 | *50%* | 2 | 10 | 7 | *17%*
-| h| In DAYLIGHT 8+|
-| Q4.1 | DTSTART | 11 | 1 | 7 | *92%* | 10 | 2 | 7 | *83%*
-| Q4.2 | TZOFFSETTO | 12 | 0 | 7 | *100%* | 11 | 1 | 7 | *92%*
-| Q4.3 | TZOFFSETFROM | 12 | 0 | 7 | *100%* | 11 | 1 | 7 | *92%*
-| Q4.4 | COMMENT | 6 | 6 | 7 | *50%* | 5 | 7 | 7 | *42%*
-| Q4.5 | RDATE | 8 | 4 | 7 | *67%* | 5 | 7 | 7 | *42%*
-| Q4.6 | RRULE | 12 | 0 | 7 | *100%* | 10 | 2 | 7 | *83%*
-| Q4.7 | TZNAME | 6 | 6 | 7 | *50%* | 8 | 4 | 7 | *67%*
-| Q4.8 | XPROP | 6 | 6 | 7 | *50%* | 2 | 10 | 7 | *17%*
+| h| In `VTIMEZONE` 8+|
+| Q2.1 | `TZID` | 11 | 1 | 7 | *92%* | 11 | 1 | 7 | *92%*
+| Q2.2 | `LAST-MODIFIED` | 6 | 6 | 7 | *50%* | 6 | 6 | 7 | *50%*
+| Q2.3 | `TZURL` | 5 | 7 | 7 | *42%* | 2 | 10 | 7 | *17%*
+| Q2.4 | `XPROP` | 5 | 7 | 7 | *42%* | 1 | 11 | 7 | *8%*
+| h| In `STANDARD` 8+|
+| Q3.1 | `DTSTART` | 11 | 1 | 7 | *92%* | 10 | 2 | 7 | *83%*
+| Q3.2 | `TZOFFSETTO` | 12 | 0 | 7 | *100%* | 11 | 1 | 7 | *92%*
+| Q3.3 | `TZOFFSETFROM` | 12 | 0 | 7 | *100%* | 11 | 1 | 7 | *92%*
+| Q3.4 | `COMMENT` | 5 | 7 | 7 | *42%* | 4 | 8 | 7 | *33%*
+| Q3.5 | `RDATE` | 8 | 4 | 7 | *67%* | 5 | 7 | 7 | *42%*
+| Q3.6 | `RRULE` | 12 | 0 | 7 | *100%* | 10 | 2 | 7 | *83%*
+| Q3.7 | `TZNAME` | 6 | 6 | 7 | *50%* | 8 | 4 | 7 | *67%*
+| Q3.8 | `XPROP` | 6 | 6 | 7 | *50%* | 2 | 10 | 7 | *17%*
+| h| In `DAYLIGHT` 8+|
+| Q4.1 | `DTSTART` | 11 | 1 | 7 | *92%* | 10 | 2 | 7 | *83%*
+| Q4.2 | `TZOFFSETTO` | 12 | 0 | 7 | *100%* | 11 | 1 | 7 | *92%*
+| Q4.3 | `TZOFFSETFROM` | 12 | 0 | 7 | *100%* | 11 | 1 | 7 | *92%*
+| Q4.4 | `COMMENT` | 6 | 6 | 7 | *50%* | 5 | 7 | 7 | *42%*
+| Q4.5 | `RDATE` | 8 | 4 | 7 | *67%* | 5 | 7 | 7 | *42%*
+| Q4.6 | `RRULE` | 12 | 0 | 7 | *100%* | 10 | 2 | 7 | *83%*
+| Q4.7 | `TZNAME` | 6 | 6 | 7 | *50%* | 8 | 4 | 7 | *67%*
+| Q4.8 | `XPROP` | 6 | 6 | 7 | *50%* | 2 | 10 | 7 | *17%*
 |===
 
 [%portrait]
@@ -133,22 +133,22 @@ result received.
 |===
 | Question | Description 3+| Answers |
 | h| General: | (y) | (n) | (o) | %
-| Q5 | Do you always send DATE-TIME values with a timezone? | 9 | 9 | 1 | *47%*
-| Q6 | Do you always send DATE-TIME values in UTC or floating? | 9 | 5 | 5 | *47%*
+| Q5 | Do you always send `DATE-TIME` values with a timezone? | 9 | 9 | 1 | *47%*
+| Q6 | Do you always send `DATE-TIME` values in UTC or floating? | 9 | 5 | 5 | *47%*
 | Q7 | Do you provide a standard set of timezones built-in to your product? | 16 | 3 | 0 | *84%*
 | Q8 | Where did you get your timezone definitions? 3+| Most come from Olsen. Some from Windows. Others from Java. |
 | Q9 | How many timezone definitions do you have? 3+| Varies from about 50 to about 380 |
-| Q10 | Do you have a special naming scheme for TZIDs, and if so what is it? 3+| Olsen naming e.g. America/New_York. Windows naming. Tzid: URI. Tzid with vendor prefix. |
+| Q10 | Do you have a special naming scheme for ``TZID``s, and if so what is it? 3+| Olsen naming e.g. America/New_York. Windows naming. Tzid: URI. Tzid with vendor prefix. |
 | Q11 | Do you provide a mechanism for updating built-in timezones? | 5 | 9 | 1 | *33%*
 | Q12 | Do you adjust future times to account for timezone definition changes? | 2 | 3 | 3 | *25%*
 | Q13 | Do you accept and use timezone definitions from imported iCalendar data? | 10 | 5 | 1 | *63%*
-| Q14 | Do you attempt to merge timezone definitions with the same TZID when importing iCalendar data? 3+| Some do, some don't (about 50%). Also: "We match it to our internal list by ID first and then by rule". |
+| Q14 | Do you attempt to merge timezone definitions with the same `TZID` when importing iCalendar data? 3+| Some do, some don't (about 50%). Also: "We match it to our internal list by ID first and then by rule". |
 | Q15 | When exporting timezones in iCalendar data (either to a file or via iTIP) do you send the entire timezone definition or just the set of dates needed for coverage of the event? 3+| Those that do it export the entire timezone definition. |
 | Q16 | Would you use timezone definitions from a standard timezone registry if one were created? | 11 | 2 | 4 | *65%*
-| Q17 | What problems would be involved in changing a timezone definition if DST was changed at some point in the future? 3+| Most would need to get new definitions and update with automatically or manually. There was some concern about how the new definitions would look (e.g. some could not support more than one STANDARD or DAYLIGHT component). |
+| Q17 | What problems would be involved in changing a timezone definition if DST was changed at some point in the future? 3+| Most would need to get new definitions and update with automatically or manually. There was some concern about how the new definitions would look (e.g. some could not support more than one `STANDARD` or DAYLIGHT component). |
 | C1 | Comments on specific answers (include Q number for cross-reference to original question): 3+| |
 | C2 | Comments on the format and ease of use of this questionnaire: 3+| Most liked email (though some wanted text/plain and not text/html). A few preferred web-based. One wanted MS Word file. |
-| C3 | Are there any additional questions we should be asking, and if so what are they? 3+| Should have asked: Do any applications support multiple STANDARD and DAYLIGHT components? Should have asked: how do you treat 'foreign' TZIDs (e.g. map to own internal TZID etc)? Would like TZID on RRULE to simplify some problems.Should have asked: are timezones used on simple non-recurring events, or only recurring events? |
+| C3 | Are there any additional questions we should be asking, and if so what are they? 3+| Should have asked: Do any applications support multiple `STANDARD` and `DAYLIGHT` components? Should have asked: how do you treat 'foreign' ``TZID``s (e.g. map to own internal `TZID` etc)? Would like TZID on RRULE to simplify some problems.Should have asked: are timezones used on simple non-recurring events, or only recurring events? |
 |===
 
 ==== Other Comments
@@ -159,31 +159,31 @@ processing algorithms you get flaky results. I notice that the experience with T
 DNS, for example, has led to RFCs that are increasingly specific in giving guidance to
 implementors.
 
-This is the main reason I haven't implemented VTIMEZONE yet. With the exception of
-RRULE (see comment below), most of the rest of iCalendar is a fairly straight forward
+This is the main reason I haven't implemented `VTIMEZONE` yet. With the exception of
+`RRULE` (see comment below), most of the rest of iCalendar is a fairly straight forward
 task of writing a codec for the data structures. Everything I need to know is in the
-RFCs. If there was a description of how to implement VTIMEZONE, I would have done
+RFCs. If there was a description of how to implement `VTIMEZONE`, I would have done
 it.
 
 I strongly suggest that the calconnect group go to greater effort to offer
 implementation guidance to further interop. This could include pseudo-code processing
 models, warnings about problems and corner cases to look out for, and should
-particularly involve test suites. RRULE, for example, would be unimplementable
+particularly involve test suites. `RRULE`, for example, would be unimplementable
 without its extensive set of examples. iTIP needs a similar suite of examples, too.
 
 === Conclusions
 
 ==== Basic Timezone Support
 
-Support for the basic VTIMEZONE component and properties seemed to be
+Support for the basic `VTIMEZONE` component and properties seemed to be
 fairly complete, with most vendors both consuming and producing such
-components. Note that "producing" a VTIMEZONE component usually means
+components. Note that "producing" a `VTIMEZONE` component usually means
 copying a component out of a standard library provided in the product. We are
-not aware of any iCalendar products that generate VTIMEZONE components
+not aware of any iCalendar products that generate `VTIMEZONE` components
 on-the-fly from some other data source.
 
 It was clear that a number of products prefer to operate in UTC and will
-"downgrade" DATE-TIME values to UTC if a timezone was included.
+"downgrade" `DATE-TIME` values to UTC if a timezone was included.
 
 Most products include a built-in set of timezone definitions, ranging in number
 from 50 to 380. These came from a variety of different sources, including the
@@ -213,8 +213,8 @@ to adopt any registry scheme if it were to become available.
 ==== Other Comments
 
 One issue that was raised and not answered, was whether products are capable
-of handling multiple STANDARD and DAYLIGHT components in a single
-VTIMEZONE. That is important for dealing with timezone definition changes.
+of handling multiple `STANDARD` and `DAYLIGHT` components in a single
+`VTIMEZONE`. That is important for dealing with timezone definition changes.
 
 ==== Future Work
 
@@ -276,39 +276,39 @@ P1:: Product/Implementation Name:
 .Components supported
 |===
 | | Consume | Produce
-| Q1: VTIMEZONE | y/n/o | y/n/o
-| Q1.1: STANDARD | y/n/o | y/n/o
-| Q1.2: DAYLIGHT | y/n/o | y/n/o
+| Q1: `VTIMEZONE` | y/n/o | y/n/o
+| Q1.1: `STANDARD` | y/n/o | y/n/o
+| Q1.2: `DAYLIGHT` | y/n/o | y/n/o
 |===
 
 .Properties supported
 |===
-3+h| In VTIMEZONE
+3+h| In `VTIMEZONE`
 | | Consume | Produce
-| Q2.1: TZID | y/n/o | y/n/o
-| Q2.2: LAST-MODIFIED | y/n/o | y/n/o
-| Q2.3: TZURL | y/n/o | y/n/o
-| Q2.4: XPROP | y/n/o | y/n/o
-3+h| In STANDARD
+| Q2.1: `TZID` | y/n/o | y/n/o
+| Q2.2: `LAST-MODIFIED` | y/n/o | y/n/o
+| Q2.3: `TZURL` | y/n/o | y/n/o
+| Q2.4: `XPROP` | y/n/o | y/n/o
+3+h| In `STANDARD`
 | | Consume | Produce
-| Q3.1: DTSTART | y/n/o | y/n/o
-| Q3.2: TZOFFSETTO | y/n/o | y/n/o
-| Q3.3: TZOFFSETFROM | y/n/o | y/n/o
-| Q3.4: COMMENT | y/n/o | y/n/o
-| Q3.5: RDATE | y/n/o | y/n/o
-| Q3.6: RRULE | y/n/o | y/n/o
-| Q3.7: TZNAME | y/n/o | y/n/o
-| Q3.8: XPROP | y/n/o | y/n/o
-3+h| In DAYLIGHT
+| Q3.1: `DTSTART` | y/n/o | y/n/o
+| Q3.2: `TZOFFSETTO` | y/n/o | y/n/o
+| Q3.3: `TZOFFSETFROM` | y/n/o | y/n/o
+| Q3.4: `COMMENT` | y/n/o | y/n/o
+| Q3.5: `RDATE` | y/n/o | y/n/o
+| Q3.6: `RRULE` | y/n/o | y/n/o
+| Q3.7: `TZNAME` | y/n/o | y/n/o
+| Q3.8: `XPROP` | y/n/o | y/n/o
+3+h| In `DAYLIGHT`
 | | Consume | Produce
-| Q4.1: DTSTART | y/n/o | y/n/o
-| Q4.2: TZOFFSETTO | y/n/o | y/n/o
-| Q4.3: TZOFFSETFROM | y/n/o | y/n/o
-| Q4.4: COMMENT | y/n/o | y/n/o
-| Q4.5: RDATE | y/n/o | y/n/o
-| Q4.6: RRULE | y/n/o | y/n/o
-| Q4.7: TZNAME | y/n/o | y/n/o
-| Q4.8: XPROP | y/n/o | y/n/o
+| Q4.1: `DTSTART` | y/n/o | y/n/o
+| Q4.2: `TZOFFSETTO` | y/n/o | y/n/o
+| Q4.3: `TZOFFSETFROM` | y/n/o | y/n/o
+| Q4.4: `COMMENT` | y/n/o | y/n/o
+| Q4.5: `RDATE` | y/n/o | y/n/o
+| Q4.6: `RRULE` | y/n/o | y/n/o
+| Q4.7: `TZNAME` | y/n/o | y/n/o
+| Q4.8: `XPROP` | y/n/o | y/n/o
 |===
 
 === General
@@ -331,7 +331,7 @@ if yes to Q7, then
 
   \______\______\_________
 
-  Q10: Do you have a special naming scheme for TZIDs, and if so what is it?
+  Q10: Do you have a special naming scheme for ``TZID``s, and if so what is it?
 
   \______\______\_________
 
@@ -347,7 +347,7 @@ Q13: Do you accept and use timezone definitions from imported iCalendar data? y/
 
 if yes to Q13, then
 {
-  Q14: Do you attempt to merge timezone definitions with the same TZID when importing iCalendar data? y/n/o
+  Q14: Do you attempt to merge timezone definitions with the same `TZID` when importing iCalendar data? y/n/o
 }
 
 Q15: When exporting timezones in iCalendar data (either to a file or via iTIP) do you send the entire timezone definition or just the set of dates needed for coverage of the event?

sources/cc-report-roundtable-2.adoc → sources/cc-0511-report-roundtable-2/document.adoc

@@ -12,7 +12,6 @@
 :mn-output-extensions: xml,html,pdf,rxl
 :local-cache-only:
 
-
 .Foreword
 The Calendaring and Scheduling Consortium ("`CalConnect`") is a global non-profit
 organization with the aim to facilitate interoperability of technologies across

sources/cc-report-roundtable-3.adoc → sources/cc-0512-report-roundtable-3/document.adoc

@@ -12,7 +12,6 @@
 :mn-output-extensions: xml,html,pdf,rxl
 :local-cache-only:
 
-
 .Foreword
 The Calendaring and Scheduling Consortium ("`CalConnect`") is a global non-profit
 organization with the aim to facilitate interoperability of technologies across

sources/cc-report-roundtable-4.adoc → sources/cc-0513-report-roundtable-4/document.adoc

@@ -12,7 +12,6 @@
 :mn-output-extensions: xml,html,pdf,rxl
 :local-cache-only:
 
-
 .Foreword
 The Calendaring and Scheduling Consortium ("`CalConnect`") is a global non-profit
 organization with the aim to facilitate interoperability of technologies across

sources/cc-dst-advisory-notice.adoc → sources/cc-0514-dst-adv-notice/document.adoc

@@ -11,7 +11,6 @@
 :mn-document-class: cc
 :mn-output-extensions: xml,html,pdf,rxl
 :local-cache-only:
-:imagesdir: images/overview-0508
 
 .Foreword