diff --git a/.github/workflows/docker.yml b/.github/workflows/docker.yml index 8c3ea0c..afc9da7 100644 --- a/.github/workflows/docker.yml +++ b/.github/workflows/docker.yml @@ -1,70 +1,49 @@ -# Auto-generated by Cimas: Do not edit it manually! -# See https://github.com/metanorma/cimas name: docker on: push: - branches: [ master ] + branches: [ main ] pull_request: - paths-ignore: - - .github/workflows/macos.yml - - .github/workflows/ubuntu.yml - - .github/workflows/windows.yml + workflow_dispatch: + +permissions: + contents: read + pages: write + id-token: write + +concurrency: + group: ${{ github.workflow }}-${{ github.head_ref || github.ref_name }} + cancel-in-progress: true jobs: - test-docker: + build: runs-on: ubuntu-latest - container: docker://metanorma/mn + container: + image: metanorma/metanorma:latest steps: - - uses: actions/checkout@master - - name: Checkout submodules - shell: bash - run: | - auth_header="$(git config --local --get http.https://github.com/.extraheader)" - git submodule sync --recursive - git -c "http.extraheader=$auth_header" -c protocol.version=2 submodule update --init --force --recursive --depth=1 - - name: Setup fonts - run: | - # We need to do this to install mscorefonts - apt-add-repository -y contrib - apt-get update - echo ttf-mscorefonts-installer msttcorefonts/accepted-mscorefonts-eula select true | debconf-set-selections - apt-get install -y ttf-mscorefonts-installer - curl -Ls https://raw.githubusercontent.com/metanorma/vista-fonts-installer/master/vista-fonts-installer.sh | bash - - name: Install gems from local Gemfile - run: | - curl -LO --retry 3 https://raw.githubusercontent.com/metanorma/metanorma-build-scripts/master/gemfile-to-bundle-add.sh | bash - - name: Build document in the Metanorma container - env: - LC_ALL: C.UTF-8 - LANG: C.UTF-8 - LANGUAGE: C.UTF-8 - run: | - metanorma site generate . -c metanorma.yml - - uses: actions/upload-artifact@master + - name: Checkout + uses: actions/checkout@v4 + with: + submodules: true + + - name: Bundler install + uses: metanorma/ci/docker-gem-install@main + + - name: Metanorma generate site + uses: actions-mn/build-and-publish@v2 with: - name: site - path: site + destination: gh-pages + agree-to-terms: true + use-bundler: true - deploy-gh-pages: - if: github.ref == 'refs/heads/master' + deploy: + if: ${{ github.ref_name == github.event.repository.default_branch }} + environment: + name: github-pages + url: ${{ steps.deployment.outputs.page_url }} runs-on: ubuntu-latest - needs: test-docker + needs: build steps: - - uses: actions/checkout@master - - uses: actions/download-artifact@v1 - with: - name: site - - name: Deploy to GH Pages - uses: peaceiris/actions-gh-pages@v3 - with: - deploy_key: ${{ secrets.GH_DEPLOY_KEY }} - publish_dir: ./site - force_orphan: true - user_name: ${{ github.actor }} - user_email: ${{ format('{0}@users.noreply.github.com', github.actor) }} - commit_message: "${{ format('Deploy to GitHub Pages: {0}', github.sha) }}" - - uses: kolpav/purge-artifacts-action@v1 - with: - token: ${{ secrets.GITHUB_TOKEN }} - expire-in: 0 + - name: Deploy to GitHub Pages + id: deployment + uses: actions/deploy-pages@v4 diff --git a/Gemfile.lock b/Gemfile.lock deleted file mode 100644 index fda0668..0000000 --- a/Gemfile.lock +++ /dev/null @@ -1,331 +0,0 @@ -GEM - remote: https://rubygems.org/ - specs: - addressable (2.7.0) - public_suffix (>= 2.0.2, < 5.0) - asciidoctor (2.0.12) - asciimath (2.0.2) - bibtex-ruby (6.0.0) - latex-decode (~> 0.0) - blankslate (3.1.3) - camertron-eprun (1.1.1) - cldr-plurals-runtime-rb (1.1.0) - cnccs (0.1.6) - coderay (1.1.3) - concurrent-ruby (1.1.7) - domain_name (0.5.20190701) - unf (>= 0.0.5, < 1.0.0) - down (5.2.0) - addressable (~> 2.5) - expressir (0.2.6) - rice (~> 2.2.0) - thor (~> 1.0) - faraday (1.0.1) - multipart-post (>= 1.2, < 3) - ffi (1.14.2) - ffi-compiler2 (2.0.1) - ffi (>= 1.0.0) - rake - fontist (1.5.1) - down (~> 5.0) - git (~> 1.0) - libmspack (~> 0.1.0) - ruby-ole (~> 1.0) - rubyzip (~> 2.3.0) - seven_zip_ruby (~> 1.0) - thor (~> 1.0.1) - gb-agencies (0.0.7) - git (1.8.1) - rchardet (~> 1.8) - hashie (4.1.0) - html2doc (1.0.6) - asciimath (~> 2.0.0) - htmlentities (~> 4.3.4) - image_size - mime-types - nokogiri (>= 1.10.4) - plane1converter (~> 0.0.1) - thread_safe - uuidtools - htmlentities (4.3.4) - http-cookie (1.0.3) - domain_name (~> 0.5) - iev (0.2.4) - nokogiri (>= 1.10.4) - image_size (2.1.0) - iso-639 (0.3.5) - iso639 (1.3.2) - isodoc (1.3.1) - asciimath - html2doc (~> 1.0.0) - htmlentities (~> 4.3.4) - liquid - metanorma (~> 1.2.0) - nokogiri (>= 1.10.4) - relaton-cli - roman-numerals - thread_safe - twitter_cldr - uuidtools - isoics (0.1.9) - latex-decode (0.3.2) - latexmath (0.1.5) - htmlentities (~> 4.3) - ox (~> 2.13) - libmspack (0.1.0) - ffi - ffi-compiler2 (>= 2.0.0) - liquid (5.0.0) - lutaml (0.3.2) - lutaml-express (~> 0.1.3) - lutaml-uml (~> 0.2.5) - thor (~> 1.0) - lutaml-express (0.1.4) - expressir (~> 0.2.1) - lutaml-uml (0.2.8) - hashie (~> 4.1.0) - parslet (~> 1.7.1) - ruby-graphviz (~> 1.2) - thor (~> 1.0) - mathml2asciimath (0.0.10) - htmlentities (~> 4.3.4) - nokogiri (>= 1.10.4) - metanorma (1.2.2) - asciidoctor - htmlentities - mn2pdf (~> 1) - nokogiri - pry - metanorma-bipm (1.0.0) - metanorma-generic (~> 1.8.0) - metanorma-cc (1.6.2) - metanorma-generic (~> 1.8.0) - metanorma-cli (1.4.0) - git (~> 1.5) - isodoc (>= 1.3.0) - metanorma (~> 1.2.0) - metanorma-bipm (~> 1.0.0) - metanorma-cc (~> 1.6.0) - metanorma-csa (~> 1.7.0) - metanorma-generic (~> 1.8.0) - metanorma-iec (~> 1.2.0) - metanorma-ietf (~> 2.2.0) - metanorma-iho (~> 0.2.0) - metanorma-iso (~> 1.5.0) - metanorma-itu (~> 1.2.0) - metanorma-m3aawg (~> 1.6.0) - metanorma-nist (~> 1.2.0) - metanorma-ogc (~> 1.2.0) - metanorma-standoc (~> 1.6.0) - metanorma-un (~> 0.5.0) - relaton-cli (>= 0.8.2) - thor (~> 1.0) - metanorma-csa (1.7.0) - metanorma-generic (~> 1.8.0) - metanorma-generic (1.8.0) - htmlentities (~> 4.3.4) - isodoc (~> 1.3.0) - metanorma-standoc (~> 1.6.0) - ruby-jing - metanorma-iec (1.2.10) - metanorma-iso (~> 1.5.10) - ruby-jing - metanorma-ietf (2.2.5) - isodoc (~> 1.3.0) - mathml2asciimath - metanorma-standoc (~> 1.6.0) - metanorma-iho (0.2.9) - htmlentities (~> 4.3.4) - metanorma-generic (~> 1.8.0) - metanorma-iso (1.5.14) - isodoc (~> 1.3.0) - metanorma-standoc (~> 1.6.0) - mn2sts (~> 1.5.0) - ruby-jing - tokenizer (~> 0.3.0) - twitter_cldr - metanorma-itu (1.2.9) - htmlentities (~> 4.3.4) - isodoc (~> 1.3.0) - metanorma-standoc (~> 1.6.0) - ruby-jing - twitter_cldr - tzinfo-data - metanorma-m3aawg (1.6.2) - htmlentities (~> 4.3.4) - metanorma-generic (~> 1.8.0) - thread_safe - metanorma-nist (1.2.9) - htmlentities (~> 4.3.4) - iso-639 - isodoc (~> 1.3.0) - metanorma-standoc (~> 1.6.0) - ruby-jing - twitter_cldr - tzinfo-data - metanorma-ogc (1.2.9) - iso-639 - isodoc (~> 1.3.0) - metanorma-standoc (~> 1.6.0) - metanorma-plugin-datastruct (0.1.1) - asciidoctor (~> 2.0.0) - isodoc - liquid - metanorma - relaton-cli - metanorma-plugin-lutaml (0.2.3) - liquid - lutaml (~> 0.3.0) - lutaml-uml (~> 0.2.0) - metanorma - relaton-cli - metanorma-standoc (1.6.5) - asciidoctor (~> 2.0.0) - concurrent-ruby - fontist (~> 1.5.0) - iev (~> 0.2.1) - isodoc (~> 1.3.0) - latexmath - mathml2asciimath - metanorma-plugin-datastruct - metanorma-plugin-lutaml (~> 0.2.1) - mimemagic - relaton-cli (~> 1.7.0) - relaton-iev (~> 1.1.0) - ruby-jing - sterile (~> 1.0.14) - unicode2latex (~> 0.0.1) - metanorma-un (0.5.9) - iso-639 - isodoc (~> 1.3.0) - metanorma-standoc (~> 1.6.0) - roman-numerals - twitter_cldr - method_source (1.0.0) - mime-types (3.3.1) - mime-types-data (~> 3.2015) - mime-types-data (3.2020.1104) - mimemagic (0.3.5) - mn2pdf (1.25) - mn2sts (1.5.0) - multipart-post (2.1.1) - nokogiri (1.11.1-x86_64-darwin) - racc (~> 1.4) - optout (0.0.2) - ox (2.14.0) - parslet (1.7.1) - blankslate (>= 2.0, <= 4.0) - plane1converter (0.0.1) - pry (0.13.1) - coderay (~> 1.1) - method_source (~> 1.0) - public_suffix (4.0.6) - racc (1.5.2) - rake (13.0.3) - rchardet (1.8.0) - relaton (1.7.1) - relaton-bipm (~> 1.7.0) - relaton-calconnect (~> 1.7.0) - relaton-gb (~> 1.7.0) - relaton-iec (>= 1.7.3) - relaton-ieee (~> 1.7.0) - relaton-ietf (~> 1.7.0) - relaton-iho (~> 1.7.0) - relaton-iso (>= 1.7.1) - relaton-itu (>= 1.7.2) - relaton-nist (>= 1.7.1) - relaton-ogc (~> 1.7.0) - relaton-omg (~> 1.7.0) - relaton-un (~> 1.7.0) - relaton-w3c (~> 1.7.0) - relaton-bib (1.7.1) - addressable - bibtex-ruby - iso639 - nokogiri - relaton-bipm (1.7.0) - relaton-bib (~> 1.7.0) - relaton-calconnect (1.7.0) - faraday - relaton-bib (~> 1.7.0) - relaton-cli (1.7.0) - liquid - relaton (~> 1.7.0) - thor - relaton-gb (1.7.0) - cnccs (~> 0.1.1) - gb-agencies (~> 0.0.1) - relaton-iso-bib (>= 1.7.0) - relaton-iec (1.7.4) - addressable - relaton-iso-bib (~> 1.7.0) - relaton-ieee (1.7.1) - faraday (~> 1.0.0) - relaton-bib (~> 1.7.0) - relaton-ietf (1.7.0) - relaton-bib (~> 1.7.0) - relaton-iev (1.1.0) - relaton (>= 1.6) - relaton-iho (1.7.0) - relaton-bib (~> 1.7.0) - relaton-iso (1.7.1) - relaton-iec (~> 1.7.0) - relaton-iso-bib (~> 1.7.0) - relaton-iso-bib (1.7.0) - isoics (~> 0.1.6) - relaton-bib (~> 1.7.0) - relaton-itu (1.7.3) - relaton-bib (~> 1.7.0) - relaton-nist (1.7.2) - relaton-bib (~> 1.7.0) - rubyzip - relaton-ogc (1.7.0) - faraday (~> 1.0.0) - relaton-iso-bib (~> 1.7.0) - relaton-omg (1.7.0) - relaton-bib (~> 1.7.0) - relaton-un (1.7.0) - faraday - http-cookie - relaton-bib (~> 1.7.0) - unf_ext (>= 0.0.7.7) - relaton-w3c (1.7.0) - relaton-bib (>= 1.7.0) - rexml (3.2.4) - rice (2.2.0) - roman-numerals (0.3.0) - ruby-graphviz (1.2.5) - rexml - ruby-jing (0.0.1) - optout (>= 0.0.2) - ruby-ole (1.2.12.2) - rubyzip (2.3.0) - seven_zip_ruby (1.3.0) - sterile (1.0.19) - nokogiri (>= 1.10.8) - thor (1.0.1) - thread_safe (0.3.6) - tokenizer (0.3.0) - twitter_cldr (6.4.0) - camertron-eprun - cldr-plurals-runtime-rb (~> 1.1) - tzinfo - tzinfo (2.0.4) - concurrent-ruby (~> 1.0) - tzinfo-data (1.2020.6) - tzinfo (>= 1.0.0) - unf (0.1.4) - unf_ext - unf_ext (0.0.7.7) - unicode2latex (0.0.4) - uuidtools (2.2.0) - -PLATFORMS - ruby - x86_64-darwin-19 - -DEPENDENCIES - metanorma-cli - -BUNDLED WITH - 2.2.1 diff --git a/README.adoc b/README.adoc index 915ad2a..c8d8edc 100644 --- a/README.adoc +++ b/README.adoc @@ -1,48 +1,90 @@ -= CalConnect Conference and IOP Testing Reports += CalConnect administrative documents -This repository contains CSD sources, and gets rendered into a Relaton collection mini-site. +This repository contains CalConnect administrative document sources. -image:https://travis-ci.com/CalConnect/csd-admin-documents.svg?branch=master["Build Status", link="https://travis-ci.com/CalConnect/csd-admin-documents"] +image:https://github.com/CalConnect/cc-admin-documents/workflows/docker/badge.svg["Docker Build Status", link="https://github.com/CalConnect/cc-admin-documents/actions/workflows/docker.yml"] -== Access +Published documents are available here: -Documents in this repository are available through the deployed mini-site: +* https://calconnect.github.io/cc-admin-documents/[CalConnect Conference and IOP Testing Reports] -* https://calconnect.github.io/csd-admin-documents/[CalConnect Conference and IOP Testing Reports] +== Purpose -== Fetching the documents +This repository holds the Metanorma source markup for CalConnect +administrative documents. + +These documents include: + +* CalConnect Conference Reports (and associated documents) +* CalConnect IOP Testing Reports +* CalConnect Advisory Notices + +NOTE: These administrative documents, prior to 2024, were published in PDF +format only. This repository contains the re-encoded documents in the Metanorma +format in order to facilitate future updates and publication in multiple +formats. -[source,sh] ----- -git clone https://github.com/CalConnect/csd-admin-documents ----- -== Install Build Tools +== Structure -See https://www.metanorma.com/[Metanorma setup]. +The repository is structured as follows: +`metanorma.yml`:: Metanorma site manifest that lists the documents to be +included in the site. -== Build +`sources/`:: Source documents in Metanorma format. + +`sources/cc-{docnumber}-{title}`:: Directory for each document, named by +document number and a shorthand title. + +`sources/cc-{docnumber}-{title}/document.adoc`:: Metanorma root document for +the document. + + +== Fetching the document [source,sh] ---- -make clean all +git clone https://github.com/CalConnect/cc-admin-documents/ ---- -== Open the generated HTML index + +== Installing build tools + +See https://www.metanorma.org/install/ + + +== Building the documents + +=== Full set + +Run the following command to build the full collection of the documents. [source,sh] ---- -open documents.html +$ bundle exec metanorma site generate --agree-to-terms ---- -== Publish +=== Single document + +Run the following command to build a single document. +.Compile a single document [source,sh] ---- -make publish +$ bundle exec metanorma sources/cc-1903-report-conference-46/document.adoc ---- -The generated HTML site will be prepared in `published/`. +=== Outputs + +The following outputs will be built: + +Index of all documents:: `_site/index.html` + +Individual document outputs:: `_site/documents/` (HTML, PDF, MN XML) + + +== License +Copyright CalConnect. diff --git a/metanorma.yml b/metanorma.yml index eac239f..3ee44cd 100644 --- a/metanorma.yml +++ b/metanorma.yml @@ -2,27 +2,158 @@ metanorma: source: files: - - sources/csd-report-conference-36.adoc - - sources/csd-report-conference-37.adoc - - sources/csd-report-conference-38.adoc - - sources/csd-report-conference-39.adoc - - sources/csd-report-conference-40.adoc - - sources/csd-report-conference-41.adoc - - sources/csd-report-conference-42.adoc - - sources/csd-report-conference-43.adoc - - sources/csd-report-conference-44.adoc - - sources/csd-report-conference-45.adoc - - sources/csd-report-ioptestevent-35.adoc - - sources/csd-report-ioptestevent-36.adoc - - sources/csd-report-ioptestevent-37.adoc - - sources/csd-report-ioptestevent-38.adoc - - sources/csd-report-ioptestevent-39.adoc - - sources/csd-report-ioptestevent-40.adoc - - sources/csd-report-ioptestevent-41.adoc - - sources/csd-report-ioptestevent-42.adoc + - sources/cc-0001-report-ioptest/document.adoc + - sources/cc-0101-report-ioptest/document.adoc + - sources/cc-0201-report-ioptest/document.adoc + - sources/cc-0401-ioptest-rules/document.adoc + - sources/cc-0402-ioptest-results/document.adoc + - sources/cc-0403-report-ioptest/document.adoc + - sources/cc-0404-report-roundtable-1/document.adoc + - sources/cc-0501-ioptest-rules/document.adoc + - sources/cc-0502-report-ioptest/document.adoc + - sources/cc-0503-ioptest-rules/document.adoc + - sources/cc-0504-report-ioptest/document.adoc + - sources/cc-0505-questionnaire-results-recurrence/document.adoc + - sources/cc-0506-report-ioptest/document.adoc + - sources/cc-0507-caldav-use-cases/document.adoc + - sources/cc-0508-pres-overview/document.adoc + - sources/cc-0509-pres-overview/document.adoc + - sources/cc-0510-questionnaire-results-timezone/document.adoc + - sources/cc-0511-report-roundtable-2/document.adoc + - sources/cc-0512-report-roundtable-3/document.adoc + - sources/cc-0513-report-roundtable-4/document.adoc + - sources/cc-0514-dst-adv-notice/document.adoc + - sources/cc-0601-miniop-usecases-1.0/document.adoc + - sources/cc-0601-miniop-usecases-v1.1/document.adoc + - sources/cc-0602-ical-tz-problems/document.adoc + - sources/cc-0603-report-ioptest/document.adoc + - sources/cc-0604-ical-recurrence-problems/document.adoc + - sources/cc-0605-pres-omads-briefing/document.adoc + - sources/cc-0606-timezone-registry/document.adoc + - sources/cc-0607-report-ioptest/document.adoc + - sources/cc-0608-pres-fb-demo/document.adoc + - sources/cc-0609-questionnaire-results-mobcal/document.adoc + - sources/cc-0610-cs-glossary-v1/document.adoc + - sources/cc-0611-ical-benefits/document.adoc + - sources/cc-0612-report-ioptest/document.adoc + - sources/cc-0613-report-roundtable-5/document.adoc + - sources/cc-0614-report-roundtable-6/document.adoc + - sources/cc-0615-report-roundtable-7/document.adoc + - sources/cc-0701-miniop-usecases-tasks/document.adoc + - sources/cc-0702-report-ioptest/document.adoc + - sources/cc-0703-caldav-scheduling-reqs/document.adoc + - sources/cc-0704-report-ioptest/document.adoc + - sources/cc-0705-pres-overview/document.adoc + - sources/cc-0706-ioptest-suite/document.adoc + - sources/cc-0706-ioptest-suite-v1.1/document.adoc + - sources/cc-0707-edst-reflections-v1/document.adoc + - sources/cc-0707-edst-reflections-v1.1/document.adoc + - sources/cc-0708-dst-review/document.adoc + - sources/cc-0709-dst-links/document.adoc + - sources/cc-0710-report-ioptest/document.adoc + - sources/cc-0711-report-roundtable-8/document.adoc + - sources/cc-0712-report-roundtable-9/document.adoc + - sources/cc-0713-report-roundtable-10/document.adoc + - sources/cc-0714-report-vcard-workshop/document.adoc + - sources/cc-0801-pres-preview-roundtable-11/document.adoc + - sources/cc-0802-report-ioptest/document.adoc + - sources/cc-0803-report-ioptest/document.adoc + - sources/cc-0804-report-ioptest/document.adoc + - sources/cc-0805-mobile-recurrence-iop/document.adoc + - sources/cc-0806-pres-preview-roundtable-13/document.adoc + - sources/cc-0807-report-ioptest/document.adoc + - sources/cc-0808-report-ioptest/document.adoc + - sources/cc-0809-report-roundtable-11/document.adoc + - sources/cc-0810-report-roundtable-12/document.adoc + - sources/cc-0811-report-roundtable-13/document.adoc + + - sources/cc-0812-pres-meet-cc/collection.yml + - sources/cc-0812-pres-meet-cc/pres-intro-01.adoc + - sources/cc-0812-pres-meet-cc/pres-intro-02.adoc + - sources/cc-0812-pres-meet-cc/pres-iop-testing.adoc + - sources/cc-0812-pres-meet-cc/pres-ischedule.adoc + - sources/cc-0812-pres-meet-cc/pres-tc-mobile.adoc + - sources/cc-0812-pres-meet-cc/pres-bedework.adoc + - sources/cc-0812-pres-meet-cc/pres-stockholm.adoc + + - sources/cc-0901-report-roundtable-14/document.adoc + - sources/cc-0902-report-ioptest/document.adoc + - sources/cc-0903-freebusy-read-url/document.adoc + - sources/cc-0904-xcal/document.adoc + - sources/cc-0905-state-of-resource-iop/document.adoc + - sources/cc-0906-resources-usecases/document.adoc + - sources/cc-0907-miniop-resource-info/document.adoc + - sources/cc-0908-report-roundtable-15/document.adoc + - sources/cc-0909-report-ioptest/document.adoc + - sources/cc-0910-report-roundtable-16/document.adoc + - sources/cc-0911-report-ioptest/document.adoc + - sources/cc-1001-report-roundtable-17/document.adoc + - sources/cc-1002-report-ioptest/document.adoc + - sources/cc-1003-schema-resources/document.adoc + - sources/cc-1004-calws-api/document.adoc + - sources/cc-1005-report-roundtable-18/document.adoc + - sources/cc-1006-link-extension/document.adoc + - sources/cc-1007-timezone-protocol/document.adoc + - sources/cc-1008-timezone-xml/document.adoc + - sources/cc-1009-report-ioptest/document.adoc + - sources/cc-1010-report-ioptest/document.adoc + - sources/cc-1011-calws-rest-v1/document.adoc + - sources/cc-1011-calws-rest-v1.0.1/document.adoc + - sources/cc-1012-ical-intro-v1/document.adoc + - sources/cc-1012-ical-intro-v1.1/document.adoc + - sources/cc-1013-report-roundtable-19/document.adoc + - sources/cc-1014-report-ioptest/document.adoc + - sources/cc-1101-ical-extensions/document.adoc + - sources/cc-1102-cs-glossary-v2/document.adoc + - sources/cc-1103-report-roundtable-20/document.adoc + - sources/cc-1104-cs-index/document.adoc + - sources/cc-1105-report-roundtable-21/document.adoc + - sources/cc-1106-report-roundtable-22/document.adoc + - sources/cc-1201-report-roundtable-23/document.adoc + - sources/cc-1202-calws-soap/document.adoc + - sources/cc-1203-report-roundtable-24/document.adoc + - sources/cc-1204-report-roundtable-25/document.adoc + - sources/cc-1301-calws-soap/document.adoc + - sources/cc-1302-report-roundtable-26/document.adoc + - sources/cc-1303-report-ioptestevent-26/document.adoc + - sources/cc-1304-report-roundtable-27/document.adoc + - sources/cc-1305-report-ioptestevent-27/document.adoc + - sources/cc-1306-report-roundtable-28/document.adoc + - sources/cc-1307-report-ioptestevent-28/document.adoc + - sources/cc-1401-report-roundtable-29/document.adoc + - sources/cc-1402-report-ioptestevent-29/document.adoc + - sources/cc-1403-workshop-30/document.adoc + - sources/cc-1404-report-ioptestevent-30/document.adoc + - sources/cc-1405-report-conference-30/document.adoc + - sources/cc-1406-report-conference-31/document.adoc + - sources/cc-1407-report-ioptestevent-31/document.adoc + - sources/cc-1501-report-conference-32/document.adoc + - sources/cc-1502-report-ioptestevent-32/document.adoc + - sources/cc-1503-report-conference-33/document.adoc + - sources/cc-1504-report-ioptestevent-33/document.adoc + - sources/cc-1505-report-ioptestevent-34/document.adoc + - sources/cc-1506-report-conference-34/document.adoc + - sources/cc-1601-report-conference-35/document.adoc + - sources/cc-1602-report-ioptestevent-35/document.adoc + - sources/cc-1603-report-conference-36/document.adoc + - sources/cc-1604-report-ioptestevent-36/document.adoc + - sources/cc-1605-report-conference-37/document.adoc + - sources/cc-1606-report-ioptestevent-37/document.adoc + - sources/cc-1701-report-conference-38/document.adoc + - sources/cc-1702-report-ioptestevent-38/document.adoc + - sources/cc-1703-report-conference-39/document.adoc + - sources/cc-1704-report-ioptestevent-39/document.adoc + - sources/cc-1705-report-conference-40/document.adoc + - sources/cc-1706-report-ioptestevent-40/document.adoc + - sources/cc-1801-report-conference-41/document.adoc + - sources/cc-1802-report-ioptestevent-41/document.adoc + - sources/cc-1803-report-conference-42/document.adoc + - sources/cc-1804-report-ioptestevent-42/document.adoc + - sources/cc-1805-report-conference-43/document.adoc + - sources/cc-1901-report-conference-44/document.adoc + - sources/cc-1902-report-conference-45/document.adoc + - sources/cc-1903-report-conference-46/document.adoc -relaton: collection: - name: CalConnect Conference and IOP Testing Reports organization: CalConnect - + name: Administrative Documents (incl. Conference and IOP Testing Reports) diff --git a/sources/cc-0001-report-ioptest/document.adoc b/sources/cc-0001-report-ioptest/document.adoc new file mode 100644 index 0000000..a6cc817 --- /dev/null +++ b/sources/cc-0001-report-ioptest/document.adoc @@ -0,0 +1,95 @@ += CalConnect I -- April, 2000 +:docnumber: 0001 +:copyright-year: 2000 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2000-04-12 +:published-date: 2000-04-12 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + +== Introduction + +On April 11 and 12, 2000, CalConnect Spring was held in Boston. It was graciously hosted by +MIT and chaired by Bob Mahoney. + +=== Participants + +The following companies and representatives were in attendance: + +* Tom Ransdell, Lotus, +* Dan Gurney, Iris/Lotus, +* John Sun, iPlanet, +* Ki Wong, iPlanet, +* Katia Hage, Microsoft, +* Colin DuPlantis, Critical Path, +* Bob Mahoney, MIT, +* Paul Hill, MIT. + +Pat Egen sat at home with a broken leg, and assisted (poorly) from the sidelines. + +=== Products Tested + +The following products and versions were tested: + +* EventCenter Version 3.0 (Critical Path) +* Outlook 2000 and Outlook Express 5.0 (Microsoft) +* iPlanet - internal unreleased alpha version iCS 5.0, server and client (Netscape) +* Organizer (Lotus) + +== General Summary + +First off, thanks to everyone for their efforts. There was consensus that all participants have a +lot of work to do, and that another testing event should be held in the fall. A west coast location +was suggested, although some interest was also expressed for New Orleans or San Antonio. All +participants felt that great progress would be made in the coming months. + +Little interoperability has occurred so far. Repeating events and canceled events seem to be +causing problems. Parsers are working OK but the actual generation of the data objects is very +inconsistent. + +Problems found with recurrence included the following: + +* one vendor always generates and expects ``RRULE``s, but cannot handle ``RDATE``s. +* two vendors always generate ``RDATE``s and cannot currently handle ``RRULE``s. +* one vendor handles ``RRULE``s but cannot handle exceptions. + +There was a brief discussion about redesigning recurrence. Some useful alternatives were +suggested but the developers also seemed to be willing to live with the current specification. +They did feel that word-smithing would help. This will be brought back to the list in more detail +for some review. + +The biggest complaints are currently with iMIP and the MIME handling. "iMIP under-constrains +what may be emitted by a data source; this requires a client to handle every possible case" which +is perceived as a heavy burden by the developers. + +Regarding MIME: "(multipart mixed vs. multipart alternative vs. text-alternative vs.attachments +...)" - the developers would be happier if there fewer options, or perhaps some stronger assertions +in the draft. This too will be put on the list. + +There has been virtually no interoperability testing of alarms yet. There were some side issues +relating to alarms, which will be brought back to the list. + +There has been virtually no testing of conformance with line lengths yet. + +A number of minor problems with blank spaces, terminating lines, and MIME boundaries were +observed and are in the process of being fixed by the implementors. + +No tester has fully implemented Journals. One vendor has the support in the parser but no +support in the front end, so they cannot be generated or displayed by the product. All of the +implementors indicate that supporting Journals is intended and that no obstacles are seen, they are +just lower on the priority list so far. + +There has been no testing of signed or encrypted objects. This should be a major goal of the next +testing event. + +Some progress is better than no progress. Look for additional activity on the list as we post some +of the items referenced above. CalConnect Fall will be announced later in the year. + +Respectfully submitted, + +Pat Egen and Bob Mahoney diff --git a/sources/cc-0101-report-ioptest/document.adoc b/sources/cc-0101-report-ioptest/document.adoc new file mode 100644 index 0000000..3a26a93 --- /dev/null +++ b/sources/cc-0101-report-ioptest/document.adoc @@ -0,0 +1,346 @@ += CalConnect II -- April, 2001 +:docnumber: 0101 +:copyright-year: 2001 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2001-04-13 +:published-date: 2001-04-13 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + +== Introduction + +IETF CALSCH Working Group Interoperability Testing . Held Wed. April 11, 2001 - Fri. April +13, 2001 - 8:30 a.m. - 6:00 p.m. + +This second interop test was held at Stanford University in Palo Alto, CA. Stanford gratiously +donated the use of their facilities and network in order to help further the movement of our +standards. This interop focused on iCalendar, iTIP and iMIP. The testing matrix can be found +on www.calsch.org. + +The first day Pat Egen, IETF CALSCH working group co-chair introduced everyone and +established the ground rules as well as let everyone know the network logistics within Stanford +and to her server at www.egenconsulting.com. + +=== Participants + +The participants were: + +* George Babics, Steltor: georgeb@steltor.com +* Alan Davies, Steltor: aland@steltor.com +* Tom Ransdell, Iris: transdell@iris.com +* Anita Paci, Iris: apaci@iris.com +* John Sun, Netscape: jsun@netscape.com +* Malika Parekh, Netscape: malika@netscape.com +* Pat Egen pregen@egenconsulting.com + +=== Products and Releases Tested + +==== Steltor + +* CorporateTime Server 6.0 Alpha +* CorporateTime Outlook Connector 3.0 +* CorporateTime Native Client 6.0 Alpha +* CorporateTime iMIP/iTIP Alpha Helper Application + +==== Lotus/Iris + +* Lotus Domino and Notes Release RNext + +==== iPlanet + +* Calendar Server Version 5.next + +== General Summary + +These notes are "homogenized" - in other words, names of vendors have been removed so you +can't tell who is who. Once the draft moves forward, we will post which vendor supports which +component. For purposes of this document, I will call them Vendor 1, Vendor 2 and Vendor 3. I +have also included a section with general notes as related by each vendor. + +=== Vendor 1 notes/results + +Overall there was good interoperability. In general the vendors were able to interoperate. They +were able to invite, reply, reschedule, and cancel to single instance meetings. There was some +problems with the timezones that were used in recurrence rules, as a result only minimal testing +was done with events with multiple occurrences. Finally, even though Microsoft was not there, +some interoperability was done with Outlook. + +[%unnumbered,options=header,headerrows=2] +|=== +| 2+| Vendor 1 2+| Vendor 2 2+|Vendor 3 +| iTIP Methods | Send | Accept | Send | Accept | Send | Accept + +| Request (Single Instance Event) | yes | yes | yes | yes | yes | yes +| Request (Multiple Instance Event without `RRULE`) | yes | yes | yes | yes | yes | yes +| Request (Multiple Instance Event with `RRULE`) | yes | yes | no | no | no | yes +| Reply | yes | yes | yes | yes | no | yes +| Add | no | yes{blank}footnote:ut[untested] | no | yes{blank}footnote:ut[] | no | no +| Cancel | yes | yes | yes | yes | yes | ? +| Counter | no | yes{blank}footnote:ut[] | ? | ? | no | no +| Decline-Counter | no | yes{blank}footnote:ut[] | ? | ? | no | no +| Refresh | no | yes | yes | yes{blank}footnote:ut[] | no | no +| Publish | no | yes{blank}footnote:ut[] | no | yes{blank}footnote:ut[] | no | yes + +7+h| Components +| `VEVENT` | yes | yes | yes | yes | yes | yes +| `VJOURNAL` | no | no | no | no | no | no +| `VTODO` | no | no | yes | yes{blank}footnote:ut[] | no | yes{blank}footnote:ut[] +| `VTIMEZONE` | yes | yes | no | no | no | yes +| `VALARMS` | no | yes{blank}footnote:ut[] | no | yes{blank}footnote:ut[] | no | no +|=== + +NOTE: "no" indicates that a vendor was unable to support a feature due to not implementing it, +bugs, or due to misinterpretation of the RFCs + +==== Other Things That Worked + +* Vendor1 was able to invite using recurrence rules +* Vendor2 was able to delegate +* Vendor2 was able to send ``VTODO``s + +What did not work: + +* Vendor 2 was unable to support more than one instance on the same day +* No one supported sending floating time events +* Vendor 2 did not support event duration less than fifteen minutes +* Vendor 3 did not support slash format in ``RDATE``s +* Vendor 2 was unable to send a response if `RSVP` was false (point for future discussion about +meaning of RSVP) +* Vendor 3 did not escape any of their special characters +* Some of Vendor 2's lines were longer than permitted in iCalendar + +=== Vendor 2 notes/results + +[%unnumbered,options=header] +|=== +| iCalendar Method | Vendor 2 supported | Test with Vendor 1 | Test with Vendor 3 +| *Event Publish* | yes | not tested | not tested +| _Event Publish_ | yes | not tested | not tested +| Event Request | - | - | - +| New Event | - | - | - +| *non repeating* | yes | tested | tested +| _non repeating_ | yes | tested | tested +| *`RRULE` repeating no exceptions* | yes | tested | tested +| _`RRULE` repeating no exceptions_ | yes | tested | tested +| *`RRULE` with `EXRULE`* | will not create | not tested | not tested +| _`RRULE` with `EXRULE`_ | yes | not tested | not tested +| *`RRULE` with ``EXDATE``s* | will not create | not tested | not tested +| _`RRULE` with ``EXDATE``s_ | yes | not tested | not tested +| *``RDATE``s repeating no exceptions* | yes | not tested | not tested +| _``RDATE``s repeating no exceptions_ | yes | not tested | not tested +| *``RDATE``s with `EXRULE`* | will not create | not tested | not tested +| _``RDATE``s with `EXRULE`_ | yes | not tested | not tested +| *``RDATE``s with ``EXDATE``s* | will not create | not tested | not tested +| _``RDATE``s with ``EXDATE``s_ | yes | not tested | not tested +| *with attachment* | yes | not tested | not tested +| _with attachment_ | yes | not tested | not tested +| Broadcast | - | - | - +| *non repeating* | yes | tested | not tested +| _non repeating_ | yes | tested | ? +| *`RRULE` repeating no exceptions* | yes | not tested | not tested +| _`RRULE` repeating no exceptions_ | yes | not tested | not tested +| *`RRULE` with `EXRULE`* | will not create | not tested | not tested +| _`RRULE` with `EXRULE`_ | yes | not tested | not tested +| *`RRULE` with ``EXDATE``s* | will not create | not tested | not tested +| _`RRULE` with ``EXDATE``s_ | yes | not tested | not tested +| *``RDATE``s with no exceptions* | yes | not tested | not tested +| _``RDATE``s with no exceptions_ | yes | not tested | not tested +| *``RDATE``s with `EXRULE`* | will not create | not tested | not tested +| _``RDATE``s with `EXRULE`_ | yes | not tested | not tested +| *``RDATE``s with ``EXDATE``s* | will not create | not tested | not tested +| _``RDATE``s with ``EXDATE``s_ | yes | not tested | not tested +| *with attachment* | yes | not tested | not tested +| _with attachment_ | yes | not tested | not tested +| Reschedule | - | - | - +| *Non repeating* | yes | not tested | not tested +| _Non repeating_ | yes | not tested | not tested +| *Repeating all* | yes | not tested | not tested +| _Repeating all_ | yes | not tested | not tested +| *Individual event of repeat set* | yes | not tested | not tested +| _Individual event of repeat set_ | yes | not tested | not tested +| Update | - | - | - +| *Non repeating* | yes | not tested | not tested +| _Non repeating_ | yes | not tested | not tested +| *Repeating all* | yes | not tested | not tested +| _Repeating all_ | yes | not tested | not tested +| *Individual event of repeat set* | yes | not tested | not tested +| _Individual event of repeat set_ | yes | not tested | not tested +| Event Reply | - | - | - +| Accept | - | - | - +| *Non repeating* | yes | tested | tested +| _Non repeating_ | yes | tested | tested +| *Repeating all* | yes | tested | tested +| _Repeating all_ | yes | tested | tested +| *Individual event from repeat set* | yes | not tested | not tested +| _Individual event from repeat set_ | | not tested | not tested +| Decline | - | - | - +| *Non repeating* | yes | ? | ? +| _Non repeating_ | yes | ? | ? +| *Repeating all* | yes | ? | ? +| _Repeating all_ | yes | ? | ? +| *Individual event from repeat set* | yes | not tested | not tested +| _Individual event from repeat set_ | yes | not tested | not tested +| Delegate | - | - | - +| *Non repeating* | yes | not tested | not tested +| _Non repeating_ | yes | not tested | not tested +| *Repeating all* | yes | not tested | not tested +| _Repeating all_ | yes | not tested | not tested +| *Individual event from repeat set* | yes | not tested | not tested +| _Individual event from repeat set_ | yes | not tested | not tested +| Event Refresh Request | - | - | - +| *Non repeating* | yes | not tested | not tested +| _Non repeating_ | yes | not tested | not tested +| *Repeating all* | yes | not tested | not tested +| _Repeating all_ | yes | not tested | not tested +| Event Counter | - | - | - +| *Non repeating* | yes | not tested | not tested +| _Non repeating_ | yes | not tested | not tested +| *Repeating all* | yes | not tested | not tested +| _Repeating all_ | yes | not tested | not tested +| *Individual event from repeat set* | yes | not tested | not tested +| _Individual event from repeat set_ | yes | not tested | not tested +| *Event DeclineCounter* | yes | not tested | not tested +| _Event DeclineCounter_ | yes | not tested | not tested +| *Event Add* | not supported | not tested | not tested +| _Event Add_ | not supported | not tested | not tested +| Event Cancel | - | - | - +| *Cancel Non repeating* | yes | tested | tested +| _Cancel Non repeating_ | yes | tested | tested +| *Cancel Repeating all* | yes | tested | tested +| _Cancel Repeating all_ | yes | tested | tested +| *Cancel Individual event from repeat set* | yes | not tested | not tested +| _Cancel Individual event from repeat set_ | yes | not tested | not tested +| *Remove individual from non repeating* | yes | not tested | not tested +| _Remove individual from non repeating_ | yes | not tested | not tested +| *Remove individual from entire repeat set* | yes | not tested | not tested +| _Remove individual from entire repeat set_ | yes | not tested | not tested +| *Remove individual from individual event of RS* | yes | not tested | not tested +| _Remove individual from individual event of RS_ | yes | not tested | not tested +| *ToDo Publish* | yes | not tested | not tested +| _ToDo Publish_ | yes | not tested | not tested +| ToDo Request | - | - | - +| New ToDo | - | - | - +| *Non repeating* | yes | not tested | not tested +| _Non repeating_ | yes | not tested | not tested +| `RRULE` repeating no exceptions | yes | | +| `RRULE` with `EXRULE` | will not create | | +| `RRULE` with ``EXDATE``s | will not create | | +| `RDATE` repeating no exceptions | yes | | +| ``RDATE``s with `EXRULE` | will not create | | +| ``RDATE``s with ``EXDATE``s | will not create | | +| Reschedule | - | - | - +| Non repeating | yes | | +| Repeating all | yes | | +| Individual event of repeat set | yes | | +| Update | yes | | +| ToDo Reply | - | - | - +| Accept | - | - | - +| Non repeating | yes | | +| Repeating all | yes | | +| Individual event from repeat set | yes | | +| Decline | - | - | - +| Non repeating | yes | | +| Repeating all | yes | | +| Individual event from repeat set | yes | | +| ToDo Add | no | | +| ToDo Cancel | - | - | - +| Cancel Non repeating | yes | | +| Cancel Repeating all | yes | | +| Cancel Individual event from repeat set | yes | | +| Remove individual from non repeating | yes | | +| Remove individual from entire repeat set | yes | | +| Remove individual from individual event of RS | yes | | +| ToDo Refresh Request | yes | | +| ToDo Counter | - | - | - +| Non Repeating | yes | | +| Repeating all | yes | | +| Individual event from repeat set | yes | | +| ToDo DeclineCounter | yes | | +| FreeBusy Publish | not yet | | +| FreeBusy Request | not yet | | +| FreeBusy Reply | not yet | | +| VJournal Publish | no planned support | | +| VJournal Add | no planned support | | +| VJournal Cancel | no planned support | | +| Status Reply | not yet | | +|=== + +[NOTE] +==== +*Sending*:: *in this font*; +_Receiving_:: _in italics_. +==== + +Some issues found were UID problems and then in timezone problems. + +The only other interesting problem was distinguishing between removing a person and canceling. +From my point of view we did not end up doing a lot of testing. I am including a table of what +we support and what we tested. The table is not completed except for `EVENTS` + +Other Issues encountered while doing iCAL testing at CalConnect2. + +. Sent to a Bcc user via Location Doc: "Through xxxx Server/MIME format"; Person Doc: +"Prefers MIME". The Bcc user receives an invitation with all of the Typical Workflow +actions. Error: S/he should only have the "Add to Calendar" action. +. Reschedule notices are not displaying invitee response actions. +. Invitations from a French Vendor 3 client are received with no subject or date/time fields. +. Cancellation notices being received as Updates from vendor 1. Upon opening notice, you get +the correct pop-up indicating that the meeting has been cancelled and the entry is removed +from the Calendar. However, the "Update Calendar" button is not hidden, and if you click on +it it will recreate the entry. +. Cancellation of a repeating meeting from Vendor 3 doesn't remove entries from Calendar. +. Custom repeats from Vendor 3 (``RDATE``s) only display the first date in the "Repeat Options" +dialog in invitee's Calendar entry. + +=== Vendor 3 Results + +Comments from Vendor 3. + +. Vendor 2 and Vendor 1 can retrieve `EVENT REQUEST` messages from Vendor 3 +Server - But they would prefer that the Vendor 3 IMIP messages come in the +"multipart/mixed" MIME format. We have included this item in our bug list. +. We tried to import a `REPLY` from the other vendors. We were able to import Vendor 2's +`REPLY`. However, we could not import Vendor 1's `REPLY` messages. This was +because they were inserting the Recurrence-ID in the event `REPLY` message even +though it was a non-recurring `VEVENT`. Also, we had a bug in handling `RSVP`. We +were saving the change in the `RSVP` value of the attendee, which caused a UI bug. (In +our User Interface, the attendee was moved to an `INFORM`) +. Vendor 1 and 2 can receive our recurring `EVENT REQUEST` invitations. +. We can import Vendor 1 and 2's recurring `REPLY` messages. However, we get the same +number of e-mails as instances (i.e. 60 replies (messages) to 1 recurring event) +. We can import `CANCEL` messages from Vendor 1 +. Vendor 2 could not import our mail messages from a Spanish or French user. -- Vendor 1 +can display them OK using the Eudora mail program. +. We can import a recurring `REQUEST` from Vendor 2 +. Vendor 4 created an event. They sent two `REQUEST` messages, sequence=0, +sequence=1, the first one sent `RECURRENCE-ID`, the second one did not. This is +Vendor 1's bug, and they may have fixed it. + +What about others: + +. No one implemented `ADD`. +. No one tested `COUNTER` or `DECLINECOUNTER` + +The Vendor 3 team is working on fixing CalConnect-related bugs and will include the fixes in +future releases. + +=== Chair Comments + +This interop compared to the first one was a world of difference. Many many more things +worked and we were able to spend more time testing elements. + +While Vendor 2 shows a lot "Untested", after reading notes, I believe many of these items were +indeed tested. We have developed a new testing form that will be used on the next interop test. I +know one vendor felt we had not done enough testing - I think he really wanted to prove it all +works. Well, most of it did! We still have a ways to go, but for the first time, everyone feels that +we have made progress and there is a light at the end of the tunnel. The best part of the interop +was the interactions between the attendees. That will help ongoing efforts tremendously. +Everyone wants to do the next interop within the next 6-9 months. We don't want to wait too +long now that we have momentum. + +By Patricia Egen diff --git a/sources/cc-0201-report-ioptest/document.adoc b/sources/cc-0201-report-ioptest/document.adoc new file mode 100644 index 0000000..a26a5b7 --- /dev/null +++ b/sources/cc-0201-report-ioptest/document.adoc @@ -0,0 +1,193 @@ += CalConnect III -- Virtual interop, September, 2002 +:docnumber: 0201 +:copyright-year: 2002 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2002-09-01 +:published-date: 2002-09-01 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + +== Vendors and Products + +* Oracle Collaboration Suite - Calendar Server 9.0.4 Alpha +* Oracle Outlook Connector 3.3 +* Oracle CorporateTime Native Client 6.1 Alpha +* Oracle CorporateTime iMIP/iTIP Helper Application +* KOrganizer - CVS for 3.1 +* Lotus Notes/Domino - Ver 6.0 +* Novell NIMS + +== Vendor1 Notes + +* If the iCal-attachment is send MIME-encoded, in a form that affects it's plain-text +appearance (in the mail), Vendor1 can't read it properly/at all. This occurred only with +Vendor4-products. +* Vendor1 doesn't send timezone information when dealing with recurring events. +* "`UNTIL`" in `RRULE` isn't set as correct UTC-value +* Vendor1 can't deal with ical-attachments +* Almost all other bugs that occurred are fixed already + +=== Other Problems + +* Vendor2's Client didn't send "Organizer"-information in their ``REPLY``-messages as +requested in RFC 2445 3.2.3 some more I can't remember, and which may be fixed already +* Communication with Vendor3 had no problems. +* Communication with Vendor2 had only the one above mentioned ``REPLY``-problem. +* Communication with Vendor4 is very limited (see MIME-problem). + +=== Personal note + +It's unlucky, that we had some technical problems, that handicapped communication,and stole a lot +of time. So testing was limited to some basics of + +=== Results + +We were not able to test as much as in the previous CalConnect, which was more +productive. We mostly tried creating and replying to events, thus the methods +that were tested were `REQUEST` and `REPLY`. + +[options=header] +.Event With One Occurrence Created By Vendor4 +|=== +| | Vendor4 | Vendor2 | Vendor1 | Vendor3 +| Able To Process `REQUEST` | Yes | Yes | Yes | Yes +| Able To Send `REPLY` to `REQUEST` | Yes | Yes | Yes | Yes +| Able To Process `REPLY` | Yes | Yes | Yes | Yes +|=== + +[options=header] +.Event With One Occurrence Created By Other Vendor +|=== +| | Vendor4 | Vendor2 | Vendor1 | Vendor3 +| Vendor4 Able To Process `REQUEST` | Yes | Yes | Yes | Yes +| Vendor4 Able To Send `REPLY` to `REQUEST` | Yes | Yes | Yes | Yes +| Vendor Able To Process `REPLY` | Yes | Yes | Yes | Yes +|=== + +[options=header] +.Event With an `RRULE` Created By Vendor4 +|=== +| | Vendor4 | Vendor2 | Vendor1 | Vendor3 +| Able To Process `REQUEST` | Yes | Yes | No | Yes +| Able To Send `REPLY` to `REQUEST` | Yes | Yes | No | Yes +| Able To Process `REPLY` | Yes | Yes | No | Yes +|=== + +[options=header] +.Event With an `RRULE` Created By Other Vendor +|=== +| | Vendor4 | Vendor2 | Vendor1 | Vendor3 +| Vendor4 Able To Process `REQUEST` | Yes | Yes | No | Yes +| Vendor4 Able To Send `REPLY` to `REQUEST` | Yes | Yes | No | Yes +| Vendor Able To Process `REPLY` | Yes | Yes | No | Yes +|=== + +=== Miscellaneous + +* We had some success with `CANCEL` and updates (`REQUEST`). However, we do not +remember with which vendors. Vendor3 had success processing a `VEVENT` that we sent to it +that had different character set in it. Some vendors were also able to process a `REQUEST` we +sent that had multiple ``RDATE``s. +* Vendor2 had trouble with line folding, multipart/mixed, and they required that attendees have +a common name ("CN"). +* Vendor1 had trouble with quoted-printable, and had a `DTSTART` in UTC for events with +``RRULE``s. According to iCalendar, when a `DTSTART` is used with a recurrence rule, it must +be specified local time. + +== Vendor 3 Notes + +Microsoft and 2 others were scheduled to participate but did not show up. Unfortunately we had +some technical issues testing w/Vendor4 folks and there were some server uptime issues inhouse +that increased the testing lag on our end. + +=== The Good News + +We were successfully able to do non-repeating and repeating meeting testing with all +implementations. We were able to both send and receive invitations to single instance and +repeating meetings just fine. We were also able to send attachments along with each type of +invitation and they were at least received correctly by the other testers (although some did not +know how to deal with multipart MIME data yet for assorted reasons). + +=== Particular notes relating to specific implementations + +==== Vendor4 + +Vendor4 did not send us any tests with attachments so we were not able to fully test that feature +inbound to Notes. + +==== Vendor 1 + +Vendor 1 is not multipart MIME savy given how it is wired into the mail client (via scripting). +As such it has limitations on it that prevented it from dealing with any attachments we sent. This +is not a failure of the test but a restriction of the receiving client. + +==== Vendor2 + +Vendor2 was able to send back multiple responses to both the single and repeating instances; to +Accept, Decline and Tentatively Accept. We were able to properly detect this status change and +render it on our end. + +=== The Not-so-good News + +The testing done was more at an vendor to vendor level than a pure IETF "RFC Conformance" +test (where we test the explicit `MUST`/`SHOULD`/`MAY`/etc. requirements). We need to find a +way to identify all of the IETF requirements and map them to vendor to vendor tests that we +generally do (or provide some matrix of what we must test to satisfy the IETF requirements for +an interop event). + +We did not attempt any `VTODO` (aka Tasks) or `VJOURNAL` interop testing. Per IETF rules, if +we do not get any implementations that support them then we must remove them from the +standard in the future (but no timeframe for this removal is clear). + +=== Particular notes relating to specific implementations + +==== Vendor4 + +Vendor4 attempted to invite a Vendor3 user to a single instance of a repeating set by sending the +correct iCalendar message that uniquely identified the single instance. We misconverted it to be +a single instance meeting that repeated at the original date/time (which was before the actual +instance date/time so that's not so good). + +==== Vendor1 + +Vendor1 had some small issues with adhering to the RFCs. Guenter was very active in either +fixing or explaining them. For example, Vendor1 sends back ALL invitees on a `REFRESH` +request but RFC 2446 expressly states that only the requestors `ATTENDEE` info is allowed. As +a result, we incorrectly identify the "Request for Update" as being from the 1st listed +`ATTENDEE` rather than from the actual requestor. + +==== Vendor2 + +Vendor2 does not have full featured workflow support in yet. They do not support delegation, +counter proposals or anything associated with them. While they do support the basic accept, +decline and tentative acceptances, the other iTIP messages are ignored or not supported so trying +them against an invitation from VENDOR2 results in an undetermined state or loss of workflow +(at least from the non-VENDOR2 POV). +We did not receive any Vendor2 originating workflow, they simply responded to the ones we +sent out. As such, we do not know how well we interoperate with them when they are the +Organizer of an event or repeating event. I was not able to find out if this was because we did +not have enough testing time or if they are unable to originate iCalendar workflow just yet + +== Chair Summary + +Multipart support/formatting seems to be a source of confusion still given the discussions held +during the interop and on the chats. This should `NOT` be a repeat issue but since its come up +again we need to draft some guidelines for the 'proper' multipart bundling of iCalendar above and +beyond the flat ASCII messages. + +By the next event we plan to have a formalized testing matrix and plan that we can all use to do +interop testing. There needs to be some kind of mapping between what the IETF is looking for +relating to standards acceptance and what we implementors are looking for such as feature C&S +workflow level interop. + +I'm working on making an understandable matrix of the `MUST`/`SHOULD`/`MAY`/etc. clauses in +the RFCs and what they mean for testing. Given our pending release schedules I did not have +time to complete this lately. Hopefully I can get it done after some hard earned time off and +before we spin up again. + +Submitted by Pat Egen diff --git a/sources/cc-0401-ioptest-rules/document.adoc b/sources/cc-0401-ioptest-rules/document.adoc new file mode 100644 index 0000000..1ee753c --- /dev/null +++ b/sources/cc-0401-ioptest-rules/document.adoc @@ -0,0 +1,114 @@ += July 2004 CalConnect Interoperability Test Rules and Test Scenarios +:docnumber: 0401 +:copyright-year: 2004 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2004-07-30 +:published-date: 2004-07-30 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Introduction + +The purpose of this testing is to move the iCalendar, iMIP and iTIP proposed standards to the next level, Draft Standard. The following text describes what +must occur. + +[quote,IETF,"rfc2026,section=4.1.2"] +____ +A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which +sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. For the purposes of this section, +"interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used. If patented or otherwise +controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. +Elevation to Draft Standard is a major advance in status, indicating a strong belief that the specification is mature and will be useful. + +The requirement for at least two independent and interoperable implementations applies to all of the options and features of the +specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable +implementations, the specification may advance to the Draft Standard level only if those options or features are removed. + +The Working Group chair is responsible for documenting the specific implementations which qualify the specification for Draft or Internet Standard status +along with documentation about testing of the interoperation of these implementations. The documentation must include information about the support of +each of the individual options and features. This documentation should be submitted to the Area Director with the protocol action request. (see Section 6) + +A Draft Standard must be well-understood and known to be quite stable, both in its semantics and as a basis for developing an +implementation. A Draft Standard may still require additional or more widespread field experience, since it is possible for +implementations based on Draft Standard specifications to demonstrate unforeseen behavior when subjected to large-scale use in production environments. A +Draft Standard is normally considered to be a final specification, and changes are likely to be made only to solve specific problems encountered. In most +circumstances, it is reasonable for vendors to deploy implementations of Draft Standards into a disruption sensitive environment. +____ + +== Conditions and Their Meanings + +=== `MUST` + +This word, or the terms "`REQUIRED`" or "`SHALL`", mean that the definition is an absolute requirement of the specification. + +=== `MUST NOT` + +This phrase, or the phrase "`SHALL NOT`", mean that the definition is an absolute prohibition of the specification. + +=== `SHOULD` + +This word, or the adjective "`RECOMMENDED`", mean that there may exist valid reasons in +particular circumstances to ignore a particular +item, but the full implications must be understood and carefully weighed before +choosing a different course. + +=== `SHOULD NOT` + +This phrase, or the phrase "`NOT RECOMMENDED`" mean that there may exist valid reasons +in particular circumstances when the +particular behavior is acceptable or even useful, but the full implications should be +understood and the case carefully weighed before implementing any +behavior described with this label. + +=== `MAY` + +This word, or the adjective "`OPTIONAL`", mean that an item is truly optional. One +vendor may choose to include the item because a particular +marketplace requires it or because the vendor feels that it enhances the product +while another vendor may omit the same item. An implementation which does +not include a particular option `MUST` be prepared to interoperate with another +implementation which does include the option, though perhaps with reduced +functionality. In the same vein an implementation which does include a particular +option `MUST` be prepared to interoperate with another implementation +which does not include the option (except, of course, for the feature the option +provides.) + +== Number of Conditions per RFC + +[%unnumbered,options=header] +|=== +| Conditions | iCalendar (<>) | iMIP (<>) | iTIP (<>) +| `MUST` | 159 | 195 | 16 +| `REQUIRED` | 17 | 67 | 2 +| `MUST NOT` | 55 | 60 | 0 +| `SHALL` | 14 | 0 | 0 +| `SHALL NOT` | 1 | 0 | 0 +| `SHOULD` | 39 | 36 | 7 +| `SHOULD NOT` | 6 | 2 | 0 +| `MAY` | 79 | 217 | 7 +| `MAY NOT` | 2 | 5 | 0 +|=== + +[bibliography] +== References + +* [[[rfc2445,RFC 2445]]] + +* [[[rfc2446,RFC 2446]]] + +* [[[rfc2447,RFC 2447]]] + +* [[[rfc2026,RFC 2026]]] diff --git a/sources/cc-0402-ioptest-results/document.adoc b/sources/cc-0402-ioptest-results/document.adoc new file mode 100644 index 0000000..e38baad --- /dev/null +++ b/sources/cc-0402-ioptest-results/document.adoc @@ -0,0 +1,351 @@ += July 2004 CalConnect Interoperability Test Results Spreadsheet +:docnumber: 0402 +:copyright-year: 2004 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2004-07-30 +:published-date: 2004-07-30 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Spreadsheet + +[%unnumbered,options=header,headerrows=2,cols=5] +|=== +| RFC 2445 2+| Internet Calendaring and Scheduling Core Object Specification 2+| +| Feature Set | Requirement | Condition | V1 | V2 + +| 2.3 International Considerations | `MUST` | If a non-US-ASCII compatible character set is used, appropriate code-point from that character set `MUST` be chosen instead | Y | Y +| 4.1 Content Lines | `SHOULD NOT` | Lines of text `SHOULD NOT` be longer than 75 octets, excluding the line break | Y | Y +| 4.1 Content Lines | `SHOULD` | Long content lines `SHOULD` be split into a multiple line representations using a line "folding" technique | Y | Y +| 4.1.1 List and Field Separators | `MUST` | Values in a list of values `MUST` be separated by a `COMMA` character (US-ASCII decimal 44). | N | N +| 4.1.1 List and Field Separators | `MUST` | Structured property values `MUST` have their value parts separated by a `SEMICOLON` character (US-ASCII decimal 59) | N | N +| 4.1.1 List and Field Separators | `MUST` | Each property parameter in a list of property parameters `MUST` be separated by a `SEMICOLON` character (US-ASCII decimal 59). | N | N +| 4.1.1 List and Field Separators | `MUST` | Property parameters with values containing a `COLON`, a `SEMICOLON` or a `COMMA` character `MUST` be placed in quoted text | N | N +| 4.1.3 Binary Content | `SHOULD` | Binary content information in an iCalendar object `SHOULD` be referenced using a URI within a property value | Y | N +| 4.1.3 Binary Content | `MUST` | Binary content information placed external to the iCalendar object `MUST` be referenced by a uniform resource identifier (URI) | Y | N +| 4.2 Property Parameters | `MUST` | 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 value | Y | Y +| 4.2 Property Parameters | `MUST NOT` | Property parameter values `MUST NOT` contain the `DOUBLE-QUOTE` (US-ASCII decimal 22) character. | Y | Y? +| 4.2.1 Alternate Text Representation | `MUST` | A property specifying alternate text representation parameter `MUST` also include a value that reflects the default representation of the text value | Y | N +| 4.2.1 Alternate Text Representation | `MUST` | The individual URI parameter values `MUST` each be specified in a quoted-string | Y | N +| 4.2.4 Delegators | `MUST` | The value of the `DELEGATED-FROM` parameter `MUST` be a `MAILTO` URI as defined in <> | Y | N +| 4.2.4 Delegators | `MUST` | The individual calendar address parameter values `MUST` each be specified in a quoted-string. | Y | N +| 4.2.5 Delegatees | `MUST` | The value of the `DELEGATED-TO` parameter `MUST` be a `MAILTO` URI as defined in <>. | Y | N +| 4.2.5 Delegatees | `MUST` | The individual calendar address parameter values `MUST` each be specified in a quoted-string. | Y | N +| 4.2.6 Directory Entry Reference | `MUST` | The individual URI parameter values of `DIR=` `MUST` each be specified in a quoted-string. | ? | N +| 4.2.7 Inline Encoding | `MUST` | If the value type parameter is "`;VALUE=BINARY`", then the inline encoding parameter `MUST` be specified with the value "`;ENCODING=BASE64`" | Y | N +| 4.2.8 Format Type | `MUST` | The parameter value of `FMTTYPE=MUST` be the `TEXT` for either an IANA registered content type or a non-standard content type | Y | N +| 4.2.11 Group or List Membership | `MUST` | The individual calendar address parameter values `MUST` each be specified in a quoted-string. | N? | N +| 4.2.12 Participation Status | `MUST` | The values to `PARTSTAT=MUST` match one of the values allowed for the given calendar component. | Y | Y +| 4.2.18 Sent By | `MUST` | The parameter value of `SENT-BY` `MUST` be a `MAILTO` URI as defined in <>. | Y | N +| 4.2.18 Sent By | `MUST` | The individual calendar address parameter values `MUST` each be specified in a quoted-string. | Y | N +| 4.2.19 Time Zone Identifier | `MUST` | 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 | Y | Y +| 4.2.19 Time Zone Identifier | `MUST` | An individual "`VTIMEZONE`" calendar component `MUST` be specified for each unique "`TZID`" parameter value specified in the iCalendar object | Y | Y +| 4.2.19 Time Zone Identifier | `MUST NOT` | The `TZID` property parameter `MUST NOT` be applied to `DATE-TIME` or `TIME` properties whose time values are specified in UTC. | Y | Y +| 4.2.20 Value Data Types | `MUST` | The property values `MUST` be of a single value type. | Y | Y +| 4.2.20 Value Data Types | `MUST` | 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 | Y | Y +| 4.3.1 Binary | `MUST` | Property values with this value type `MUST` also include the inline encoding parameter sequence of "`;ENCODING=BASE64`". | Y | N +| 4.3.3 Calendar User Address | `MUST` | When used to address an Internet email transport address for a calendar user, the value `MUST` be a `MAILTO` URI, as defined by <> | Y | Y +| 4.3.5 Date-Time | `MUST NOT` | The form of date and time with UTC offset `MUST NOT` be used. | Y | Y +| 4.3.5 Date-Time | `SHOULD` | 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 | Y | Y +| 4.3.5 Date-Time | `SHOULD` | Floating time `SHOULD` only be used where that is the reasonable behavior | Y | Y +| 4.3.5 Date-Time | `MUST` | 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 | Y | Y +| 4.3.5 Date-Time | `MUST NOT` | The `TZID` property parameter `MUST NOT` be applied to `DATE-TIME` properties whose time values are specified in UTC | Y | Y +| 4.3.5 Date-Time | `MUST ONLY` | A time value `MUST ONLY` specify 60 seconds when specifying the periodic "leap second" in the time value | ? | Y +| 4.3.9 Period of Time | `MUST` | The start of the period `MUST` be before the end of the period. | ? | ? +| 4.3.10 Recurrence Rule | `MUST` | Individual rule parts `MUST` only be specified once | Y | Y +| 4.3.10 Recurrence Rule | `MUST` | The `FREQ` rule part identifies the type of recurrence rule. This rule part `MUST` be specified in the recurrence rule | Y | Y +| 4.3.10 Recurrence Rule | `MUST` | If `UNTIL` is specified as a date-time value, then it `MUST` be specified in an UTC time format. | Y | Y +| 4.3.10 Recurrence Rule | `MUST` | `BYSETPOS` `MUST` only be used in conjunction with another `BYxxx` rule part | Y | Y? +| 4.3.11 Text | `MUST` | 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" | Y | Y +| 4.3.12 Time | `MUST NOT` | The form of time with UTC offset `MUST NOT` be used. | Y | Y +| 4.3.12 Time | `SHOULD` | 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 | Y | Y +| 4.3.12 Time | `SHOULD` | Floating time `SHOULD` only be used where that is reasonable behavior | Y | Y +| 4.3.12 Time | `MUST` | To properly communicate a fixed time in a property value, either UTC time or local time with time zone reference `MUST` be specified. | Y | Y +| 4.3.12 Time | `MUST NOT` | The `TZID` property parameter `MUST NOT` be applied to `TIME` properties whose time values are specified in UTC | Y | Y +| 4.3.14 UTC Offset | `MUST` | The `PLUS SIGN` character `MUST` be specified for positive UTC offsets (i.e., ahead of UTC). | Y | Y +| 4.4 iCalendar Object | `MUST` | The first line and last line of the iCalendar object `MUST` contain a pair of iCalendar object delimiter strings | Y | Y +| 4.6 Calendar Components | `MUST` | An iCalendar object `MUST` include the "`PRODID`" and "`VERSION`" calendar properties. | Y | Y +| 4.6 Calendar Components | `MUST NOT` | '`calscale`' and '`method`' are optional, but `MUST NOT` occur more than once | Y | Y +| 4.6 Calendar Components | `MUST` | An iCalendar object `MUST` include at least one calendar component. | Y | Y? +| 4.6.1 Event Component | `MUST NOT` | the following are optional, but `MUST NOT` occur more than once: `class` / `created` / `description` / `dtstart` / `geo` / `last-mod` / `location` / `organizer` / `priority` / `dtstamp` / `seq` / `status` / `summary` / `transp` / `uid` / `url` / `recurid` | Y | Y +| 4.6.1 Event Component | `MUST NOT` | either '`dtend`' or '`duration`' may appear in a '`eventprop`', but '`dtend`' and '`duration`' `MUST NOT` occur in the same '`eventprop`' | Y | Y +| 4.6.1 Event Component | `MAY` | the following are optional, and `MAY` occur more than once: `attach` / `attendee` / `categories` / `comment` / `contact` / `exdate` / `exrule` / `rstatus` / `related` / `resources` / `rdate` / `rrule` / `x-pro` | Y | Y +| 4.6.2 To-do Component | `MUST NOT` | 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` / `ur` | Y | Y +| 4.6.2 To-do Component | `MUST NOT` | either 'due' or 'duration' may appear in a 'todoprop', but 'due' and 'duration' `MUST NOT` occur in the same 'todoprop' | Y | Y +| 4.6.2 To-do Component | `MAY` | the following are optional, and `MAY` occur more than once: `attach` / `attendee` / `categories` / `comment` / `contact` / `exdate` / `exrule` / `rstatus` / `related` / `resources` / `rdate` / `rrule` / `x-pro` | Y | Y +| 4.6.3 Journal Component | `MUST NOT` | 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` | N | N +| 4.6.3 Journal Component | `MAY` | the following are optional, and `MAY` occur more than once: `attach` / `attendee` / `categories` / `comment` / `contact` / `exdate` / `exrule` / `related` / `rdate` / `rrule` / `rstatus` / `x-pro` | N | N +| 4.6.3 Journal Component | `MUST NOT` | The "`VJOURNAL`" calendar component cannot be nested within another calendar component | N | N +| 4.6.4 Free/Busy Component | `MUST NOT` | the following are optional, but `MUST NOT` occur more than once: `contact` / `dtstart` / `dtend` / `duration` / `dtstamp` / `organizer` / `uid` / `url` | N | Y +| 4.6.4 Free/Busy Component | `MAY` | the following are optional, and `MAY` occur more than once: `attendee` / `comment` / `freebusy` / `rstatus` / `x-prop` | N | Y +| 4.6.4 Free/Busy Component | `MUST NOT` | 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 | N | Y +| 4.6.5 Time Zone Component | `MUST NOT` | 'tzid' is required, but `MUST NOT` occur more than once | Y | Y +| 4.6.5 Time Zone Component | `MUST NOT` | 'last-mod' and 'tzurl' are optional, but `MUST NOT` occur more than once | Y | Y +| 4.6.5 Time Zone Component | `MUST` | one of 'standardc' or 'daylightc' `MUST` occur and each `MAY` occur more than once | Y | Y +| 4.6.5 Time Zone Component | `MAY` | the following is optional, and `MAY` occur more than once: x-prop | Y | Y +| 4.6.5 Time Zone Component | `MAY` | Multiple "`VTIMEZONE`" calendar components can exist in an iCalendar object. | Y | Y +| 4.6.5 Time Zone Component | `MUST` | If multiple "`VTIMEZONE`" calendar components exist in an iCalendar object, each "`VTIMEZONE`" `MUST` represent a unique time zone definition | Y | Y +| 4.6.5 Time Zone Component | `MUST` | 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 | Y | Y +| 4.6.5 Time Zone Component | `MAY` | A "`VTIMEZONE`" calendar component can be present if the iCalendar object does not contain such an `RRULE` that generates dates on both sides of a time zone shift. | Y | Y +| 4.6.5 Time Zone Component | `MUST` | If a `RRULE` that generates dates on both sides of a time zone shift is present, there `MUST` be valid time zone information for all recurrence instances | Y | Y +| 4.6.5 Time Zone Component | `MUST` | The "`VTIMEZONE`" calendar component `MUST` include the "`TZID`" property and at least one definition of a standard or daylight component. | Y | Y +| 4.6.5 Time Zone Component | `MUST` | The standard or daylight component `MUST` include the "`DTSTART`", "`TZOFFSETFROM`" and "`TZOFFSETTO`" properties. | Y | Y +| 4.6.5 Time Zone Component | `MUST` | An individual "`VTIMEZONE`" calendar component `MUST` be specified for each unique "`TZID`" parameter value specified in the iCalendar object. | Y | Y +| 4.6.5 Time Zone Component | `SHOULD` | `TZURL` `SHOULD` refer to a resource that is accessible by anyone who might need to interpret the object. | N | N +| 4.6.5 Time Zone Component | `SHOULD NOT` | `TZURL` `SHOULD NOT` normally be a file: URL or other URL that is not widely-accessible. | N | N +| 4.6.6 Alarm Component | `REQUIRED` | 'action' and 'trigger' are both `REQUIRED`, but `MUST NOT` occur more than once | N | N +| 4.6.6 Alarm Component | `MUST NOT` | 'duration' and 'repeat' are both optional, and `MUST NOT` occur more than once each, but if one occurs, so `MUST` the other | N | N +| 4.6.6 Alarm Component | `MUST` NOT| the following is optional, but `MUST NOT` occur more than once: attach | N | N +| 4.6.6 Alarm Component | `MAY` | the following is optional, and `MAY` occur more than once: x-prop | N | N +| 4.6.6 Alarm Component | `REQUIRED` | the following are all `REQUIRED`, but `MUST NOT` occur more than once: `action` / `description` / `trigger` | N | N +| 4.6.6 Alarm Component | `MUST NOT` | 'duration' and 'repeat' are both optional, and `MUST NOT` occur more than once each, but if one occurs, so `MUST` the other | N | N +| 4.6.6 Alarm Component | `MAY` | the following is optional, and `MAY` occur more than once: x-prop | N | N +| 4.6.6 Alarm Component | `REQUIRED` | the following are all `REQUIRED`, but `MUST NOT` occur more than once: `action` / `description` / `trigger` / `summary` | N | N +| 4.6.6 Alarm Component | `REQUIRED` | the following is `REQUIRED`, and `MAY` occur more than once: attendee | N | N +| 4.6.6 Alarm Component | `MUST NOT` | 'duration' and 'repeat' are both optional, and `MUST NOT` occur more than once each, but if one occurs, so `MUST` the other | N | N +| 4.6.6 Alarm Component | `MAY` | the following are optional, and `MAY` occur more than once: `attach` / `x-prop` | N | N +| 4.6.6 Alarm Component | `REQUIRED` | the following are all `REQUIRED`, but `MUST NOT` occur more than once: `action` / `attach` / `trigger` | N | N +| 4.6.6 Alarm Component | `MUST NOT` | 'duration' and 'repeat' are both optional, and `MUST NOT` occur more than once each, but if one occurs, so `MUST` the other | N | N +| 4.6.6 Alarm Component | `MUST NOT` | 'description' is optional, and `MUST NOT` occur more than once | N | N +| 4.6.6 Alarm Component | `MAY` | the following is optional, and `MAY` occur more than once: x-prop | N | N +| 4.6.6 Alarm Component | `MUST` | The "`VALARM`" calendar component `MUST` include the "`ACTION`" and "`TRIGGER`" properties. | N | N +| 4.6.6 Alarm Component | `MUST` | 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. | N | N +| 4.6.6 Alarm Component | `MUST` | 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. | N | N +| 4.6.6 Alarm Component | `MUST` | 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. | N | N +| 4.6.6 Alarm Component | `MAY` | It can also include one or more "`ATTACH`" properties, which are intended to be sent as message attachments. | N | N +| 4.6.6 Alarm Component | `MUST` | 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. | N | N +| 4.6.6 Alarm Component | `MUST` | The "`VALARM`" calendar component `MUST` only appear within either a "`VEVENT`" or "`VTODO`" calendar component. | N | N +| 4.6.6 Alarm Component | `MUST NOT` | "`VALARM`" calendar components cannot be nested. | N | N +| 4.6.6 Alarm Component | `MUST` | 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. | N | Y +| 4.6.6 Alarm Component | `MUST` | 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. | N | +| 4.6.6 Alarm Component | `MUST` | 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. | N | Y +| 4.6.6 Alarm Component | `MUST` | A definition of an alarm with a repeating trigger `MUST` include both the "`DURATION`" and "`REPEAT`" properties. | N | +| 4.6.6 Alarm Component | `MUST` | Both "`DURATION`" and "REPEAT" 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. | N | Y +| 4.6.6 Alarm Component | `MUST` | The "`ACTION`" property `MUST` specify one and only one of "`AUDIO`", "`DISPLAY`", "`PROCEDURE`", "`EMAIL`". | N | Y +| 4.6.6 Alarm Component | `MUST` | In an `AUDIO` alarm, if the optional "`ATTACH`" property is included, it `MUST` specify an audio sound resource. | N | Y +| 4.6.6 Alarm Component | `MUST` | For an "`EMAIL`" alarm, 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. | N | Y +| 4.6.6 Alarm Component | `SHOULD` | Any "`ATTACH`" properties in the "`VALARM`" calendar component `SHOULD` be sent as attachments to the message. | N | Y +| 4.6.6 Alarm Component | `MUST` | 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. | N | Y +| 4.6.6 Alarm Component | `SHOULD` | While a very useful alarm capability, the `PROCEDURE` type of alarm `SHOULD` be treated by the "Calendar User Agent" as a potential security risk. | N | Y +| 4.7 Calendar Properties | `SHOULD` | Calendar Properties `SHOULD` be specified after the "`BEGIN:VCALENDAR`" property and prior to any calendar component. | Y | Y +| 4.7.2 Method | `MUST` | 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. | Y | Y +| 4.7.2 Method | `MUST` | If either the "`METHOD`" property or the Content-Type "method" parameter is specified, then the other `MUST` also be specified. | Y | Y +| 4.7.2 Method | `MUST NOT` | If this property is not present in the iCalendar object, then a scheduling transaction `MUST NOT` be assumed. | Y | Y +| 4.7.3 Product Identifier | `MUST` | The property `MUST` be specified once in an iCalendar object. | Y | Y +| 4.7.3 Product Identifier | `SHOULD` | 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 <>. | Y | Y +| 4.7.3 Product Identifier | `SHOULD NOT` | This property `SHOULD` not be used to alter the interpretation of an iCalendar object beyond the semantics specified in this memo. | Y | Y +| 4.7.4 Version | `MUST` | This property `MUST` be specified by an iCalendar object, but `MUST` only be specified once. | Y | Y +| 4.8.1.1 Attachment | `MUST` | the following is optional, but `MUST NOT` occur more than once: fmttypeparam | Y | N +| 4.8.1.1 Attachment | `MAY` | the following is optional, and `MAY` occur more than once: xparam | Y | N +| 4.8.1.2 Categories | `MUST NOT` | the following is optional, but `MUST NOT` occur more than once: languageparam | N | Y +| 4.8.1.2 Categories | `MAY` | the following is optional, and `MAY` occur more than once: xparam | N | Y +| 4.8.1.4 Comment | `MUST NOT` | the following are optional, but `MUST NOT` occur more than once: altrepparam, languageparam | Y | Y +| 4.8.1.4 Comment | `MAY` | the following is optional, and `MAY` occur more than once: xparam | Y | Y +| 4.8.1.5 Description | `MUST NOT` | the following are optional, but `MUST NOT` occur more than once: altrepparam, languageparam | Y | Y +| 4.8.1.5 Description | `MAY` | the following is optional, and `MAY` occur more than once: xparam | Y | Y +| 4.8.1.6 Geographic Position | `MUST` | The value `MUST` be two `SEMICOLON` separated `FLOAT` values. | Y | Y +| 4.8.1.7 Location | `MUST` | the following are optional, but `MUST NOT` occur more than once: altrepparam, languageparam | Y | Y +| 4.8.1.7 Location | `MAY` | the following is optional, and `MAY` occur more than once: xparam | Y | Y +| 4.8.1.10 Resources | `MUST NOT` | the following are optional, but `MUST NOT` occur more than once: altrepparam, languageparam | Y | Y +| 4.8.1.10 Resources | `MAY` | the following is optional, and `MAY` occur more than once: xparam | Y | Y +| 4.8.1.12 Summary | `MUST NOT` | the following are optional, but `MUST NOT` occur more than once: altrepparam, languageparam | Y | Y +| 4.8.1.12 Summary | `MAY` | the following is optional, and `MAY` occur more than once: xparam | Y | Y +| 4.8.2.1 Date/Time Completed | `MUST` | The date and time `MUST` be in a UTC format. | Y | Y +| 4.8.2.2 Date/Time End | `MUST NOT` | the following are optional, but `MUST NOT` occur more than once: "`VALUE`" "=" ("`DATETIME`" / "`DATE`")), tzidparam | Y | Y +| 4.8.2.2 Date/Time End | `MAY` | the following is optional, and `MAY` occur more than once: xparam | Y | Y +| 4.8.2.3 Date/Time Due | `MUST NOT` | the following are optional, but `MUST NOT` occur more than once: "`VALUE`" "=" ("`DATETIME`" / "`DATE`")), tzidparam | Y | N +| 4.8.2.3 Date/Time Due | `MAY` | the following is optional, and `MAY` occur more than once: xparam | Y | N +| 4.8.2.4 Date/Time Start | `MUST` | The time value `MUST` be one of the forms defined for the `DATE-TIME` value type. | Y | Y +| 4.8.2.4 Date/Time Start | `MUST NOT` | the following are optional, but `MUST NOT` occur more than once: "VALUE" "=" ("DATETIME" / "DATE")), tzidparam | Y | Y +| 4.8.2.4 Date/Time Start | `MAY` | the following is optional, and `MAY` occur more than once: xparam | Y | Y +| 4.8.2.6 Free/Busy Time | `MUST` | The date and time values `MUST` be in an UTC time format. | N | Y? +| 4.8.2.6 Free/Busy Time | `MUST` | the following is optional, but `MUST NOT` occur more than once: fbtypeparam | N | Y +| 4.8.2.6 Free/Busy Time | `MAY` | the following is optional, and `MAY` occur more than once: xparam | N | Y +| 4.8.2.7 Time Transparency | `SHOULD` | Events 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. | Y | Y +| 4.8.2.7 Time Transparency | `SHOULD` | 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. | Y | Y +| 4.8.3.1 Time Zone Identifier | `MUST` | This property `MUST` be specified in a "`VTIMEZONE`" calendar component. | Y | Y +| 4.8.3.2 Time Zone Name | `MUST NOT` | the following is optional, but `MUST NOT` occur more than once: languageparam | Y | Y +| 4.8.3.2 Time Zone Name | `MAY` | the following is optional, and `MAY` occur more than once: xparam | Y | Y +| 4.8.3.3 Time Zone Offset From | `MUST` | This property `MUST` be specified in a "`VTIMEZONE`" calendar component. | Y | Y +| 4.8.3.4 Time Zone Offset To | `MUST` | This property `MUST` be specified in a "`VTIMEZONE`" calendar component. | Y | Y +| 4.8.4.1 Attendee | `MUST` | This property `MUST` be specified in an iCalendar object that specifies a group scheduled calendar entity. | Y | Y +| 4.8.4.1 Attendee | `MUST NOT` | This property `MUST NOT` be specified in an iCalendar object when publishing the calendar information. | Y | N +| 4.8.4.1 Attendee | `MUST` | The property `MUST` only be specified within calendar components to specify participants, non-participants and the chair of a group scheduled calendar entity. | Y | Y +| 4.8.4.1 Attendee | `MUST NOT` | The `ROLE`, `PARSTAT`, `RSVP`, `CUTYPE`, etc. `MUST NOT` be specified in an "`ATTENDEE`" property in a "`VFREEBUSY`" or "`VALARM`" calendar component. | Y | Y +| 4.8.4.1 Attendee | `MUST` | A recipient delegated a request `MUST` inherit the `RSVP` and `ROLE` values from the attendee that delegated the request to them. | Y | N +| 4.8.4.1 Attendee | `MUST NOT` | the following are optional, but `MUST NOT` occur more than once: cutypeparam, memberparam, roleparam, partstatparam, rsvpparam, deltoparam, delfromparam, sentbyparam, cnparam, dirparam, languageparam | Y | Y +| 4.8.4.1 Attendee | `MAY` | the following is optional, and `MAY` occur more than once: xparam | Y | Y +| 4.8.4.2 Contact | `MUST` | the following are optional, but `MUST NOT` occur more than once: altrepparam, languageparam | Y | Y +| 4.8.4.2 Contact | `MAY` | the following is optional, and `MAY` occur more than once: xparam | Y | Y +| 4.8.4.3 Organizer | `MUST` | This property `MUST` be specified in an iCalendar object that specifies a group scheduled calendar entity. | Y | Y +| 4.8.4.3 Organizer | `MUST` | This property `MUST` be specified in an iCalendar object that specifies the publication of a calendar user's busy time. | N | Y +| 4.8.4.3 Organizer | `MUST NOT` | 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. | N | N +| 4.8.4.3 Organizer | `MUST NOT` | the following are optional, but `MUST NOT` occur more than once: cnparam, dirparam, sentbyparam, languageparam | Y | Y +| 4.8.4.3 Organizer | `MAY` | the following is optional, and `MAY` occur more than once: xparam | Y | Y +| 4.8.4.4 Recurrence ID | `MUST` | If the value of the "`DTSTART`" property is a `DATE` type value, then the value `MUST` be the calendar date for the recurrence instance. | Y | Y +| 4.8.4.4 Recurrence ID | `MUST NOT` | the following are optional, but `MUST NOT` occur more than once: "`VALUE`" "=" ("`DATETIME`" / "`DATE`"), tzidparam, rangeparam | Y | Y +| 4.8.4.4 Recurrence ID | `MAY` | the following is optional, and `MAY` occur more than once: xparam | Y | Y +| 4.8.4.5 Related To | `MUST NOT` | the following is optional, but `MUST NOT` occur more than once: reltypeparam | N | N +| 4.8.4.5 Related To | `MAY` | the following is optional, and `MAY` occur more than once: xparam | N | N +| 4.8.4.7 Unique Identifier | `MUST` | The property `MUST` be specified in the "`VEVENT`", "`VTODO`", "`VJOURNAL`" or "`VFREEBUSY`" calendar components. | Y | Y +| 4.8.4.7 Unique Identifier | `MUST` | The UID itself `MUST` be a globally unique identifier. | Y | Y +| 4.8.4.7 Unique Identifier | `MUST` | The generator of the identifier `MUST` guarantee that the identifier is unique. | Y | Y +| 4.8.4.7 Unique Identifier | `MUST` | Implementations `MUST` be able to receive and persist values of at least 255 characters for this property. | Y | Y +| 4.8.5.1 Exception Date/Times | `MUST` | 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`". | Y | Y +| 4.8.5.1 Exception Date/Times | `MUST NOT` | the following are optional, but `MUST NOT` occur more than once: "`VALUE`" "=" ("`DATETIME`" / "`DATE`"), tzidparam | Y | Y +| 4.8.5.1 Exception Date/Times | `MAY` | the following is optional, and `MAY` occur more than once: xparam | Y | Y +| 4.8.5.3 Recurrence Date/Times | `MUST NOT` | the following are optional, but `MUST NOT` occur more than once: "`VALUE`" "=" ("`DATETIME`" / "`DATE`" / "`PERIOD`"), tzidparam | Y | Y +| 4.8.5.3 Recurrence Date/Times | `MAY` | the following is optional, and `MAY` occur more than once: xparam | Y | Y +| 4.8.5.4 Recurrence Rule | `MUST` | 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. | Y | Y +| 4.8.6.1 Action | `MUST` | This property `MUST` be specified once in a "VALARM" calendar component. | Y | Y +| 4.8.6.3 Trigger | `MUST` | 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. | N | +| 4.8.6.3 Trigger | `MUST` | The trigger relationship property parameter `MUST` only be specified when the value type is `DURATION`. | N | Y +| 4.8.6.3 Trigger | `MUST` | This property `MUST` be specified in the "`VALARM`" calendar component. | N | Y +| 4.8.6.3 Trigger | `MUST` | If a value type of `DATE-TIME` is specified, then the property value `MUST` be specified in the UTC time format. | N | N +| 4.8.6.3 Trigger | `MUST` | If the trigger is set relative to `START`, then the "`DTSTART`" property `MUST` be present in the associated "`VEVENT`" or "`VTODO`" calendar component. | N | Y +| 4.8.6.3 Trigger | `MUST` | 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. | N | N +| 4.8.6.3 Trigger | `MUST` | 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. | N | Y +| 4.8.6.3 Trigger | `MUST NOT` | the following are optional, but `MUST NOT` occur more than once: "`VALUE`" "=" "`DURATION`", trigrelparam | N | Y +| 4.8.6.3 Trigger | `MAY` | the following is optional, and `MAY` occur more than once: xparam | N | Y +| 4.8.6.3 Trigger | `REQUIRED` | the following is `REQUIRED`, but `MUST NOT` occur more than once: "`VALUE`" "=" "`DATETIME`" | N | ? +| 4.8.7.2 Date/Time Stamp | `MUST` | This property `MUST` be included in the "`VEVENT`", "`VTODO`", "`VJOURNAL`" or "`VFREEBUSY`" calendar components. | Y | Y +| 4.8.7.2 Date/Time Stamp | `MUST` | The value `MUST` be specified in the UTC time format. | Y | Y +| 4.8.7.4 Sequence Number | `MUST` | 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`" | Y | Y +| 4.8.7.4 Sequence Number | `MUST` | 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". | ? | ? +| 4.8.8.2 Request Status | `MUST NOT` | the following is optional, but `MUST NOT` occur more than once: languageparm | Y | Y +| 4.8.8.2 Request Status | `MAY` | the following is optional, and `MAY` occur more than once: xparam | Y | Y +| 6 Recommended Practices | `MUST NOT` | 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. | Y | Y +| 6 Recommended Practices | `SHOULD` | 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. | Y | Y +|=== + +[%unnumbered,options=header,headerrows=2,cols=5] +|=== +| RFC 2446 2+| iCalendar Transport-Independent Interoperability Protocol 2+| +| Feature Set | Requirement | Condition | V1 | V2 + +| 3.1 Common Component Restrictions | `MUST` | `CALSCALE` 0 or 1 | N | N +| 3.1 Common Component Restrictions | `MUST` | `PRODID` `MUST` appear | Y | Y +| 3.1 Common Component Restrictions | `MUST` | `VERSION` `MUST` be 2.0 | Y | Y +| 3.1 Common Component Restrictions | `MUST` | `VTIMEZONE` `MUST` contain specified required values | Y | Y +| 3.1 Common Component Restrictions | `MUST` | `VALARM` `MUST` contain specified required values | Y | N +| 3.2.1 `VEVENT PUBLISH` | `MUST` | `MUST` contain specified required values | N | Y +| 3.2.1 `VEVENT PUBLISH` | `MUST` | `MUST` contain "Organizer" | N | Y +| 3.2.1 `VEVENT PUBLISH` | `MUST NOT` | `MUST NOT` contain "Attendees" | N | Y +| 3.2.2 `VEVENT REQUEST` | `MUST` | `MUST` contain specified required values | Y | Y +| 3.2.2.1 Rescheduling an Event | `MUST` | `MUST` contain existing "`UID`" but incremented "`SEQUENCE`" or higher "`DTSTAMP`" | Y | Y +| 3.2.2.2 Updating or Reconfirmation of an Event | `MUST` | `MUST` contain existing "`UID`" and current "`SEQUENCE`" | Y | Y +| 3.2.2.3 Delegating an Event to another CU | `MUST` | "Delegator" `MUST` forward `VEVENT REQUEST` to "Delegate" showing the "Delegate" as an "Atendee" | Y | N +| 3.2.2.3 Delegating an Event to another CU | `MUST` | "Delegator" `MUST` send `VEVENT REPLY` to "Organizer" showing "Deletator's" "Atendee" parstat as "delegated" plus "delegated-to" value | Y | N +| 3.2.2.3 Delegating an Event to another CU | `MUST` | "Delegate" `MUST` send `VEVENT REPLY` to "Organizer" showing "delegated-from" value | Y | N +| 3.2.2.6 Forwarding to An Uninvited CU | `MAY` | 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. | N | N +| 3.2.2.6 Forwarding to An Uninvited CU | `MUST NOT` | When forwarding a "`REQUEST`" to another CU, the forwarding "Attendee" `MUST NOT` make changes to the `VEVENT` property set. | N | N +| 3.2.3 `VEVENT REPLY` | `MUST NOT` | The optional properties of the original `VEVENT REQUEST` `MUST NOT` be changed from those of the original request. If property changes are desired the `COUNTER` message must be used. | Y | Y? +| 3.2.4 `VEVENT ADD` | `MUST` | The "`UID`" `MUST` be that of an existing `VEVENT`. | Y | Y +| 3.2.4 `VEVENT ADD` | `SHOULD` | 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`". | Y | Y? +| 3.2.4 `VEVENT ADD` | `SHOULD` | 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`". | Y | Y +| 3.2.4 `VEVENT CANCEL` | `MUST` | 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. | N | Y +| 3.2.4 `VEVENT CANCEL` | `MUST` | 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. | Y | Y +| 3.2.4 `VEVENT CANCEL` | `MUST` | Canceling multiple `VEVENT` instances `MUST` be done with either "`RECURRENCE-ID`" and "`RANGE`" `OR` multiple "`RECURRENCE-ID`" values. | Y | Y +| 3.2.4 `VEVENT CANCEL` | `MUST` | When a "`VEVENT`" is cancelled, the "`SEQUENCE`" property value `MUST` be incremented. | N? | Y +| 3.3 Methods For `VFREEBUSY` Components | `MUST` | This document only addresses the transfer of busy time information. Applications desiring free time information `MUST` infer this from available busy time information. | N | Y +| 3.3 Methods For `VFREEBUSY` Components | `MAY` | The busy time information within the iCalendar object `MAY` be grouped into more than one "`VFREEBUSY`" calendar component. | N | N +| 3.3 Methods For `VFREEBUSY` Components | `MAY` | The "`FREEBUSY`" property value `MAY` include a list of values, separated by the `COMMA` character ([US-ASCII] decimal 44). | N | N +| 3.3 Methods For `VFREEBUSY` Components | `MAY` | Alternately, multiple busy time periods `MAY` be specified with multiple instances of the "FREEBUSY" property. | N | N +| 3.3 Methods For `VFREEBUSY` Components | `MUST` | Both forms `MUST` be supported by implementations conforming to this document. | N | N +| 3.3 Methods For `VFREEBUSY` Components | `SHOULD NOT` | Duplicate busy time periods `SHOULD NOT` be specified in an iCalendar object | N | Y +| 3.3 Methods For `VFREEBUSY` Components | `MAY` | However, two different busy time periods `MAY` overlap. | N | Y +| 3.3 Methods For `VFREEBUSY` Components | `SHOULD` | "`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. | N | Y +| 3.3.1 `VFREEBUSY PUBLISH` | `MUST` | 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. | N | Y +| 3.3.2 `VFREEBUSY `REQUEST` | `SHOULD` | 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. | N | N +| 3.3.3 `VFREEBUSY REPLY` | `MAY` | 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. | N | N +| 3.4.1 `VTODO PUBLISH` | `MUST` | `VTODO PUBLISH` `MUST` have an "Organizer" | ? | N +| 3.4.1 `VTODO PUBLISH` | `MUST NOT` | `VTODO PUBLISH` `MUST NOT` have "Attendees" | ? | N +| 3.4.1 `VTODO PUBLISH` | `MAY` | 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 "`VTODO`" calendar component. | ? | N +| 3.4.2 `VTODO REQUEST` | `MAY` | `VTODO REQUEST` `MAY` be a new request or a rescheduling of a `VTODO` depending on the values of the "`UID`", "`SEQUENCE`", and "`DTSTAMP`" properties. | Y | N +| 3.4.2.3 `REQUEST` for Delegating a `VTODO` | `MUST NOT` | An "Attendee" of a "`VTODO`" calendar component `MUST NOT` delegate to the "Organizer" of the event. | Y | N +| 3.4.2.3 `REQUEST` for Delegating a `VTODO` | `MUST` | The "Delegator" of a "`VTODO`" calendar component `MUST` forward the existing "`REQUEST`" method for a "`VTODO`" calendar component to the "Delegate". | Y | N +| 3.4.2.3 `REQUEST` for Delegating a `VTODO` | `MUST` | The "`VTODO`" calendar component description `MUST` include the "Delegator's" up-to-date "`VTODO`" calendar component definition. | Y | N +| 3.4.2.3 `REQUEST` for Delegating a `VTODO` | `MUST` | The "`REQUEST`" method `MUST` also include an "`ATTENDEE`" property with the calendar address of the "Delegate". | Y | N +| 3.4.2.3 `REQUEST` for Delegating a `VTODO` | `MUST` | The "Delegator" `MUST` also send a "`REPLY`" method back to the "Organizer" with the "Delegator's" "Attendee" property "partstat" parameter value set to "`DELEGATED`". | Y | N +| 3.4.2.3 `REQUEST` for Delegating a `VTODO` | `MUST` | The "delegated-to" parameter `MUST` be included with the calendar address of the "Delegate". | Y | N +| 3.4.2.3 `REQUEST` for Delegating a `VTODO` | `SHOULD` | 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. | Y | N +| 3.4.2.3 `REQUEST` for Delegating a `VTODO` | `MUST` | 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`". | Y | N +| 3.4.2.4 `REQUEST` Forwarded To An Uninvited Calendar User | `MAY` | 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. | N | N +| 3.4.2.4 `REQUEST` Forwarded To An Uninvited Calendar User | `MAY` | The new CU can send a "`REPLY`" to the "Organizer" of the "`VTODO`" calendar component. | N | N +| 3.4.2.4 `REQUEST` Forwarded To An Uninvited Calendar User | `MAY` | The "Organizer" `MAY` send the CU a "`CANCEL`" message to indicate that they will not be added to the to-do. | N | N +| 3.4.3 `VTODO REPLY` | `MUST` | 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. | Y | N +| 3.4.3 `VTODO REPLY` | `MUST` | The "Delegate" `MUST` include the calendar address of the "Delegator" on the "delegated-from" parameter of the "Delegate's" "`ATTENDEE`" property. | Y | N +| 3.4.3 `VTODO REPLY` | `MAY` | The "`REPLY`" method `MAY` also be used to respond to an unsuccessful "`VTODO`" calendar component "`REQUEST`" method. | Y | N +| 3.4.3 `VTODO REPLY` | `MAY` | The "Organizer" of a "`VTODO`" calendar component `MAY` receive a "`REPLY`" method from a "Calendar User" not in the original "`REQUEST`". 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. | Y | N +| 3.4.4 `VTODO ADD` | `SHOULD` | 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". | Y | N +| 3.4.5 `VTODO CANCEL` | `MUST` | 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. | Y | N +| 3.4.5 `VTODO CANCEL` | `MUST` | 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. | Y | N +| 3.4.5 `VTODO CANCEL` | `MUST` | When a "`VTODO`" is cancelled, the "`SEQUENCE`" property value `MUST` be incremented. | N | N +| 3.4.6 `VTODO REFRESH` | `MAY` | The "Organizer" of the "`VTODO`" calendar component `MAY` use this method to request an updated status from the "Attendees". | N | N +| 3.4.6 `VTODO REFRESH` | `MUST` | The "REFRESH" method `MUST` specify the "`UID`" property corresponding to the "`VTODO`" calendar component needing update. | N | N +| 3.4.6 `VTODO REFRESH` | `MUST` | 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. | N | N +| 3.4.7 `VTODO COUNTER` | `SHOULD` | 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". | Y | N +| 3.5.1 `VJOURNAL PUBLISH` | `MUST` | `VJOURNAL PUBLISH` `MUST` have an "Organizer". | N | N +| 3.5.1 `VJOURNAL PUBLISH` | `MUST NOT` | `VJOURNAL PUBLISH` `MUST NOT` have "Attendees". | N | N +| 3.5.1 `VJOURNAL PUBLISH` | `MAY` | The "Organizer" `MAY` subsequently update (with another "`PUBLISH`" method) or cancel (with a "`CANCEL`" method) a previously published journal entry. | N | N +| 3.5.2 `VJOURNAL ADD` | `MAY` | 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`". | N | N +| 3.5.3 `VJOURNAL CANCEL` | `MUST` | 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. | N | N +| 3.5.3 `VJOURNAL CANCEL` | `MUST` | 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. | N | N +| 3.5.3 `VJOURNAL CANCEL` | `MUST` | When a "`VJOURNAL`" is cancelled, the "`SEQUENCE`" property value `MUST` be incremented. | N | N +| 3.6 Status Replies | `MAY` | Various optional responses `MAY` be added to the various Status Replies to explain the particular Status value | Y | Y +| 3.7.2 Attendee Property Considerations | `MUST` | 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 authorizing an update. Second, it is prudent to provide a point of contact for anyone who receives a published component in case of problems. | Y | Y +| 3.7.2 Attendee Property Considerations | `MAY` | There are valid > 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. | Y | Y +| 3.7.2 Attendee Property Considerations | `MUST` a| 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 | N | N +| 5 Application Protocol Fallbacks | `SHOULD` | 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. | Y | Y +|=== + +[%unnumbered,options=header,headerrows=2] +|=== +| RFC 2447 2+| iCalendar Message-Based Interoperability Protocol 2+| +| Feature Set | Requirement | Condition | V1 | V2 +| 2.2.1 Authorization | `SHOULD` | 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. | Y | Y +| 2.3 <> Addresses | `MUST` | The calendar address specified within the "`ATTENDEE`" property in an iCalendar object `MUST` be a fully qualified, <> address specification for the corresponding "Organizer" or "Attendee" of the "`VEVENT`" or "`VTODO`". | Y | Y +| 2.3 <> Addresses | `MUST` | The addresses of "Organizers" or "Attendees" `MUST` be ascertained by opening the "text/calendar" MIME body part and examining the "`ATTENDEE`" and "`ORGANIZER`" properties. | Y | N +| 2.4 Content Type | `MUST` | A MIME body part containing content information that conforms to this document `MUST` have an <> "Content-Type" value of text/calendar". | Y | Y +| 2.4 Content Type | `MUST` | The <> "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 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. | Y | Y +| 2.4 Content Type | `MUST` | A "charset" parameter `MUST` be present if the iCalendar object contains characters that are not part of the US-ASCII character set. <> discusses the selection of an appropriate "charset" value. | Y | Y +| 2.4 Content Type | `SHOULD` | 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. | Y | Y +| 2.5 Content-Transfer-Encoding | `SHOULD` | A transfer encoding `SHOULD` be used for iCalendar objects containing any characters that are not part of the US-ASCII character set. | Y | Y +| 2.6 Content-Disposition | `SHOULD` | The handling of a MIME part should be based on its <> "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. | Y | Y +| 3 Security Considerations | `MUST` | Compliant applications `MUST` support signing and encrypting text/calendar attachments using a mechanism based on Security Multiparts for MIME <> to facilitate the authentication the originator of the iCalendar object. | N | N +| 3 Security Considerations | `MAY` | Implementations `MAY` provide a means for users to disable signing and encrypting. | N | N +| 3 Security Considerations | `MUST` | 1. The iCalendar object `MUST` be signed by the "Organizer" sending an update or the "Attendee" sending a reply. | N | N +| 3 Security Considerations | `SHOULD` | To address the confidentiality security threats, signed iMIP messages `SHOULD` be encrypted by a mechanism based on Security Multiparts for MIME <>. | N | N +| 3 Security Considerations | `MUST` | Implementations `MUST` provide mechanisms for the "Calendar Users" to make that decision before applying changes from someone working on behalf of a "Calendar User". | N | N +|=== + +[bibliography] +== Bibliography + +* [[[rfc1738,RFC 1738]]] + +* [[[rfc822,RFC 822]]] + +* [[[rfc1847,RFC 1847]]] + +* [[[rfc2045,RFC 2045]]] + +* [[[rfc2046,RFC 2046]]] + +* [[[iso9070,ISO 9070]]] diff --git a/sources/cc-0403-report-ioptest/document.adoc b/sources/cc-0403-report-ioptest/document.adoc new file mode 100644 index 0000000..f668b07 --- /dev/null +++ b/sources/cc-0403-report-ioptest/document.adoc @@ -0,0 +1,237 @@ += July 2004 CalConnect Interoperability Test Report +:docnumber: 0403 +:copyright-year: 2004 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2004-07-30 +:published-date: 2004-07-30 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Report + +=== Participants + +* Dave Thewlis - Calendaring and Scheduling Consortium +* Pat Egen - IETF Co-chair and Calendaring and Scheduling Consortium +* Nathaniel S. Borenstein, IBM +* Chris Stoner -- IBM +* Keith MacDonald -- Oracle +* Simon Vaillancourt -- Oracle +* Jeff McCullough -- University of California at Berkeley - our host + +=== Products Tested + +* Lotus Notes 7 +* Oracle Collaboration Suite + +=== General Summary + +During our testing event at UC Berkeley two vendors participated. This was the fourth in a +series of interoperability testing events for RFC 2445, 2446, and 2447. The first two were +"onsite" events and the third was a "virtual" event with testing occurring via conference calls and +email testing. + +At the last three testing events, the testing done was more at a vendor to vendor level rather than +at a pure IETF "RFC Conformance" level. By Conformance testing, we mean identifying +support for and testing explicit `MUST`/`MUST NOT`/`SHOULD`/`SHOULD NOT`/ and `MAY` +requirements. + +In preparation for this interop event and to satisfy the requirement for RFC conformance testing, +a matrix of all three RFC's was prepared and this was used as our driver for testing compliance. +We, as a group, went through each and every item and validated whether the requirement was +supported by each vendor. In most cases, where both vendors did not support a particular +requirement, we still tested the action to validate this "non-support." From that perspective, this +was probably the most productive interop of all the events. + +Since there were only two participants at this interop, we will need at least one more +interoperability event to fully identify what needs to be removed from these drafts. Now that we +have a complete set of matrices as well as test scenarios and scripts, we can fully define what +works and doesn't work. I have included the notes from the other three events at the end of this +document for comparison. + +This document will highlight the key findings from this exercise. The matrix spreadsheet with all +items noted is attached to this report. The spreadsheet shows what is and is not supported by the +two participants. Based on past interops, and discussions held at this meeting we have +ascertained the following: + +* Most vendors are not doing Journals. It appears we can probably remove any `VJOURNAL` +items from all drafts without significant ramifications. +* Recurring and repeating meetings still have a bit of mystery and ambiguity associated with +them. This was obvious during testing and is well documented and discussed on the various +lists. We talked about the differences between recurring and repeating meetings and we look +to see this discussed further on all the mailing lists. +* ``VTODO``'s are not supported by either vendor and there were problems in past interops. This +may be something that can be removed and added back as another draft that just pertains to +``VTODO``s. + +The next page identifies the items that are supported by both vendors and the items not supported +on the three drafts. Note - there are 201 specific items in RFC 2445, 74 items in RFC 2446, and +14 items in RFC 2447. Any item not shown on the summary page means only one of the two +vendors during this interoperability event supports that item. + +I created a table that counts the number of items supported and not supported by both vendors as +well as a breakdown of how many of each item each vendor does or does not support. I also +created a table that shows the specific items supported by both vendors and a table showing the +specific items `NOT` supported by both vendors. + +In summary, we are farther along than we were during the first interop. But we have a ways to +go. There was discussion at this interop about opening a new mailing list to work on +simplification of these drafts in order to improve/enhance interoperability opportunities. + +The results for both vendors showed the following: + +[%unnumbered,options=header] +|=== +| Draft | Items Supported | Items Not Supported +| RFC 2445 | 114 | 26 +| RFC 2446 | 15 | 5 +| RFC 2447 | 8 | 5 +|=== + +By Vendor, the numbers look like this: + +[%unnumbered,options=header] +|=== +| Draft | Items Supported | Items Not Supported + +3+h| Vendor 1 +| RFC 2445 | 132 | 69 +| RFC 2446 | 35 | 39 +| RFC 2447 | 9 | 5 + +3+h| Vendor 2 +| RFC 2445 | 137 | 64 +| RFC 2446 | 45 | 29 +| RFC 2447 | 8 | 6 +|=== + +== Identification of Specific Items on the Drafts + +=== Items supported by BOTH vendors + +==== iCalendar - RFC 2445 - 114 items out of 201 + +* 2.3 International Considerations +* 4.1 Content Lines +* 4.2 Property Parameters +* 4.2.12 Participation Status +* 4.2.19 Time Zone Identifier +* 4.2.20 Value Data Types +* 4.3.3 Calendar User Address +* 4.3.5 Date-Time +* 4.3.10 Recurrence Rule +* 4.3.11 Text +* 4.3.12 Time +* 4.3.14 UTC Offset +* 4.4 iCalendar Object +* 4.6 Calendar Components +* 4.6.1 Event Component +* 4.6.2 To-do Component +* 4.6.5 Time Zone Component +* 4.7 Calendar Properties +* 4.7.2 Method +* 4.7.3 Product Identifier +* 4.7.4 Version +* 4.8.1.4 Comment +* 4.8.1.5 Description +* 4.8.1.6 Geographic Position +* 4.8.1.7 Location +* 4.8.1.10 Resources +* 4.8.1.12 Summary +* 4.8.2.1 Date/Time Completed +* 4.8.2.2 Date/Time End +* 4.8.2.4 Date/Time Start +* 4.8.2.7 Time Transparency +* 4.8.3.1 Time Zone Identifier +* 4.8.3.2 Time Zone Name +* 4.8.3.3 Time Zone Offset From +* 4.8.3.4 Time Zone Offset To +* 4.8.4.1 Attendee +* 4.8.4.2 Contact +* 4.8.4.3 Organizer +* 4.8.4.4 Recurrence ID +* 4.8.4.7 Unique Identifier +* 4.8.5.1 Exception Date/Times +* 4.8.5.4 Recurrence Rule +* 4.8.6.1 Action +* 4.8.7.2 Date/Time Stamp +* 4.8.7.4 Sequence Number +* 4.8.8.2 Request Status +* 6 Recommended Practices + +==== iTIP - RFC 2446 - 15 items out of 74 + +* 3.1 Common Component Restrictions +* 3.2.2 `VEVENT REQUEST` +* 3.2.2.1 Rescheduling an Event +* 3.2.2.2 Updating or Reconfirmation of an Event +* 3.2.3 `VEVENT REPLY` +* 3.2.4 `VEVENT ADD` +* 3.2.4 `VEVENT CANCEL` +* 3.6 Status Replies +* 3.7.2 Attendee Property Considerations +* 5 Application Protocol Fallbacks + +==== iMIP - RFC 2447 - 8 items out of 14 + +* 2.3 RFC 822 Addresses +* 2.4 Content Type (all) +* 2.5 Content-Transfer-Encoding +* 2.6 Content-Disposition + +=== Items NOT supported by BOTH vendors + +==== iCalendar - RFC 2445 - 26 of 201 items + +* 4.1.1 List and Field Separators +* 4.2.6 Directory Entry Reference +* 4.3.5 Date-Time +* 4.3.9 Period of Time +* 4.6.3 Journal Component +* 4.6.5 Time Zone Component +* 4.8.4.3 Organizer +* 4.8.4.5 Related To +* 4.8.6.3 Trigger +* 4.8.7.4 Sequence Number + +==== iTIP - RFC 2446 - 5 of 74 items + +* 3.1 Common Component Restrictions +* 3.2.2.6 Forwarding to An Uninvited CU +* 3.3 Methods For `VFREEBUSY` Components +* 3.3.2 `VFREEBUSY REQUEST` +* 3.3.3 `VFREEBUSY REPLY` +* 3.4.2.4 `REQUEST` Forwarded To An Uninvited Calendar User +* 3.4.1 `VTODO PUBLISH` +* 3.4.5 `VTODO CANCEL` +* 3.4.6 `VTODO REFRESH` +* 3.5.1 `VJOURNAL PUBLISH` +* 3.5.2 `VJOURNAL ADD` +* 3.5.3 `VJOURNAL CANCEL` +* 3.7.2 Attendee Property Considerations + +==== iMIP - RFC 2447 - 6 of 16 items + +* Section 3 - security considerations + +[bibliography] +== Bibliography + +* [[[report-1,1]]], CalConnect I -- April, 2000 + +* [[[report-2,2]]], CalConnect II -- April, 2001 + +* [[[report-3,3]]], CalConnect III -- Virtual interop, September, 2002 diff --git a/sources/cc-0404-report-roundtable-1/document.adoc b/sources/cc-0404-report-roundtable-1/document.adoc new file mode 100644 index 0000000..85dbe65 --- /dev/null +++ b/sources/cc-0404-report-roundtable-1/document.adoc @@ -0,0 +1,83 @@ += Report on Roundtable I, 23-24 September 2004 +:docnumber: 0404 +:copyright-year: 2004 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2004-09-24 +:published-date: 2004-09-24 +:technical-committee: CALCONNECT +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Report + +The first Roundtable sponsored by the Consortium took place on 23-24 September, 2004, hosted +by Oracle Corporation in Montreal. This event was not restricted to Consortium members. It was +an invitational "Open Roundtable on the Future of Interoperable Calendaring and Scheduling" and +the invitation was sent out to a variety of individuals and organizations involved in Calendaring +and Scheduling as vendors, customers, standards participants, etc. + +Twenty-three individuals from fourteen organizations attended the Roundtable. The discussion +was oriented towards three general areas: + +* Do we agree on a problem statement? +* Are we willing to work together to address the problem(s)? +* How do we want to go about undertaking this work? + +At the end of the two days, the participants had broadly agreed on a common definition of the +problem in terms of what had to be done to move forward with interoperable Calendaring and +Scheduling, and had jointly agreed to work together to address the problems. The group adopted +the following informal "charter" as a synthesis of their discussions: + +[quote] +"WE" will come together to develop use cases, in concert with the users of calendaring products, +to shape the technical requirements and critical input to help shape the work taking place in at +least CalDAV, CALSIFY, UMA and other calendaring areas. Areas of focus will be calendar +interoperability and a definition of a minimum implementation of same. We will also focus on +testing and evaluation of interoperability. Attention will be paid to the promotion and evangelism +of calendaring standards, capabilities and interop. + +The Roundtable agreed to work within the Consortium structure to accomplish its work, and +established a timetable for participating organizations to commit to and join the Consortium. Plans +for initial technical committees, and a general timetable for carrying out the work, were also +agreed. + +Represented at the Roundtable were Apple, Duke University, Isamet, IBM Lotus, the Mozilla +Foundation, Nokia, Novell, Oracle, OSAF (Open Source Applications Foundation), Stata Labs, +UC Berkeley, University of Washington, Yahoo!, and the Calendaring and Scheduling +Consortium. + +The critical mass of organizations joining the Consortium in the following months, both those who +had participated in the September Roundtable and others, enabled the Consortium to make its +public launch announcement on December 14, 2004, and to move forward with plans for its next +Roundtable in January 2005. diff --git a/sources/cc-0501-ioptest-rules/document.adoc b/sources/cc-0501-ioptest-rules/document.adoc new file mode 100644 index 0000000..6a05de8 --- /dev/null +++ b/sources/cc-0501-ioptest-rules/document.adoc @@ -0,0 +1,93 @@ += January 2005 CalConnect Interoperability Test Scenarios +:docnumber: 0501 +:copyright-year: 2005 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2005-01-12 +:published-date: 2005-01-12 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Basic Calendar Access Test Scenarios + +=== Event creation + +==== {blank} +Create new single-instance meeting titled "Meeting 1.1" with the location "Seattle". + +[[cls-1.2]] +==== {blank} +Create new meeting titled "Meeting 1.2" recurring every Monday from 10:00 AM to 11:00 +AM for 4 weeks. + +==== {blank} +Create new single-instance meeting titled "Meeting 1.3" with 2 other attendees. + +==== {blank} +Create new single-instance meeting titled "Meeting 1.4" with an alarm set to trigger +15 minutes prior to the schedule time of the meeting. + +=== Event modification + +==== {blank} +Modify the title of meeting "Meeting 1.1" to "Meeting 1.1bis". + +==== {blank} +Modify the location of the meeting "Meeting 1.1bis" to "Seattle bis". + +==== {blank} +Reschedule meeting "Meeting 1.1bis" to the next day. + +==== {blank} +Add an attendee to "Meeting 1.1bis". + +==== {blank} +Add an alarm to "Meeting 1.1bis". + +==== {blank} +Modify the title of the 1st instance of the recurring meeting created in <>. + +==== {blank} +Modify the participation status of + +==== {blank} +Cancel the 4th instance of the recurring meeting created in <>. + +==== {blank} +One client changes "Meeting 1.1bis" to a different time, second client 'refreshes' its display to see the modification. + +=== Event retrieval + +==== {blank} +Retrieve all the components and properties of the meetings scheduled for the current day (i.e., midnight to midnight local time). + +==== {blank} +Retrieve all the components and properties of the meetings scheduled for the current week. + +==== {blank} +Retrieve all the components and properties of the meetings scheduled for the current month. + +==== {blank} +Retrieve only the `SUMMARY`, `DTSTART` and `DTEND` +(or `DURATION`) properties of the meetings scheduled for the current week. + +=== Event deletion + +==== {blank} +Delete the meeting titled "Meeting 1.1bis" + +==== {blank} +Delete the meeting titles "Meeting 1.2" diff --git a/sources/cc-0502-report-ioptest/document.adoc b/sources/cc-0502-report-ioptest/document.adoc new file mode 100644 index 0000000..34a2e84 --- /dev/null +++ b/sources/cc-0502-report-ioptest/document.adoc @@ -0,0 +1,211 @@ += January 2005 CalConnect Interoperability Test Report +:docnumber: 0502 +:copyright-year: 2005 +:title-main-en: Interoperability Testing of RFC 2445 and the current CALDAV draft +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2005-01-12 +:published-date: 2005-01-12 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Report + +=== Participants + +* Pat Egen - Interop Manager - Calendaring and Scheduling Consortium +* Cyrus Daboo -- Isamet +* Mike Shaver - Mozilla +* Dan Mosedale -- Mozilla +* Bernard Desruisseaux -- Oracle +* Simon Vaillancourt -- Oracle +* Greg Barnes - University of Washington +* Scott Heyano -- University of Washington + +=== Products Tested + +* Oracle CALDAV server +* Isamet CALDAV server and two Isamet clients +* Mozilla clients + +=== Introduction + +In January, the Calendaring and Scheduling Consortium hosted their second interoperability +event at the University of Washington in Seattle. This was actually the fifth in the series of +interop events testing calendaring standards. The main purpose of the event is to exercise as +many client/server pairs as possible to identify what interoperates and what does not. + +During this event, two different groups did testing. The first group tested interoperability +between CalDav clients and servers. CALDAV is current a draft (see footnote below) and not +yet an RFC. However, it is always a good idea to start testing draft specifications as early as +possible to ensure a draft is heading in the right direction. Considerable work has already been +implemented using the draft in its current state. Therefore, there is enough of a code base to +facilitate interoperability testing. At this event, two servers and three client applications were +tested. + +The second set of testing was reading iCalendar objects created by an application developed by +the University of Washington. Their objects only used the RFC 2445 specification. They have +not added iTIP (RFC 2447) and iMIP (RFC 2446) functionality but this testing was an excellent +opportunity to test how different applications and servers reacted to their ics files. + +=== Summary + +In summary, the server implementations basically worked and did what they were supposed to +do. The clients are well along and passed the majority of the scenarios. There are some pieces +left to fill in but this is early in the interop testing scheme of things for CALDAV. The results +are pretty great for a specification so young. This bodes well for the future of this spec. + +=== CALDAV testing results + +A set of 19 basic testing scenarios were used to test the servers and clients. We tested event +creation, event modification, event retrieval and event deletion. One significant thing to note +about this interop is this is the first time we are using a server-based application to store and +retrieve events. + +Some general items were noted by each of the vendors present. They are as follows: + +==== Issues and findings + +It was determined there is no real good reason for a server to remember a URL specified by a +client. Implementers want to be able to forget a URI but do want to be able to send back the real +URI of the meeting that is the final object. There was discussion that there may have been +something in the CAP draft that handles this. That may be a resource for text to add to +CALDAV. + +When a client does a PUT the server sends back what the URI is at the end of the process. There +is dialog out on the CALDAV list that may point to possible resolutions. + +If an underlying WEBDAV server does not support ACL or locking, then the client must handle +everything. Locking would then be handled by tags and "if match" - you have to do a put +operation that fails - a lock will guarantee you have a connection if you don't get data back down +the pipe. + +It was determined it is hard to lock a collection. The question is will this cause a performance hit +on the server? + +In order to determine if locking is required, we need good usecases or test scenarios to prove or +justify requiring locking. It was suggested that implementers use eTags as a workaround. +However, server implementations will need to handle limits on locks. This gives rise to the +question of how to handle things when the lock is broken and the eTag has changed. Consensus +among the group was to not make it mandatory. + +One question that came up pertained to HREFs. The question is "are HREF's allowed to be +relative in Webdav?" + +The majority of issues found during testing were not with the CALDAV specifications, but more +with RFC2445 interpretations. For example, section 4.6.5 of RFC2445 addresses vtimezones +and rrules. The first paragraph in this section seems to be interpreted differently by various +clients. We will need to post this issue to the Calsify mailing list in the hopes that group can add +this to their list of required changes/enhancements to RFC2445. + +It was discussed that there might be an issue with propstat in the Caldav draft. Bernard from +Oracle is not sure and will research this. + +The following page shows the cases tested. The names of the clients are not noted -- we use a +code instead. C1, C2 and C3 are clients and S1 and S2 are servers. + +==== Results of Test Scenarios + +[%unnumbered,options=header,cols=7] +|=== +a| C1 + +> + +S1 +a| C1 + +> + +S2 +a| C2 + +> + +S1 +a| C3 + +> + +S1 +a| C2 + +> + +S2 +a| C3 + +> + +S2 | Test Scenario + +6+| | 1. Event creation. + +| Y | Y | Y | N/A | Y | N/A +| 1.1. Create new single-instance meeting titled "Meeting 1.1" with the location "Seattle". + +| F | Y | Y | N/A | Y | N/A +| 1.2. Create new meeting titled "Meeting 1.2" recurring every Monday from 10:00 AM to 11:00 AM for 4 weeks. + +| Y | Y | N | N/A | N | N/A +| 1.3. Create new single-instance meeting titled "Meeting 1.3" with 2 other attendees. + +| N/A | N/A | N | N/A | N | N/A +| 1.4. Create new single-instance meeting titled "Meeting 1.4" with an alarm set to trigger 15 minutes prior to the schedule time of the meeting. + +6+| | 2. Event modification +| Y | | Y | N/A | Y | N/A +| 2.1. Modify title of meeting "Meeting 1.1" to "Meeting 1.1bis". + +| Y | | Y | N/A | Y | N/A +| 2.2. Modify the location of the meeting "Meeting 1.1bis" to "Seattle bis". + +| Y | | F | N/A | Y | N/A +| 2.3. Reschedule meeting "Meeting 1.1bis" to the next day. + +| Y | | F | N/A | F | N/A +| 2.4. Add an attendee to "Meeting 1.1bis". + +| | | F | N/A | Y | N/A +| 2.5. Add an alarm to "Meeting 1.1bis". + +| | | F | N/A | F | N/A +| 2.6. Modify the title of the 1st instance of the recurring meeting created in 1.2. + +| | | F | N/A | F | N/A +| 2.7. Modify the participation status of + +| | | F | N/A | Y | N/A +| 2.8. Cancel the 4th instance of the recurring meeting created in 1.2. + +| Y | | F | N/A | N/A | N/A +| 2.9. One client changes "Meeting 1.1bis" to a different time, second client 'refreshes' its display to see the modification. + +6+| | 3. Event retrieval + +| Y | | Y | Y | Y | Y +| 3.1. Retrieve all the components and properties of the meetings scheduled for the current day (i.e., midnight to midnight local time). + +| Y | | Y | Y | Y | Y +| 3.2. Retrieve all the components and properties of the meetings scheduled for the current week. + +| F | | Y | Y | Y | Y +| 3.3. Retrieve all the components and properties of the meetings scheduled for the current month. + +| F | | N/A | N/A | Y | N/A +| 3.4. Retrieve only the `SUMMARY`, `DTSTART` and `DTEND` (or `DURATION`) properties of meetings scheduled for current week. + +6+| | 4. Event deletion + +| Y | | Y | N/A | Y | N/A +| 4.1. Delete the meeting titled "Meeting 1.1bis" + +| N | | Y | N/A | Y | N/A +| 4.2. Delete the meeting titles "Meeting 1.2" + +|=== + +[bibliography] +== Bibliography + +* [[[caldav-draft,IETF I-D draft-dusseault-caldav-04]]], Calendaring and Scheduling Extensions to WebDAV (CalDAV) draft-dusseault-caldav-04 diff --git a/sources/cc-0503-ioptest-rules/document.adoc b/sources/cc-0503-ioptest-rules/document.adoc new file mode 100644 index 0000000..124172d --- /dev/null +++ b/sources/cc-0503-ioptest-rules/document.adoc @@ -0,0 +1,88 @@ += June 2005 CalConnect Interoperability Test Scenarios +:docnumber: 0503 +:copyright-year: 2005 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2005-06-18 +:published-date: 2005-06-18 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Test Scenarios + +[%unnumbered,cols=2] +|=== +h| 1. h| Event creation. +| 1.1. | Create new single-instance meeting titled "Meeting 1.1" with the location "Durham". +| 1.2. | Create new meeting titled "Meeting 1.2" recurring every Monday from 10:00 AM to 11:00 AM for 4 weeks. +| 1.3. | Create new single-instance meeting titled "Meeting 1.3" with 2 other attendees. +| 1.4. | Create new single-instance meeting titled "Meeting 1.4" with an alarm set to trigger 15 minutes prior to the schedule time of the meeting. +h| 2. h| Event modification +| 2.1. | Modify the title of meeting "Meeting 1.1" to "Meeting 1.1bis". +| 2.2. | Modify the location of the meeting "Meeting 1.1bis" to "Seattle bis". +| 2.3. | Reschedule meeting "Meeting 1.1bis" to the next day. +| 2.4. | Add an attendee to "Meeting 1.1bis". +| 2.5. | Add an alarm to "Meeting 1.1bis". +| 2.6. | Modify the title of the 1st instance of the recurring meeting created in 1.2. +| 2.7. | Modify the participation status of 1st instance to `DECLINED`. +| 2.8. | Cancel the 4th instance of the recurring meeting created in 1.2. +| 2.9. | One client changes "Meeting 1.1bis" to a different time, second client 'refreshes' its display to see the modification. +h| 3. h| Event retrieval +| 3.1. | calendar-query `REPORT` +| 3.1.1. | No filtering (match everything) +| 3.1.1.1. | Query all components and return all data. (tests `` and ``) +| 3.1.1.2. | Query all components and return ETag WebDAV property and all data. (tests `+` and ``) +| 3.1.1.3. | Query all components and return just entire `VEVENT` components. (tests ``, `+`) +| 3.1.1.4. | Query all components and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `+`, `++`) +| 3.1.2. | time-range filtering +| 3.1.2.1. | Query all components within a one day time-range and return all data. Make sure that there is a recurring event that starts prior to the chosen time-range but has one non-overridden instance within the time-range. (tests ``, `+`) +| 3.1.2.2. | Query all components within a one week time-range and return just entire `VEVENT` components. Make sure that there is a recurring event that starts prior to the chosen time-range but has one overridden instance within the time-range. (tests ``, `+`) +| 3.1.3. | component based filtering +| 3.1.3.1. | Query all components that contain an embedded `VALARM` component. (tests ``, `+`) +| 3.1.3.2. | Query all components that contain an embedded `VALARM` component whose trigger falls within a specific time-range. (tests ``, `+++`) +| 3.1.4. | property based filtering +| 3.1.4.1. | Query all components that contain any `ORGANIZER` property. (tests ``, `++`) +| 3.1.4.2. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-insensitively. (tests ``, `+++`) +| 3.1.4.3. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-sensitively. (tests ``, `+++`) +| 3.1.5. | parameter based filtering +| 3.1.5.1. | Query all components that contain a `DTSTART` property with a `TZID` parameter. (tests ``, `++++`) +| 3.1.5.2. | Query all components that contain an `ATTENDEE` property with `PARTSTAT=NEEDSACTION` parameter. (tests ``, `++++`) +| 3.2. | calendar-multiget `REPORT` +| 3.2.1. | Query a specific href and return all data. (tests ``) +| 3.2.2. | Query multiple hrefs (some of which do not exist) and return all data. (tests ``) +| 3.2.3. | Query a specific href and return ETag WebDAV property and all data. (tests `+`) +| 3.2.4. | Query multiple hrefs (some of which do not exist) and return ETag WebDAV property and all data. (tests `+`) +| 3.2.5. | Query a specific href and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) +| 3.2.6. | Query multiple hrefs (some of which do not exist) and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) +h| 4. h| Event deletion +| 4.1. | Delete a single non-recurring meeting. +| 4.2. | Delete a single recurring meeting with no overridden instances. +| 4.3. | Delete a single recurring meeting with overridden instances. +| 4.4. | Delete a non-overridden instance of a recurring meeting. +| 4.5. | Delete an overridden instance of a recurring meeting. +h| 5. h| Access Control +| 5.1. | View access control details on current user's main calendar. +| 5.2. | Change access control details on current user's main calendar to add another user with read-only access. Verify that other user can view the calendar but not change it. +| 5.3. | Change access control details on current user's main calendar to add another user with read-write access. Verify that other user can view the calendar and change it. Verify that changes done by one user are seen by the other. +| 5.4. | Remove another user's access to the current user's main calendar and verify they can no longer access the calendar. +h| 6. h| Calendar Management +| 6.1 | Browse the list of calendars on the server, including the current user's personal calendars. +| 6.2 | Create a new calendar in the current user's personal calendar space. +| 6.3 | Create a regular collection in the current user's personal calendar space. +| 6.4 | Create a new calendar inside the collection created in 6.3. +| 6.5 | Delete the calendar created in 6.2. +| 6.6 | Delete the collection created in 6.3. +|=== diff --git a/sources/cc-0504-report-ioptest/document.adoc b/sources/cc-0504-report-ioptest/document.adoc new file mode 100644 index 0000000..8bf5476 --- /dev/null +++ b/sources/cc-0504-report-ioptest/document.adoc @@ -0,0 +1,445 @@ += June 2005 CalConnect Interoperability Test Report +:docnumber: 0504 +:copyright-year: 2005 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2005-06-18 +:published-date: 2005-06-18 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +[.preface] +== {blank} + +June 18, 2005 + +TO: CalConnect Members + +Re: June 1-3, 2005 Interop Test Results + +The following report details the results from the interop testing event held at +Duke University in Durham on June 1-3, 2005. The report includes text as +well as a spreadsheet with actual results of scenario testing. + +The attached version includes the public, abridged text and is meant for +public distribution. + +Respectfully submitted, + +Patricia Egen + +Interop Manager + +Calendaring and Scheduling Consortium + +:attachments + +== Report + +The following organizations and personnel participated in a two-day interoperability testing +event held on June 1-3, 2005 at Duke University. + +[%unnumbered] +|=== +| Organization | Representative +| Isamet | Cyrus Daboo +| Mozilla | Dan Mosedale +| Rodney Price | Novell{blank}footnote:[Novell was auditing the testing event -- their product was not tested.] +| Simon Vaillancourt | Oracle +| Mike Douglass | Rensselaer Polytechnic Institute (RPI) +|=== + +Versions tested are as follows: + +Isamet: + +* Mulberry v4.0 - client (publicly released) +* Mulberry J2ME v0.1 - client (not released) +* ISAMET CalDAV server v0.2 - server (not released) + +Mozilla: + +* Mozilla Lightening Client -- no version number available (yet) + +Oracle: + +* CalConnectCalDAVTest script - Version 1.0 +* OracleCalDAV server - June-2005 version! + +RPI: + +* UWCalendar - Version RPI-2.3.1 + +=== Interop Discussion Items + +At the beginning of the interoperability event, we held a general discussion with each of the +participants. They in turn discussed what would be tested, and the current status of their +implementations. We also agreed upon ``userid``s, server names and IP addresses to access +the servers. + +VendorA, B and C provided URL's for connection to their servers. Two were situated locally +on the intranet and one was on a public IP address. These three servers were then used +during testing by the two clients. + +VendorA tested two clients and one server. They support level 5 of Caldav. Their desktop +client has been publicly released. Their server had a few minor changes since the last +interop testing. In addition, they are working on a FreeBusy report. Multi Get has been +implemented in their client. Their mobile client had no changes since the last interop +testing event. + +VendorC tested their client; however, their server had an issue arise so it was not tested +during the interop. There are no version numbers yet assigned. They support version 5 of +the Caldav draft. + +VendorB tested both a client and a server implementation. They also support version 5 of +the Caldav draft. They are working on the Keep Alive connection. Simon noted that we +need to ensure that applications are also WEBDAV and HTTP compliant since much of the +CALDAV draft rides upon those specifications. For the purpose of this event, we are +assuming applications support the current levels of both WEBDAV and HTTP. + +VendorD has a server and runs on a skeletal Webdav server. They do not support ACLs or +recurrences. Their Put/Get works and they support reports. They support level 5 of the +Caldav draft as well. + +A set of test scenarios had been provided by Bernard Desruisseaux from Oracle. These +scenarios focused on a specific set of events for testing. The events tested were as follows: + +Calendar Events + +* Creation +* Modification +* Deletion +* Query + +Access Control + +* Creation +* Modification +* Deletion + +Several tables at the end of this report breakdown each test scenario. There is a table for +each client that show how each of the three servers responded to their calendar +submissions. There is also a table that show what each server supports. + +=== Summary + +Overall, the specific items tested went well. Not all of the specification was tested -- what +was tested did not point out any specific issues with the draft. + +Items of note are: + +* Access Control Lists are not yet supported by any of the servers or clients. +* Clients and servers both had some issues with respect to their implementation of the draft +components. Several of those items were fixed during the testing. All clients still have +some components that are not yet working and are still under development. +* Two servers support the majority of the items selected for testing during this event. The +third server supports less but is well on its way towards being a robust CalDAV server. +* With regards to RFC2445, the iCalendar specification, there appears to be an issue with +recurring rules with `DTSTART` in UTC. While it is not valid in RFC2445, several of the +vendors support `DTSTART` in UTC. Therefore, this issue needs to be addressed -- either the +RFC2445 must be changed or the vendors need to change their applications to support the +current RFC2445. This is an issue that will be turned over to the Calsify technical group as +it will be pertinent to the simplification work going on for RFC2445. +* Going forward, we need to get additional vendors into the testing group. It would be good +to see if we can find additional mobile vendors for testing as well. The consortium will be +looking into ways of expanding the number of vendors that participate during +interoperability events. The more we test, the more we ensure a good specification. +* In order to move the draft to proposed standard level within the IETF (after it becomes an +RFC), we will need to test all the ``MUST``s/``SHOULD``s/``MUST NOT``s/``SHOULD NOT``s in the draft +in order to be considered interoperable. Pat Egen, the interop manager, volunteered to put +together a matrix of these components and will post this on the public CalConnect server. + +Finally, the following are comments by two of the participants stating how they felt the +interop went overall. + +//// +EDITOR: It seems a part of the text is missing here. +//// + +[appendix] +== Supporting Tables - Test Results + +[cols=5,options=header,headerrows=2] +.VendorA Desktop Client +|=== +3+| VENDORA Desktop Client 2.2+| +| VENDORA | VENDORB | VENDORD + +| | | h| 1. h| Event creation. +| P | P | P | 1.1. | Create new single-instance meeting titled "Meeting 1.1" with the location "Durham". +| P | P | N | 1.2. | Create new meeting titled "Meeting 1.2" recurring every Monday from 10:00 AM to 11:00 AM for 4 weeks. +| P | P | N | 1.3. | Create new single-instance meeting titled "Meeting 1.3" with 2 other attendees. +| P | P | N | 1.4. | Create new single-instance meeting titled "Meeting 1.4" with an alarm set to trigger 15 minutes prior to the schedule time of the meeting. +| | | h| 2. h| Event modification +| P | P | P | 2.1. | Modify the title of meeting "Meeting 1.1" to "Meeting 1.1bis". +| P | P | P | 2.2. | Modify the location of the meeting "Meeting 1.1bis" to "Seattle bis". +| P | P | P | 2.3. | Reschedule meeting "Meeting 1.1bis" to the next day. +| P | P | N | 2.4. | Add an attendee to "Meeting 1.1bis". +| P | P | N | 2.5. | Add an alarm to "Meeting 1.1bis". +| N | N | N | 2.6. | Modify the title of the 1st instance of the recurring meeting created in 1.2. +| N | N | N | 2.7. | Modify the participation status of 1st instance to `DECLINED`. +| P | P | N | 2.8. | Cancel the 4th instance of the recurring meeting created in 1.2. +| P | P | P | 2.9. | One client changes "Meeting 1.1bis" to a different time, second client 'refreshes' its display to see the modification. +| | | h| 3. h| Event retrieval +| | | h| 3.1. h| calendar-query `REPORT` +| | | h| 3.1.1. h| No filtering (match everything) +| N | N | N | 3.1.1.1. | Query all components and return all data. (tests `` and ``) +| N | N | N | 3.1.1.2. | Query all components and return ETag WebDAV property and all data. (tests `+` and ``) +| N | N | N | 3.1.1.3. | Query all components and return just entire `VEVENT` components. (tests ``, `+`) +| N | N | N | 3.1.1.4. | Query all components and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `+`, `++`) +| | | h| 3.1.2. h| time-range filtering +| N | N | N | 3.1.2.1. | Query all components within a one day time-range and return all data. Make sure that there is a recurring event that starts prior to the chosen time-range but has one non-overridden instance within the time-range. (tests ``, `+`) +| N | N | N | 3.1.2.2. | Query all components within a one week time-range and return just entire `VEVENT` components. Make sure that there is a recurring event that starts prior to the chosen time-range but has one overridden instance within the time-range. (tests ``, `+`) +| | | h| 3.1.3. h| component based filtering +| N | N | N | 3.1.3.1. | Query all components that contain an embedded `VALARM` component. (tests ``, `+`) +| N | N | N | 3.1.3.2. | Query all components that contain an embedded `VALARM` component whose trigger falls within a specific time-range. (tests ``, `+++`) +| | | h| 3.1.4. h| property based filtering +| N | N | N | 3.1.4.1. | Query all components that contain any `ORGANIZER` property. (tests ``, `++`) +| N | N | N | 3.1.4.2. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-insensitively. (tests ``, `+++`) +| N | N | N | 3.1.4.3. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-sensitively. (tests ``, `+++`) +| | | h| 3.1.5. h| parameter based filtering +| N | N | N | 3.1.5.1. | Query all components that contain a `DTSTART` property with a `TZID` parameter. (tests ``, `++++`) +| N | N | N | 3.1.5.2. | Query all components that contain an `ATTENDEE` property with `PARTSTAT=NEEDS-ACTION` parameter. (tests ``, `++++`) +| | | h| 3.2. h| calendar-multiget `REPORT` +| N | N | N | 3.2.1. | Query a specific `href` and return all data. (tests ``) +| P | P | P | 3.2.2. | Query multiple ``href``s (some of which do not exist) and return all data. (tests ``) +| N | N | N | 3.2.3. | Query a specific `href` and return ETag WebDAV property and all data. (tests `+`) +| P | P | P | 3.2.4. | Query multiple ``href``s (some of which do not exist) and return ETag WebDAV property and all data. (tests `+`) +| N | N | N | 3.2.5. | Query a specific `href` and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) +| N | N | N | 3.2.6. | Query multiple ``href``s (some of which do not exist) and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) +| | | h| 4. h| Event deletion +| P | P | P | 4.1. | Delete a single non-recurring meeting. +| P | P | N | 4.2. | Delete a single recurring meeting with no overridden instances. +| N | N | N | 4.3. | Delete a single recurring meeting with overridden instances. +| N | P | N | 4.4. | Delete a non-overridden instance of a recurring meeting. +| N | N | N | 4.5. | Delete an overridden instance of a recurring meeting. +| | | h| 5. h| Access Control +| P | N | N | 5.1. | View access control details on current user's main calendar. +| P | N | N | 5.2. | Change access control details on current user's main calendar to add another user with read-only access. Verify that other user can view the calendar but not change it. +| P | N | N | 5.3. | Change access control details on current user's main calendar to add another user with read-write access. Verify that other user can view the calendar and change it. Verify that changes done by one user are seen by the other. +| P | N | N | 5.4. | Remove another user's access to the current user's main calendar and verify they can no longer access the calendar. +|=== + +[%key] +P:: Pass +F:: Fail +N:: Not supported + +[cols=5,options=header,headerrows=2] +.VendorA Mobile Client +|=== +3+| VENDORA Mobile Client 2.2+| +| VENDORA | VENDORB | VENDORD + +| | | h| 1. h| Event creation. +| N | N | N | 1.1. | Create new single-instance meeting titled "Meeting 1.1" with the location "Durham". +| N | N | N | 1.2. | Create new meeting titled "Meeting 1.2" recurring every Monday from 10:00 AM to 11:00 AM for 4 weeks. +| N | N | N | 1.3. | Create new single-instance meeting titled "Meeting 1.3" with 2 other attendees. +| N | N | N | 1.4. | Create new single-instance meeting titled "Meeting 1.4" with an alarm set to trigger 15 minutes prior to the schedule time of the meeting. +| | | h| 2. h| Event modification +| N | N | N | 2.1. | Modify the title of meeting "Meeting 1.1" to "Meeting 1.1bis". +| N | N | N | 2.2. | Modify the location of the meeting "Meeting 1.1bis" to "Seattle bis". +| N | N | N | 2.3. | Reschedule meeting "Meeting 1.1bis" to the next day. +| N | N | N | 2.4. | Add an attendee to "Meeting 1.1bis". +| N | N | N | 2.5. | Add an alarm to "Meeting 1.1bis". +| N | N | N | 2.6. | Modify the title of the 1st instance of the recurring meeting created in 1.2. +| N | N | N | 2.7. | Modify the participation status of 1st instance to `DECLINED`. +| N | N | N | 2.8. | Cancel the 4th instance of the recurring meeting created in 1.2. +| N | N | N | 2.9. | One client changes "Meeting 1.1bis" to a different time, second client 'refreshes' its display to see the modification. +| | | h| 3. h| Event retrieval +| | | h| 3.1. h| calendar-query `REPORT` +| | | h| 3.1.1. h| No filtering (match everything) +| N | N | N | 3.1.1.1. | Query all components and return all data. (tests `` and ``) +| N | N | N | 3.1.1.2. | Query all components and return ETag WebDAV property and all data. (tests `+` and ``) +| N | N | N | 3.1.1.3. | Query all components and return just entire `VEVENT` components. (tests ``, `+`) +| N | N | N | 3.1.1.4. | Query all components and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `+`, `++`) +| | | h| 3.1.2. h| time-range filtering +| P | P | N | 3.1.2.1. | Query all components within a one day time-range and return all data. Make sure that there is a recurring event that starts prior to the chosen time-range but has one non-overridden instance within the time-range. (tests ``, `+`) +| P | P | N | 3.1.2.2. | Query all components within a one week time-range and return just entire `VEVENT` components. Make sure that there is a recurring event that starts prior to the chosen time-range but has one overridden instance within the time-range. (tests ``, `+`) +| | | h| 3.1.3. h| component based filtering +| N | N | N | 3.1.3.1. | Query all components that contain an embedded `VALARM` component. (tests ``, `+`) +| N | N | N | 3.1.3.2. | Query all components that contain an embedded `VALARM` component whose trigger falls within a specific time-range. (tests ``, `+++`) +| | | h| 3.1.4. h| property based filtering +| N | N | N | 3.1.4.1. | Query all components that contain any `ORGANIZER` property. (tests `, `++`) +| N | N | N | 3.1.4.2. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-insensitively. (tests ``, `+++`) +| N | N | N | 3.1.4.3. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-sensitively. (tests ``, `+++`) +| | | h| 3.1.5. h| parameter based filtering +| N | N | N | 3.1.5.1. | Query all components that contain a `DTSTART` property with a `TZID` parameter. (tests ``, `++++`) +| N | N | N | 3.1.5.2. | Query all components that contain an `ATTENDEE` property with `PARTSTAT=NEEDS-ACTION` parameter. (tests ``, `++++`) +| | | h| 3.2. h| calendar-multiget `REPORT` +| N | N | N | 3.2.1. | Query a specific `href` and return all data. (tests ``) +| N | N | N | 3.2.2. | Query multiple ``href``s (some of which do not exist) and return all data. (tests ``) +| N | N | N | 3.2.3. | Query a specific `href` and return ETag WebDAV property and all data. (tests `+`) +| N | N | N | 3.2.4. | Query multiple ``href``s (some of which do not exist) and return ETag WebDAV property and all data. (tests `+`) +| N | N | N | 3.2.5. | Query a specific `href` and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) +| N | N | N | 3.2.6. | Query multiple ``href``s (some of which do not exist) and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) +| | | h| 4. h| Event deletion +| N | N | N | 4.1. | Delete a single non-recurring meeting. +| N | N | N | 4.2. | Delete a single recurring meeting with no overridden instances. +| N | N | N | 4.3. | Delete a single recurring meeting with overridden instances. +| N | N | N | 4.4. | Delete a non-overridden instance of a recurring meeting. +| N | N | N | 4.5. | Delete an overridden instance of a recurring meeting. +| | | h| 5. h| Access Control +| N | N | N | 5.1. | View access control details on current user's main calendar. +| N | N | N | 5.2. | Change access control details on current user's main calendar to add another user with read-only access. Verify that other user can view the calendar but not change it. +| N | N | N | 5.3. | Change access control details on current user's main calendar to add another user with read-write access. Verify that other user can view the calendar and change it. Verify that changes done by one user are seen by the other. +| N | N | N | 5.4. | Remove another user's access to the current user's main calendar and verify they can no longer access the calendar. +|=== + +[%key] +P:: Pass +F:: Fail +N:: Not supported + +[cols=5,options=header,headerrows=2] +.VendorC Client +|=== +3+| VENDORC Client 2.2+| +| VENDORA | VENDORB | VENDORD + +| | | h| 1. h| Event creation. +| N (3) | N | N | 1.1. | Create new single-instance meeting titled "Meeting 1.1" with the location "Durham". +| N (3) | N | N | 1.2. | Create new meeting titled "Meeting 1.2" recurring every Monday from 10:00 AM to 11:00 AM for 4 weeks. +| N (3) | N | N | 1.3. | Create new single-instance meeting titled "Meeting 1.3" with 2 other attendees. +| N (3) | N | N | 1.4. | Create new single-instance meeting titled "Meeting 1.4" with an alarm set to trigger 15 minutes prior to the schedule time of the meeting. +| | | h| 2. h| Event modification +| P | P | P | 2.1. | Modify the title of meeting "Meeting 1.1" to "Meeting 1.1bis". +| P | P | P | 2.2. | Modify the location of the meeting "Meeting 1.1bis" to "Seattle bis". +| P | P | P | 2.3. | Reschedule meeting "Meeting 1.1bis" to the next day. +| P | P | N | 2.4. | Add an attendee to "Meeting 1.1bis". +| N | N | N | 2.5. | Add an alarm to "Meeting 1.1bis". +| N | N | N | 2.6. | Modify the title of the 1st instance of the recurring meeting created in 1.2. +| N | N | N | 2.7. | Modify the participation status of 1st instance to `DECLINED`. +| N | N | N | 2.8. | Cancel the 4th instance of the recurring meeting created in 1.2. +| (NOT TESTED) | (NOT TESTED) | P | 2.9. | One client changes "Meeting 1.1bis" to a different time, second client 'refreshes' its display to see the modification. +| | | h| 3. h| Event retrieval +| | | h| 3.1. h| calendar-query `REPORT` +| | | h| 3.1.1. h| No filtering (match everything) +| N | N | N | 3.1.1.1. | Query all components and return all data. (tests `` and ``) +| N | N | N | 3.1.1.2. | Query all components and return ETag WebDAV property and all data. (tests `+` and ``) +| N | N | N | 3.1.1.3. | Query all components and return just entire `VEVENT` components. (tests ``, `+`) +| N | N | N | 3.1.1.4. | Query all components and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `+`, `++`) +| | | h| 3.1.2. h| time-range filtering +| N | N | N | 3.1.2.1. | Query all components within a one day time-range and return all data. Make sure that there is a recurring event that starts prior to the chosen time-range but has one non-overridden instance within the time-range. (tests ``, `+`) +| P (2) - except override | P (1) - except recurr | P (1) - except recurr | 3.1.2.2. | Query all components within a one week time-range and return just entire `VEVENT` components. Make sure that there is a recurring event that starts prior to the chosen time-range but has one overridden instance within the time-range. (tests ``, `+`) +| | | h| 3.1.3. h| component based filtering +| N | N | N | 3.1.3.1. | Query all components that contain an embedded `VALARM` component. (tests ``, `+`) +| N | N | N | 3.1.3.2. | Query all components that contain an embedded `VALARM` component whose trigger falls within a specific time-range. (tests ``, `+++`) +| | | h| 3.1.4. h| property based filtering +| N | N | N | 3.1.4.1. | Query all components that contain any `ORGANIZER` property. (tests ``, `++`) +| N | N | N | 3.1.4.2. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-insensitively. (tests ``, `+++`) +| N | N | N | 3.1.4.3. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-sensitively. (tests ``, `+++`) +| | | h| 3.1.5. h| parameter based filtering +| N | N | N | 3.1.5.1. | Query all components that contain a `DTSTART` property with a `TZID` parameter. (tests ``, `++++`) +| N | N | N | 3.1.5.2. | Query all components that contain an `ATTENDEE` property with `PARTSTAT=NEEDS-ACTION` parameter. (tests ``, `++++`) +| | | h| 3.2. h| calendar-multiget `REPORT` +| N | N | N | 3.2.1. | Query a specific `href` and return all data. (tests ``) +| N | N | N | 3.2.2. | Query multiple ``href``s (some of which do not exist) and return all data. (tests ``) +| N | N | N | 3.2.3. | Query a specific `href` and return ETag WebDAV property and all data. (tests `+`) +| N | N | N | 3.2.4. | Query multiple ``href``s (some of which do not exist) and return ETag WebDAV property and all data. (tests `+`) +| N | N | N | 3.2.5. | Query a specific `href` and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) +| N | N | N | 3.2.6. | Query multiple ``href``s (some of which do not exist) and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) +| | | h| 4. h| Event deletion +| P | P | P | 4.1. | Delete a single non-recurring meeting. +| P | N | N | 4.2. | Delete a single recurring meeting with no overridden instances. +| N | N | N | 4.3. | Delete a single recurring meeting with overridden instances. +| N | N | N | 4.4. | Delete a non-overridden instance of a recurring meeting. +| N | N | N | 4.5. | Delete an overridden instance of a recurring meeting. +| | | h| 5. h| Access Control +| N | N | N | 5.1. | View access control details on current user's main calendar. +| N | N | N | 5.2. | Change access control details on current user's main calendar to add another user with read-only access. Verify that other user can view the calendar but not change it. +| N | N | N | 5.3. | Change access control details on current user's main calendar to add another user with read-write access. Verify that other user can view the calendar and change it. Verify that changes done by one user are seen by the other. +| N | N | N | 5.4. | Remove another user's access to the current user's main calendar and verify they can no longer access the calendar. +|=== + +[%key] +P:: Pass +F:: Fail +N:: Not supported + +NOTE: Recurrence between VENDORC and VENDORB is currently non-functional. + +NOTE: VENDORC's overriding/exceptions is not working yet. + +NOTE: Current VENDORC Lightening VI doesn't support creation other than via +drag-to-create and modify +to change things like title. That will change soon. The backend code supports 1.1-1.3 but not yet 1.4. + +NOTE: VENDORC used their Lightening product for testing. + +[cols=5,options=header,headerrows=2] +.Server Support +|=== +3+| Server - Support 2.2+| +| VENDORA | VENDORB | VENDORD + +| | | h| 1. h| Event creation. +| P | P | P | 1.1. | Create new single-instance meeting titled "Meeting 1.1" with the location "Durham". +| P | P | N | 1.2. | Create new meeting titled "Meeting 1.2" recurring every Monday from 10:00 AM to 11:00 AM for 4 weeks. +| P | P | N | 1.3. | Create new single-instance meeting titled "Meeting 1.3" with 2 other attendees. +| P | P | N | 1.4. | Create new single-instance meeting titled "Meeting 1.4" with an alarm set to trigger 15 minutes prior to the schedule time of the meeting. +| | | h| 2. h| Event modification +| P | P | P | 2.1. | Modify the title of meeting "Meeting 1.1" to "Meeting 1.1bis". +| P | P | P | 2.2. | Modify the location of the meeting "Meeting 1.1bis" to "Seattle bis". +| P | P | P | 2.3. | Reschedule meeting "Meeting 1.1bis" to the next day. +| P | P | N | 2.4. | Add an attendee to "Meeting 1.1bis". +| P | P | N | 2.5. | Add an alarm to "Meeting 1.1bis". +| P | P | N | 2.6. | Modify the title of the 1st instance of the recurring meeting created in 1.2. +| P | P | N | 2.7. | Modify the participation status of 1st instance to `DECLINED`. +| P | P | N | 2.8. | Cancel the 4th instance of the recurring meeting created in 1.2. +| P | P | P | 2.9. | One client changes "Meeting 1.1bis" to a different time, second client 'refreshes' its display to see the modification. +| | | h| 3. h| Event retrieval +| | | h| 3.1. h| calendar-query `REPORT` +| | | h| 3.1.1. h| No filtering (match everything) +| P | P | P | 3.1.1.1. | Query all components and return all data. (tests `` and ``) +| P | P | P | 3.1.1.2. | Query all components and return ETag WebDAV property and all data. (tests `+` and ``) +| P | P | P | 3.1.1.3. | Query all components and return just entire `VEVENT` components. (tests ``, `+`) +| P | P | P | 3.1.1.4. | Query all components and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `+`, `++`) +| | | h| 3.1.2. h| time-range filtering +| P | P | P | 3.1.2.1. | Query all components within a one day time-range and return all data. Make sure that there is a recurring event that starts prior to the chosen time-range but has one non-overridden instance within the time-range. (tests ``, `+`) +| P | P | P | 3.1.2.2. | Query all components within a one week time-range and return just entire `VEVENT` components. Make sure that there is a recurring event that starts prior to the chosen time-range but has one overridden instance within the time-range. (tests ``, `+`) +| | | h| 3.1.3. h| component based filtering +| P | P | N | 3.1.3.1. | Query all components that contain an embedded `VALARM` component. (tests ``, `+`) +| P | P | N | 3.1.3.2. | Query all components that contain an embedded `VALARM` component whose trigger falls within a specific time-range. (tests ``, `+++`) +| | | h| 3.1.4. h| property based filtering +| P | P | P | 3.1.4.1. | Query all components that contain any `ORGANIZER` property. (tests ``, `++`) +| P | P | F | 3.1.4.2. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-insensitively. (tests ``, `+++`) +| P | P | F | 3.1.4.3. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-sensitively. (tests ``, `+++`) +| | | h| 3.1.5. h| parameter based filtering +| P | P | N | 3.1.5.1. | Query all components that contain a `DTSTART` property with a `TZID` parameter. (tests ``, `++++`) +| P | P | N | 3.1.5.2. | Query all components that contain an `ATTENDEE` property with `PARTSTAT=NEEDS-ACTION` parameter. (tests ``, `++++`) +| | | h| 3.2. h| calendar-multiget `REPORT` +| P | P | P | 3.2.1. | Query a specific `href` and return all data. (tests ``) +| P | P | P | 3.2.2. | Query multiple ``href``s (some of which do not exist) and return all data. (tests ``) +| P | P | P | 3.2.3. | Query a specific `href` and return ETag WebDAV property and all data. (tests `+`) +| P | P | P | 3.2.4. | Query multiple ``href``s (some of which do not exist) and return ETag WebDAV property and all data. (tests `+`) +| P | P | P | 3.2.5. | Query a specific `href` and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) +| P | P | P | 3.2.6. | Query multiple ``href``s (some of which do not exist) and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) +| | | h| 4. h| Event deletion +| P | P | P | 4.1. | Delete a single non-recurring meeting. +| P | P | N | 4.2. | Delete a single recurring meeting with no overridden instances. +| P | P | N | 4.3. | Delete a single recurring meeting with overridden instances. +| P | P | N | 4.4. | Delete a non-overridden instance of a recurring meeting. +| P | P | N | 4.5. | Delete an overridden instance of a recurring meeting. +| | | h| 5. h| Access Control +| N | N | N | 5.1. | View access control details on current user's main calendar. +| N | N | N | 5.2. | Change access control details on current user's main calendar to add another user with read-only access. Verify that other user can view the calendar but not change it. +| N | N | N | 5.3. | Change access control details on current user's main calendar to add another user with read-write access. Verify that other user can view the calendar and change it. Verify that changes done by one user are seen by the other. +| N | N | N | 5.4. | Remove another user's access to the current user's main +calendar and verify they can no longer access the calendar. +|=== + +[%key] +P:: Pass +F:: Fail +N:: Not supported diff --git a/sources/cc-0505-questionnaire-results-recurrence/document.adoc b/sources/cc-0505-questionnaire-results-recurrence/document.adoc new file mode 100644 index 0000000..2b07efb --- /dev/null +++ b/sources/cc-0505-questionnaire-results-recurrence/document.adoc @@ -0,0 +1,362 @@ += Results from First Recurrence Questionnaire +:docnumber: 0505 +:copyright-year: 2005 +:language: en +:doctype: specification +:edition: 1 +:status: published +:revdate: 2005-07-21 +:published-date: 2005-07-21 +:technical-committee: RECURR +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:imagesdir: images + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +The Recurrence Technical Committee of CalConnect (The Calendaring and Scheduling +Consortium) has collected specific +information on how C&S implementations have, or have not, implemented the Recurrence +Rules of RFCs 2445 and 2446, iCalendar +and iTIP. This document is part of the committee's work to compile actual usage +information and interoperability issues. + +The Recurrence Committee recently collected information in the form of a Recurrence +Questionnaire, which allowed vendors and +other producers and consumers of iCalendar recurrences to list the features of +iCalendar that they implemented. The questionnaire +also contained space for comments about each line item in the RFCs and also overall +issues with recurrences. The Recurrence +Technical Committee has since analyzed the results of the questionnaire into this +document. + +The Committee and the Consortium would like to thank all those who took part in this +effort by filling out the Recurrence +Questionnaire. + +This document is generally available to all who responded to the questionnaire in +evaluating their implementation against others, and to +all organizations and implementors working with Calendaring and Scheduling +implementations. The Recurrence Technical +Committee of CalConnect would appreciate feedback on the value and relevance of this +material from those who make use of it. +Feedback and comments may be sent to the Executive Director of the Consortium via +Dave.Thewlis@calconnect.org. + +== Aggregate of Results for 19 Respondents + +[%unnumbered,cols=8,options=header] +|=== +| | Yes | No | Othr | N/A | Total | Percent | Summary Comments + +h| iCalendar Elements 5+| | 54% | +| 4.3.10.a Recurrence Rule | 15 | 0 | 2 | 2 | 19 | 79% | Only use first instance. No errors for incorrect data +| 4.3.10.b Recurrence Rule | 15 | 0 | 2 | 2 | 19 | 79% | No errors for incorrect data. Some do not support '`SECONDLY`' / '`MINUTELY`' / '`HOURLY`' frequences +| 4.3.10.c Recurrence Rule | 8 | 5 | 4 | 2 | 19 | 42% | Issues related to use of timezones in `UNTIL`: some only handle UTC. One does `DATE` only not `DATETIME` in `UNTIL`. One does not export `UNTIL` any longer due to legacy and server compatibility issues, but attempts to read `UNTIL` as best it can. +| 4.3.10.d Recurrence Rule | 12 | 3 | 2 | 2 | 19 | 63% | `BYSETPOS` not fully supported. No errors for incorrect data. +| 4.6.1.a Event Component | 15 | 0 | 1 | 2 | 18 | 83% | Some `PROPS` not stored, Only last value used if specified more than once. One vendor does not export geo and url. +| 4.6.1.b Event Component | 12 | 0 | 4 | 2 | 18 | 67% | Some do not support `EXRULE`, `RDATE` etc. Some ``PROP``s not stored. Only first instance of `PROP` used. One does not export comment, exrule, rstatus, and related. Some only support zero or one `RRULE`, and no exrules. +| 4.6.2.a To-do Component | 11 | 3 | 2 | 2 | 18 | 61% | Some do not support `TODO`. Some `PROPS` not stored. +| 4.6.2.b To-do Component | 9 | 3 | 4 | 2 | 18 | 50% | Some do not support `EXRULE`, `RDATE` etc. Some do not support `TODO`. Some ``PROP``s not stored. Only first instance of `PROP` used. Some do not support `RRULE` and `EXRULE` for `VTODO`. +| 4.6.3.a Journal Component | 4 | 7 | 5 | 2 | 18 | 22% | Most do not generate `VJOURNAL`. Some consume it. Some ignore it. +| 4.6.3.b Journal Component | 3 | 9 | 3 | 2 | 17 | 18% | Most do not generate `VJOURNAL`. Some consume it. Some ignore it. +| 4.6.4.a Free/Busy Component | 10 | 4 | 2 | 2 | 18 | 56% | Some do not support `VFREEBUSY`. Some issues with timezones. One only imports and exports with the Internet Free Busy feature. Some ignore it. +| 4.6.5.a Time Zone Component | 10 | 5 | 1 | 2 | 18 | 56% | Some only use UTC. +| 4.6.5.b Time Zone Component | 10 | 5 | 1 | 2 | 18 | 56% | Some only use UTC. One always exports UTC or Floating time if possible, but can import iCals which use this area of the spec. +| 4.6.5.c Time Zone Component | 9 | 4 | 2 | 2 | 17 | 53% | Some only use UTC. +| 4.6.6.a Alarm Component | 9 | 6 | 1 | 2 | 18 | 50% | Some do not support `VALARM`. Some do not support repeating alarms. Some support sending alarm components. +| 4.6.6.b Alarm Component | 7 | 7 | 2 | 2 | 18 | 39% | Some do not support `VALARM`. Some do not support repeating alarms. +| 4.6.6.c Alarm Component | 6 | 5 | 4 | 2 | 17 | 35% | Some do not support `VALARM`. Some do not support repeating alarms. +| 4.8.4.4.a Recurrence ID | 11 | 2 | 2 | 2 | 17 | 65% | Some do not implement. Some produce just the date portion for `RECURRRENCE-ID`; no Time and do not set `DATE` parameter. +| 4.8.4.4.b Recurrence ID | 10 | 2 | 3 | 2 | 17 | 59% | Some do not implement. Some do not handle more than one R-ID. Some do not import/export `DATE-TIME` or rangeparam. +| 4.8.4.4.c Recurrence ID | 6 | 4 | 5 | 2 | 17 | 35% | Some do not support `XPARAMS`. One only reads first `XPARAM`. +| 4.8.5.1.a Exception Date/Times | 11 | 1 | 2 | 2 | 16 | 69% | One changes start date of instance. +| 4.8.5.1.b Exception Date/Times | 11 | 2 | 1 | 2 | 16 | 69% | Some do not implement. One does not export `DATE-TIME` since that's implicit. +| 4.8.5.1.c Exception Date/Times | 5 | 6 | 4 | 2 | 17 | 29% | Some ignore ``XPARAM``s on `EXDATE`. +| 4.8.5.3.a Recurrence Date/Times | 9 | 3 | 2 | 2 | 16 | 56% | One does not implement `RDATE` only `RRULE`. Some do not support `VALUE=PERIOD` for ``EXDATE``s or ``RDATE``s. +| 4.8.5.3.b Recurrence Date/Times | 6 | 5 | 4 | 2 | 17 | 35% | One does not implement `RDATE` only `RRULE`. Some do not support ``XPARAM``s +| 4.8.5.4.a Recurrence Rule | 9 | 3 | 4 | 2 | 18 | 50% | Some do not support `RDATE`. Some generate new components if component changed. Some use `EXDATE` to detach instances. Some do not support `PERIOD` in ``RDATE``s. +| 4.8.7.4.a Sequence Number | 7 | 3 | 5 | 2 | 17 | 41% | One changes `SEQUENCE` when other ``PROP``s change. Some require new event for change. Some do not increment sequence of instance when start or end of instance is changed. +h| iTIP Elements 5+| | 18% | +| 3.2.4.a `VEVENT` `CANCEL` | 9 | 4 | 2 | 2 | 17 | 53% | Some do not support. One generates OK, but does not consume it OK. +| 3.2.4.b `VEVENT` `CANCEL` | 6 | 7 | 2 | 2 | 17 | 35% | Some do not support. One generates OK, but does not consume it OK. Some use `EXDATE` for cancellations. +| 3.2.4.c `VEVENT` `CANCEL` | 2 | 8 | 5 | 2 | 17 | 12% | Some do not support. One generates OK, but does not consume it OK. Some use `EXDATE` for cancellations. Some only handle single instance or the entire set. Some do not support `RANGE` in `RECURRENCE-ID`. +| 3.4.5.a `VTODO` `CANCEL` | 3 | 9 | 3 | 2 | 17 | 18% | Some do not support. Some do not support `iTIP` + `VTODO`. One generates OK, but does not consume it OK. +| 3.4.5.b `VTODO` `CANCEL` | 3 | 9 | 3 | 2 | 17 | 18% | Some do not support. Some do not support `iTIP` + `VTODO`. One generates OK, but does not consume it OK. +| 3.4.6.a `VTODO` `REFRESH` | 1 | 10 | 3 | 2 | 16 | 6% | Some do not support. Some do not support `iTIP` + `VTODO`. One generates OK, but does not consume it OK. +| 3.5.3.a `VJOURNAL` `CANCEL` | 1 | 10 | 3 | 2 | 16 | 6% | Some do not support. Some do not support `iTIP` + `VJOURNAL`. +| 3.5.3.b `VJOURNAL` `CANCEL` | 0 | 11 | 3 | 2 | 16 | 0% | Some do not support. Some do not support `iTIP` + `VJOURNAL`. +h| Part 3 7+| +| See <> tab 7+| +h| Part 4 7+| +| See <> tab 7+| +|=== + +[%landscape] +<<< + +[%unnumbered] +image::img01.png[] + +[%portrait] +<<< + +[%unnumbered] +image::img02.png[] + +[[part3]] +== Part 3 + +=== iTIP + +==== Reschedules + +Additionally we have issues with other vendors who send a new rule on +reschedule of recurring meeting. Reschedules are problematic for us with +interop with other vendors. THe other vendors want to remove the old set +and replace it with the new set, but we don't allow that. We preserve the +original set and try to move it to the new dates.times, but that isn't +always possible if the new set that's sent has fewer/more instances than +the original one. + +Removing an invitee (not strictly specific to recurring): +For removing an invitee (which was bundled in with `CANCEL`), we do not +increment sequence number on the instance (recurring or single actually) so +that we can add that user back into the meeting later. If we increment the +sequence number on removal, then when we try to see who is coming to our +meeting, the sequence #'s will no longer match up - that data is stale now. +The responses will be off by 1 (from the removal). Remove should be a +separate workflow event, not requiring a bump of sequence number, be it +repeating or single. + +==== Broken up recurrance sets + +For meetings that have shifted, as in a 5 day daily repeating meeting: +Monday, Tuesday, Wedsnesday, Thursday, Friday all from 10-11am. If we +reschedule each of these individually to be of different times, say Monday +(9-10), Tuesday(8-9), Wedsnesday(7-8), Thursday(12-1), Friday(1-2) and then +reschedule the entire set to be from 3-4pm, does that mean that the user +wants each day to be from 3-4pm? + +Additionally with the same scenario, if I change Monday's body item (or +just 1 other field, like Subject) and then apply that to the entire set, +should all of the data on Monday be deposited into the rest of the set? +What if I had booked a different Room for Thursday? What if all I expected +was the body to be updated (since that's all I changed) and now the +Subject, location, etc. - all the fields have changed (one vendor's +implementation). That's not what I expected - I expected to know that I +only wanted to update just the body field, but ical does not give us the +information to know that we only intended to change body for just this +instance. + +Vendor has a bit of iTIP implementation, enough to accept/reject invitations, but that's it. + +=== Rules and Rdates + +`RDATE` is not supported at all (WHY?) + +The iCalendar Recurrence rule section is very elaborate. I'm not aware of any product that +conforms to it fully. Specifically, most products recognize only one `RRULE` and the others are ignored. + +There is more than one way to specify recurrences. For example, we can specify a daily event as a +`FREQ=WEEKLY` event with weekday = su, mo...sa or as a `FREQ=DAILY`. It is relatively easy to +implement a recurrence engine to generate events using the rules, but we find it hard to recognize +it as a daily event to be displayed in User Interface. + +What is the acceptability of interpreting one rule as another (e.g. reinterpret yearly as every 12 months repeat)? + +No support for multiple ``RRULE``s. + +No support for ``EXRULE``s. + +Cannot modify the `RRULE` attribute (But ``RDATE``s and ``EXDATE``s can be added). + +No support/limited support for these attributes: `INFINITE`, `SECONDLY`. + +Vendor supports a special recurrence option for monthly meetings where an instance +that falls on a weekend +can be shifted to a weekday, either the preceding Friday, the following Monday, or +whichever is closer. +There is no way to sufficiently represent this in iCalendar. Hypothetically, a +complex series of ``RRULE``s can +come close, but in cases where the adjustment would cross a month boundary there is +no recourse. + +Vendor is using a lot the `RECURRENCE-ID` / `UID` identification in data model to +represent "detached" events, +specialization for a given occurrence in a recurrence. This is apparently a much +debated point in the +interpretation of the specification. Vendor would like to stress the fact that iTIP +support is great for invitation +interoperability, but the first level should be even before invitations handling, +just representation of a given +calendar ("`PUBLISH`" support) so entire calendars can be published, stored, subscribed +and imported. + +Some other problematic points with recurrences, as seen by Vendor: + +* the exact semantic of date-based triggers for alarms set on a recurring event +* the lack of a standard, commonly accepted vtimezone definitions is a major +roadblock to correctly interpret recurrences. + +=== Date handling + +`DTEND` property was not well defined. For example, if we have event with +`DTSTART=20040404T100000` and `DURATION=PT2H`, it is not clear if the +`DTEND` should be 120000 or 115900. We have seen iCalendars with both the conventions. + +All times are written in UTC (even when the event/todo has an `RRULE`) - (WHY?) + +=== Timezones + +Though not directly linked to recurrences, the timezone is one of most difficult part to implement +and least useful for majority of users. Many users just use one timezone. + +The big piece of hard functionality from 2445 that vendor hasn't implemented is timezones. + +Standard C library APIs deal well with only two timezones: UTC, and the local +timezone (whatever that is). +So, vendor's library works well in these two cases, including with ``RRULE``s that cross +DST shifts. Vendor +needs to implement a date-time abstraction that uses timezones as specified by +`VTIMEZONE`. Vendor +Vendor hasn't had the time yet. Suspects that the widespread lack of good APIs to +deal with timezones +will be the biggest interop headache for many implementations. But, vendor feels that +we can't take +timezones out of the spec, they are critical to how time is measured/used, and we +need a protocol that +will work properly between CUAs in various timezones. This is hard, but necessary. + +Vendor confused by 4.6.5.c and posted two possible answers: + +. We never export invalid time zone information, and we never reference undeclared time zones. +. A recurring appointment which gets shifted by a time zone (e.g. Daily from 1pm to +2pm PST) *can* have an exception which is all day long (floating). + +=== CPL + +Vendor implements a subset of RFC 2445, primarily `RRULE` reoccurrence to do time +handling as specified in CPL +in CPL (RFC 3880) - which in turn refers to RFC 2445 for it's implementation. CPL is +a script language which +allows for the declaration of complex call forwarding behaviors, in IP telephony systems. + +=== Sequence Number + +Vendor has not seen any product that uses the sequence number field correctly. + +=== vTo Dos and vJournal + +Partial support for ``VTODO``s (Intending on improving it). + +Support for ``VJOURNAL``s in our internal API but not in iCalendar. + +Vendor does not support `VJOURNAL` (little customer interest) + +=== General Comments + +It's not clear if the questions are for reading or for writing +Vendor's product really doesn't implement an iCalendar protocol. + +Vendor licenses its operating system as a platform for handset manufacturers to build their +products with. The answers to the questionnaire describe what conformance is enabled by the PIM +data stores provided in a particular version of the vendor's operating system +Other versions do not provide iCalendar parsing/generation or RFC 2446 implementation - this +functionality will be provided by handset manufacturers. + +Vendor has created a toolkit, which at its lowest level is built on an RFC 2425 +encoder/decoder, +so it's possible to encode `ANYTHING`. An app built on this toolkit may encode +according to the +`MUST` rules, or may not, so many of the questions don't really apply. You can do it +right, or you can do +it wrong, and on decoding, vendor tries and be liberal in what is accepted. So, most +of answers are either +`OTHER` or `NO`. Despite this, vendor feels compliance is pretty good (in the things +implemented), it's just +that it's very hard to write a flexible toolkit that makes it impossible to generate +calendars that break the rules. + +Lots of stuff vendor hasn't done are easy, just haven't had the time or need for them yet. + +In general, vendor does not always return errors for incorrect data input. However, +they consume correct +data properly, and produce right data in most of the above cases. + +Vendor has always considered it unusual that monthly recurrence rules that might fall +outside the range of +shorter months result in the instance being skipped. Vendor actually forbids such a +meeting, but if iCalendar +is to allow such a recurrence rule, it should follow the lead of many other +applications and pull the instance +back to the last day of the month. Currently, it's just a little silly. If a +company's employees get paid on the +15th and 30th of every month, shouldn't my iCalendar-compliant accounting application +be capable of doing "the right thing" in February? + +Vendor's resource scheduler product does not accept iCal documents, only generates +them. Currently does not create recurrence data. + +Vendor's library provides applications with support for recurrences mainly in three areas: + +* translating RFC2445-style recurrences into an internal structure; +* creating recurrences (and exceptions) with a procedural API; +* iterating over instances. + +Everything else is expected to be handled by the application. + +More tests are needed. This is a direct consequence of the extreme complexity of the +specification and the many corner cases that need to be tested. + +(What are the complex areas and what corner cases need to be flushed out?) + +[[part4]] +== Part 4 + +. Would you like to see a similar questionnaire for all of RFCs 2445 and 2446 (knowing that it would be quite large). ++ +-- +Vendor would like to see similar questionnaire for all of RFCs 2445 and especially 2446. + +Vendor would like to see a similar questionnaire for RFC2445 and 2446. +-- + +. Was it worthwhile for you to fill this out in the sense that it allows you to compare your implementation to the proposed standards? ++ +-- +Yes + +It was useful to fill out the questionnaire. +-- + +. Can you offer us any additional comments to help us do better in the future? ++ +-- +To be accurate, the question "Does your product conform the specification" should be +split into (a) Does your product access +iCalendar objects conforming to the specification and (b) Does your product generate +iCalendar objects conforming to the specification. +I've answered the second question because most of the time, we were reading iCalendar +objects generated by us. + +_[ We will answer this part in the second questionnaire by asking those exact questions ]_ + +Another vendor commented about the use of yes/no instead of producing/consuming. + +Vendor thought It would be very helpful when all the replies would be open for +reading by everyone, so that we can compare our implementations. + +Vendor felt that to assist completion of future questionnaires, examples for complex +areas would be useful. +-- + +<<< + +embed::questionnaire-recurrence.adoc[] diff --git a/sources/cc-0505-questionnaire-results-recurrence/images/img01.png b/sources/cc-0505-questionnaire-results-recurrence/images/img01.png new file mode 100644 index 0000000..7027636 Binary files /dev/null and b/sources/cc-0505-questionnaire-results-recurrence/images/img01.png differ diff --git a/sources/cc-0505-questionnaire-results-recurrence/images/img02.png b/sources/cc-0505-questionnaire-results-recurrence/images/img02.png new file mode 100644 index 0000000..c4d9563 Binary files /dev/null and b/sources/cc-0505-questionnaire-results-recurrence/images/img02.png differ diff --git a/sources/cc-0505-questionnaire-results-recurrence/questionnaire-recurrence.adoc b/sources/cc-0505-questionnaire-results-recurrence/questionnaire-recurrence.adoc new file mode 100644 index 0000000..83e6a2a --- /dev/null +++ b/sources/cc-0505-questionnaire-results-recurrence/questionnaire-recurrence.adoc @@ -0,0 +1,321 @@ += Questionnaire on Implementation of Recurrence +:docnumber: 0505 +:copyright-year: 2005 +:language: en +:doctype: specification +:edition: 1 +:status: published +:revdate: 2005-07-21 +:published-date: 2005-07-21 +:technical-committee: RECURR +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + +== Questionnaire on Implementation of Recurrence + +//// +EDITOR: Document attributes are not available for this document. +//// + +The Recurrence Technical Committee of the Consortium is collecting specific +information on how calendaring and scheduling +implementations have implemented or not implemented the recurrence rules of iCalendar +as part of its work to compile actual usage +information and develop recommendations to CalSIFY and other efforts. + +This questionnaire is *NOT* limited to Consortium members; we need information from +as many different implementations as possible. +We appreciate your responding to this questionnaire with as much information about +your implementation as you can. If you do not +know whether the response to an individual rule instance is "Yes" or "No" please +leave the response blank. We welcome as much +information as you are able and willing to supply. If we have questions or are +unclear about your responses we will contact you via the +e-mail address you supply. + +Our goal is to obtain a broad perspective on how recurrence has been dealt with in +existing implementations. The final report which the +Consortium will make public will not identify any particular product or +implementation, nor will it present the results in a way which +will allow such inferences to be made. + +=== Part 1. Product/Implementation being reported + +Please specify the product or implementation name, your name, and your e-mail +address. We will contact you via e-mail if we have any questions or are +unclear about any of your responses. + +Product/Implementation Name:: +Name of Person Reporting:: +E-Mail Address::   + +=== Part 2. Specific Implementation Information + +This table contains elements for specific rules from RFC 2445. For each one, please +indicate whether the implementation does (Yes) or does not (No) +conform to the stated rule. If you have comments, issues or questions about this rule +please enter in the Comment line under the rule. + +NOTE: The ``MUST``s, ``MUST NOT``s, etc. in the specs refer to both consumption and +production of the relevant items. To be compliant you have to do both +correctly. So for the purposes of the questionnaire please answer YES only if you +both produce and consume the item correctly (or if your +implementation only does one thing - i.e. just consumes - then answer YES to that if +it conforms). Ignore any behavior for non-compliant data being +consumed. + +NOTE: If you cannot reasonably answer either Yes or No to a question, please respond +"Other" and explain the problem or situation in the comment line +(or, if the statement is too long for the comment line, in the comment area at the +end of the form. + +[%unnumbered,cols="3a,1a,5a"] +|=== +3+h| RFC 2445 - iCalendar elements + +| 4.3.10.a Recurrence Rule + +○ Yes ○ No ○ Other +| `MUST` +| Individual rule parts `MUST` only be specified once. + +| 4.3.10.b Recurrence Rule + +○ Yes ○ No ○ Other +| `MUST` +| The `FREQ` rule part identifies the type of recurrence rule. This rule part `MUST` be specified in the recurrence rule. + +| 4.3.10.c Recurrence Rule + +○ Yes ○ No ○ Other +| `MUST` +| If `UNTIL` is specified as a date-time value, then it `MUST` be specified in a UTC time format. + +| 4.3.10.d Recurrence Rule + +○ Yes ○ No ○ Other +| `MUST` +| `BYSETPOS` `MUST` only be used in conjunction with another `BYxxx` rule part. + +| 4.6.1.a Event Component + +○ Yes ○ No ○ Other +| `MUST NOT` +| The following are optional but `MUST NOT` occur more than once: class / created / description / dtstart / geo / last-mod / location / organizer / priority / dstamp / seq / status / summary / transp / uid / url / recurid. + +| 4.6.1.b Event Component + +○ Yes ○ No ○ Other +| `MAY` +| The following are optional and `MAY` occur more than once: attach / attendee / categories / comment / contact / exdate / exrule / rstatus / related / resources / rdate / rrule / x-pro. + +| 4.6.2.a To-do Component + +○ Yes ○ No ○ Other +| `MUST NOT` +| The following are optional, but `MUST NOT` occur more than once: class / completed / created / description / dstamp / dtstart / geo / last-mod / location / organizer / percent / priority / recurid / seq / status / summary / uid / ur. + +| 4.6.2.b To-do Component + +○ Yes ○ No ○ Other +| `MAY` +| The following are optional, and `MAY` occur more than once: attach / attendee / categories / comment / contact / exdate / exrule / rstatus / related / resources / rdate / rrule / x-pro. + +| 4.6.3.a Journal Component + +○ Yes ○ No ○ Other +| `MUST NOT` +| The following are optional, but `MUST NOT` occur more than once: class / created / description / dtstart / dstamp / last-mod / organizer / recurid / seq / status / summary / uid / url. + +| 4.6.3.b Journal Component + +○ Yes ○ No ○ Other +| `MAY` +| The following are optional, and `MAY` occur more than once: attach / attendee / categories / comment / contact / exdate / exrule / related / rdate / rrule / rstatus / x-pro. + +| 4.6.4.a Free/Busy Component + +○ Yes ○ No ○ Other +| `MUST NOT` +| 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. + +| 4.6.5.a Time Zone Component + +○ Yes ○ No ○ Other +| `MUST` +| 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. + +| 4.6.5.b Time Zone Component + +○ Yes ○ No ○ Other +| `MAY` +| A '`VTIMEZONE`' calendar component `MAY` be present if the iCalendar object does not contain an `RRULE` that generates dates on both sides of a time zone shift. + +| 4.6.5.c Time Zone Component + +○ Yes ○ No ○ Other +| `MUST` +| If an `RRULE` that generates dates on both sides of a time zone shift is present, there `MUST` be valid time zone information for all recurrence instances. + +| 4.6.6.a Alarm Component + +○ Yes ○ No ○ Other +| `MUST NOT` +| '`DURATION`' and '`REPEAT`' are both optional, and `MUST NOT` occur more than once each, but if one occurs, so `MUST` the other. + +| 4.6.6.b Alarm Component + +○ Yes ○ No ○ Other +| `MUST` +| A definition of an alarm with a repeating trigger `MUST` include both the '`DURATION`' and '`REPEAT`' properties. + +| 4.6.6.c Alarm Component + +○ Yes ○ No ○ Other +| `MUST` +| Both '`DURATION`' and '`REPEAT`' 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. + +| 4.8.4.4.a Recurrence ID + +○ Yes ○ No ○ Other +| `MUST` +| If the value of the '`DTSTART`' property is a '`DATE`' type value, then the value `MUST` be the calendar date for the recurrence instance. + +| 4.8.4.4.b Recurrence ID + +○ Yes ○ No ○ Other +| `MUST NOT` +| The following are optional, but `MUST NOT` occur more than once: "`VALUE`" "=" ("`DATE-TIME`" / "`DATE`"), tzidparam, rangeparam. + +| 4.8.4.4.c Recurrence ID + +○ Yes ○ No ○ Other +| `MAY` +| The following are optional, and `MAY` occur more than once: xparam. + +| 4.8.5.1.a Exception Date/Times + +○ Yes ○ No ○ Other +| `MUST` +| 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`". + +| 4.8.5.1.b Exception Date/Times + +○ Yes ○ No ○ Other +| `MUST NOT` +| The following are optional, but `MUST NOT` occur more than once: "`VALUE`" "=" ("`DATE-TIME`" / "`DATE`"), tzidparam. + +| 4.8.5.1.c Exception Date/Times + +○ Yes ○ No ○ Other +| `MAY` +| The following is optional, and `MAY` occur more than once: xparam. + +| 4.8.5.3.a Recurrence Date/Times + +○ Yes ○ No ○ Other +| `MUST NOT` +| The following are optional, but `MUST NOT` occur more than once: "`VALUE`" "=" ("`DATE-TIME`" / "`DATE`" / "`PERIOD`"), tzidparam. + +| 4.8.5.3.b Recurrence Date/Times + +○ Yes ○ No ○ Other +| `MAY` +| The following is optional, and `MAY` occur more than once: xparam. + +| 4.8.5.4.a Recurrence Rule + +○ Yes ○ No ○ Other +| `MUST` +| 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. + +| 4.8.7.4.a Sequence Number + +○ Yes ○ No ○ Other +| `MUST` +| 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`". + +3+h| RFC 2446 - iTIP elements + +| 3.2.4.a `VEVENT CANCEL` + +○ Yes ○ No ○ Other +| `MUST` +| To cancel the complete range of a recurring event, the "`UID`" property value for the event `MUST` be specified and a "`RECURRENCE-ID`" `MUST NOT` be specified in the "`CANCEL`" method. + +| 3.2.4.b `VEVENT CANCEL` + +○ Yes ○ No ○ Other +| `MUST` +| 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. + +| 3.2.4.c `VEVENT CANCEL` + +○ Yes ○ No ○ Other +| `MUST` +| Cancelling multiple `VEVENT` instances `MUST` be done with either "`RECURRENCE-ID`" and "`RANGE`" `OR` multiple "`RECURRENCE-ID`" values. + +| 3.4.5.a `VTODO CANCEL` + +○ Yes ○ No ○ Other +| `MUST` +| 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. + +| 3.4.5.b `VTODO CANCEL` + +○ Yes ○ No ○ Other +| `MUST` +| 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. + +| 3.4.6.a `VTODO REFRESH` + +○ Yes ○ No ○ Other +| `MUST` +| 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. + +| 3.5.3.a `VJOURNAL CANCEL` + +○ Yes ○ No ○ Other +| `MUST` +| 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. + +| 3.5.3.b `VJOURNAL CANCEL` + +○ Yes ○ No ○ Other +| `MUST` +| 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. +|=== + +=== Part 3. Additional Comments or Issues with Recurrences + +Please use the following area{blank}footnote:[If your comments are likely to be long, +please send them by e-mail to Dave.Thewlis@calconnect.org and reference the +questionnaire response to which they belong.] to provide any additional comments or +issues with recurrences that may not be addressed above; known interop issues with +a particular other implementation that might conflict with your implementation; etc. + +=== Part 4. Feedback on Value of this Questionnaire + +We would appreciate your feedback on this questionnaire. Specifically, (1) Would you +like to see a similar questionnaire for all of RFCs 2445 and 2446 +(knowing that it would be quite large). (2) Was it worthwhile for you to fill this +out in the sense that it allows you to compare your implementation to the +proposed standards? (3) Can you offer us any additional comments to help us do better +in the future? + +=== Part 5. Completion and Submission + +Please review your completed questionnaire carefully. You may use the "CLEAR" button +below to clear the entire form and re-enter all information. Use +the "SEND" button to transmit the completed questionnaire to us. + +[%unnumbered,align=center] +|=== +| Send | Clear form & start over +|=== + +[align=center] +This site uses frames. + +If you do not see the navigation sidebar on the left, please click Restore to +establish the full site. diff --git a/sources/cc-0506-report-ioptest/document.adoc b/sources/cc-0506-report-ioptest/document.adoc new file mode 100644 index 0000000..9e1fc32 --- /dev/null +++ b/sources/cc-0506-report-ioptest/document.adoc @@ -0,0 +1,298 @@ += September 2005 CalConnect Interoperability Test Report +:docnumber: 0506 +:copyright-year: 2005 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2005-09-14 +:published-date: 2005-09-14 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Report + +This event is the seventh event testing calendar interoperability and is the fourth one sponsored by the +Calendaring and Scheduling Consortium. The participants and the products and drafts they tested are +as follows: + +[%unnumbered,cols=4] +|=== +2+| VendorName | Products | Tested +| EVDB | Dan Markham | EVDB Server | iCalendar +| IBM | Bill Le | Lotus Notes 7 | iCalendar,iTIP,iMIP +| Isamet | Cyrus Daboo | Mulberry | CALDAV, iCalendar +| Mozilla | Dan Mosedale | Thunderbird | iCalendar +| Novell | Dave Camp | Hula Server | CALDAV +| Oracle | Simon Vaillancourt | Collaboration Suite | CALDAV, iCalendar +.3+| OSAF | Grant Baillie | Chandler | CALDAV +| Jeffrey Harris | Chandler | iCalendar +| Brian | Cosmo | CALDAV +| RPI | Mike Douglass | RPI Calendar Server | CALDAV +.2+| Sun | Ciny Joy | Sun Calendar Server | iCalendar,iTIP,iMIP +| May Ma | | +|=== + +Prior to the interop the participants had pre-work to review iCalendar streams, CALDAV scripts and to +provide usernames and passwords to the interop list in order for us to attempt to get an earlier start on +interop testing. + +=== CALDAV Testing + +Anyone testing CALDAV had a test script to run through. During the pre-testing, some items were +found in the script that were corrected and put back on the CalConnect web server. + +As noted before, the CALDAV script was available for pre-testing as "Homework". Some things that +were found and fixed were the following:' + +One tester noted the following while testing the CALDAV script: these were useful tests of +conformance. I guess there's almost an infinite number of incorrect forms of data but checking that the +server enforces guid and uri uniqueness might be worthwhile. And I should add that having these tests +available has been very useful. + +They also found the following testing the script prior to the interop. They tried creating a new account +to run the scripts against and ran into another problem. The guid is supposed to be globally unique but +isn't. As a first pass he tried changing line 104 to: + +`T_UIDPREFIX="CalConnectCalDAVTest.${T_USERNAME1}."` + +We should probably add a timestamp or something. + +The script developer replied with: The test is not supposed to be leaving any meetings it created when +it's done, if it does you need to manually clean them up before re-running the test on any users. +Additionally, the test does not support being run at the same time from 2 different users because of the +UIDs. Your idea to add a timestamp is a good one but should only help in running the test from 2 users +at the same time. + +The tester also found the following items which were fixed. + +The cleanup doesn't have an .ics suffix on the names. Is this to test the servers response to the "MAY" +in calendaring and scheduling information may be suffixed by ".ics", Does the ".ics" form part of the +name. + +The tester's iCalendar parser is failing with the `MAIL_TO` value. All the RFC examples show mailto +and RFC1738 only mentions mailto. This was fixed and the script updated. + +A new matrix was provided that has all the Musts/Shoulds/Mays and Must Nots/Should Nots listed for +the CALDAV draft. Several of the participating vendors filled out this sheet and the results are +included with this report. + +A CALDAV scenario testing spreadsheet was completed by all the participants and is a summary +spreadsheet is included in this report. + +=== RFC2445, 2446, and 2447 Testing + +Several ics streams had been submitted prior to the interop and these were pointed to as part of the prework. +The idea was that vendors could try out the streams to see how their products reacted. I'm not +sure how much of that was done prior to the interop. However, several of the streams were tested at +the actual interop. + +In addition, a Test scenario used at the last RFC interop was used to create examples. During the +testing, it became apparent that it would be very helpful to have example ics streams next to each of +the test scenarios. + +=== Specific Findings and observations + +The following are some key notes from the CALDAV and iCalendar, iMIP and iTIP . + +During testing of the iCalendar scenarios, one vendor was able to: + +* `PUBLISH` and process an event to/from all vendors +* send/receive from all vendors a single without attachments. +* send all vendors a single with one attachment (bmp). +* send all vendors a single with two attachments (txt and bmp). +* send all vendors a single with AltReps of text in the description field. +* send all vendors a single with AltReps of text in the comments dialog. +* send all vendors a single with AltReps of text in the location field. +* send all vendors a single with audio alarm. +* send all vendors a single with display alarm. +* send all vendors a single with email alarm. +* send to vendors individually. +* send to GROUP of vendors. +* send all vendors a single Invite with an RnR. +* send a single Invite with Chair role to all vendors. +* send a single Invite with `REQ-PARTICIPANT` role to all vendors. +* send a single Invite with `OPT-PARTICIPANT` role to all vendors. +* send a single Invite with `NEEDS-ACTION`. +* send an `ACCEPTED` out. +* send a `DECLINED` out. +* send a `TENTATIVE` out. +* delegate an invite. +* send with `RSVP=TRUE` +* send with `RSVP=FALSE` +* send out with `DELEGATED-TO` +* send out with `DELEGATED-FROM` +* send a single event with `SENT-BY` to all vendors +* send with a CN. + +During testing of accepting and declining invitations, they sent a vendor a single event. The vendor +accepts. The vendor then declines. The paired vendor does not support a request for a Refresh. They +were not able to test delegation as no one present supported this. + +This was the second vendor's first interop and several items on the scenarios were not tested. The +items where they were successful in sending were: + +* Receipt of a published event from all vendors +* Sending a published event to one vendor +* Display only and email only alarms on Non-repeating events +* Under Partstat they can handle Needs-Action, Accept, Decline and Tentative with two vendors. +* They can send accept an invitation and reschedule of a meeting. +* They can `RSVP` to one vendor but not to another. +* They can send and receive chair, req-participant, opt-participant and non-participant on Roles. + +Specific issues we came across in testing one client: + +* URL quoting was badly broken (Having '@' in some of the calendar paths was very useful!). +* iCALENDAR interoperability issues within the context of ical4j +* Some code that tries to tell whether a resource exists on the server via HTTP ``OPTION``s. After +twiddling it to try to get it to work on 5 different servers (and some non-CalDAV servers elsewhere), +the tester decided to re-factor it to use `PROPFIND` where possible. +* Finally, running through some CalDAV tests helped isolate display issues in vendor apps. This has +nothing to do with interoperability per se, but it's a serendipitous side-effect! + +Some problems found (in all products): + +* iCAL: Escaping of some characters was not done properly. One vendor did not escape all CR in a +description property. +* iCAL: Some recurring meetings created by some products did not specify a time zone which is +required by RFC2445. According to the draft, 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. About 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. +* CalDAV: If-None-Match and if-match precondition bugs. This is a bug on a CalDAV server where +`if-none-match=*` was not handled properly and a bug on a CalDAV client where `if-none-mach=*` was set +when modifying an event. +* CalDAV: Interop problems with one vendor's WebDAV interface making it unable to create events +on "strict" CalDAV servers. Their WebDAV interface does a lot of things when creating a file, the +most problematic being the `PUT` of an empty file before doing the actual put of the real file. A +CalDAV server enforcing the validity of the ics files being created will never accept that an empty ics +file be created. Also it seems to be attempting to create some "`.`" hidden files without +changing the file extension. +* iCAL: `EXDATE` handling problems - Some vendors were not removing occurrences cancelled with +exdate +* iCAL: Handling problems with meetings without endtime or duration specified. Some vendors +always expected to have either a `DURATION` or a `DTEND` in a `VEVENT` component. RFC2445 +clearly specifies that these are valid events. From the RFC, the description is: "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." +* iCAL: Handling problems when `VTIMEZONE` defined after `VEVENT` components. A vendor +couldn't import events where the `VTIMEZONE` component was defined after the `VEVENT` +component which is a valid `VCALENDAR` object. +* iCAL: Matching of recurrence-id to ``RDATE``s problems. A vendor was not doing a proper "union" +with ``RDATE``s matching dates of a rule (The occurrences would appear as 2 occurrences instead of one. + +One vendor can receive our iCal correctly, but they can't do a REPLY. This vendor sends us iCal +stream, but we never receive any iCal stream. This is because they sent us a multi-event iCal (an initial +rule event plus an update event for same uid within single iCalendar stream), which we don't +understand and we don't handle it completely. + +One vendor sent an iCal stream with no `DTEND`. We can parse it, but our client can't handle an event +without enddatetime. This is in the schedule to enhance this issue for our next release. + +We can't handle EXDATEs correctly. In the schedule to fix for next release. + +One vendor has problems importing ics with Timezone id does not reference the Olson path. + +One vendor was busy with CalDAV and roundtable, so we couldn't do much interops in between. + +Another thing that we've run into in the Interop is that it's not entirely clear from at least cursory +readings whether RRULEs are permitted to be in Zulu time. + +Events were created and modified with attendees not in one vendor's calendar server, using +`mailto:`. One vendor's calendar server sent iTip messages to the attendees. + +Similarly users on other calendar servers invited another vendor's calendar server Users or published +events to the calendar server users by sending e-mail and iCal data. The data received was imported. +After importing the requested events, replies to events were sent from the Calendar Server via iTip +messages to the organizer in appropriate cases. + +The main problem area for us was detected to be timezone and recurrence related. All other +implemented feature testing went fine. We do not send `VTIMEZONE` information or timezone tags in +a form specified by the standards in our iTip, making it hard for the consumers to interpret our ``RRULE``s or +``RECURRENCEID``s right. + +Similarly we do not parse the timezone information provided in iTips we receive right, making +consumption of others' iTips correctly, hard. We do not do a proper union of ``RDATE``s and the dates got +by expansion of `RRULE` resulting in multiple instances of really the same instance at times. + +We do not interpret the iTip methods during import which results in attendee copy overwriting the +organizer copy on an import. + +We do not send extra ``RDATE``s if any when sending out iTip. That is, we send only the `RRULE`. + +=== Participant General Comments + +The following are various notes and reports from the participants. The wording has been changed to +remove identification of products where possible. + +This was my first interop (of any kind), so I wasn't quite sure what to expect. What I found was a +pretty intense combination of testing, debugging and writing code. It was definitely good to fire off +questions at server authors, and, if something turned out to be a problem on their side, be able to +proceed after they had fixed it. + +It was also clear that several vendors were arriving with pretty recent implementations of some +CalDAV features, so it was good to feel that we were all helping one another shake out some of the +corner cases. + +One client started out being a pure WebDAV client, and CalDAV support is being added afterward. As +a result, we worked better against servers that are WebDAV-oriented. Testing against the more +calendar-based servers turned up useful bugs. + +This interop was a very interesting experience and the additional participants helped in finding more +interoperability problems. + +The experience was again very valuable but at times it was difficult to tell what was going on. I think +the arrangement for next time will address a lot of that. Ensuring everyone can devote a stretch of time +without being dragged out will help. I don't know if we can timetable tests or encourage people to be +clearer about which server they are testing against. By it's very nature it's somewhat intensive and +that's a large part of its value but if more vendors take part it might become a little uncontrolled. + +I think encouraging server developers to make the server available ahead of time - say for the week +preceding - and encouraging the client people to run through the tests - would weed out some of the +simpler bugs. It might also bring to mind some topics for discussion ahead of time. + +One vendor was able to test its CalDAV desktop client, web client and server with other servers and +clients at the interop. Overall we found interoperability to be good. In a couple of situations there were +areas where servers had not yet implemented functionality, but in several cases they were able to make +modifications and get those working during the interop. Other minor issues were fixed during the +course of the interop. + +=== Summary + +This was the largest interop event we've had testing calendar specifications. Several vendors got an +excellent opportunity to see how their products worked with other applications. The more we can test, +the more we can find, fix, enhance, and simplify. One of the products from this event will be the RFC +matrix which we will provide to the CALSIFY working group at the IETF. It shows what components +are supported and not supported by three vendors today. This should prove helpful in their mission to +come up with RFC's that will better interoperate. + +In addition, based on comments made by attendees and the manager's analysis of what transpired, we +will make modifications to how we handle the interop testing itself. As we add more participants, we +will have to make the interop a bit more structured in order to ensure we test each and every product +implementation. Pre-defining user-ids prior to the interop this time helped. We will need to ensure +that server implementations can be accessed prior to the interop as well. This may pose a problem to +those who bring servers with them to interops, but we'll work around those situations on a company by +company basis. + +More vendors at this interop also meant more extensive testing of CALDAV. Most vendors are still in +the development stages, but the number of vendors supporting CALDAV is growing, so we expect the +number of attendees at future interops to increase. In summary, it was a good event. + +Respectively submitted, + +Patricia Egen + +Interop Manager diff --git a/sources/cc-0507-caldav-use-cases/document.adoc b/sources/cc-0507-caldav-use-cases/document.adoc new file mode 100644 index 0000000..0a19936 --- /dev/null +++ b/sources/cc-0507-caldav-use-cases/document.adoc @@ -0,0 +1,523 @@ += CalDav Use Cases +:docnumber: 0507 +:copyright-year: 2005 +:language: en +:doctype: specification +:edition: 1 +:status: published +:revdate: 2005-09-26 +:published-date: 2005-09-26 +:technical-committee: CALDAV +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Bernard Desruisseaux +:affiliation: Oracle +:role: editor + +.Foreword + +This document is one in a series of use case documents that the Calendaring and +Scheduling Consortium is developing to help better define the needs of different +calendaring and scheduling user groups. As such, this document provides a list of use +cases for a calendar access protocol only. Other use case documents will cover +different areas of calendaring and scheduling, and will be made available by the +Consortium in the usual manner. + +While this list of use cases was developed to assist in the development of the CalDAV +protocol, none of the use cases are specific to CalDAV, that is, this list of use +cases should apply to any calendar access protocol. It is expected that this document +will be used as a basis to further develop technical requirements for a calendar +access protocol such as CalDAV. + +== Introduction + +This document provides a list of use cases that the members of the Calendaring and +Scheduling Consortium believe should be covered by a calendar access protocol. While +this list of use cases was developed to assist in the development of the CalDAV +protocol, none of the use cases are specific to CalDAV, that is, this list of use +cases should apply to any calendar access protocol. It is expected that this document +will be used as a basis to further develop technical requirements for a calendar +access protocol such as CalDAV. + +All the use cases involves any of the following _actors_: + +* *Attendee*: a user who is invited to a given calendar object; +* *Organizer*: a user that act as the organizer of a given calendar object. +* *User*: a user accessing or managing a calendar store; + +Unless stated otherwise, the actor in any use case could also be a user authorized to work on behalf of the actor specified in each use case. + +NOTE: The use cases only covers functionality related to events and tasks, that is, there are no use cases related to journal entries. + +[heading=terms and definitions] +== Terminology + +=== Access Control List + +Set of all privileges granted or denied to any "security principal" on a given "calendar" or "calendar object"; + +=== Calendar + +Container of "calendar objects"; + +=== Calendar object + +Resource defining calendar components such as events and tasks; + +=== Security principal + +An actor or a group of actors that initiates calendar operations. Security principals may either be: (a) authenticated users, (b) unauthenticated users, (c) specific users, or (d) specific groups of security principals. + +== Calendar Access + +=== Create calendar object + +==== {blank} +A user wants to create a new event/task in a given calendar. + +==== {blank} +A user wants to mark a period of time as busy in a given calendar. + +=== Modify calendar object + +==== {blank} +A user wants to create/delete one or multiple instances of an existing calendar object. + +==== {blank} +A user wants to add/modify/delete information (e.g., summary, location, start time, +status, access classification, list of attendees, participation status, attachment, +etc.) for one or multiple instances of an existing calendar object. + +==== {blank} +A user wants to create/delete an alarm for one or multiple instances of an existing +calendar object. + +==== {blank} +A user wants to modify the information (e.g., reminder lead time, etc.) of the alarms +of one or multiple instances of an existing calendar object. + +==== {blank} +A user wants to create/modify/delete an alarm on a calendar object, on which he has +at least read access, in a way that the alarm will only apply to him, will only be +visible to him and can only be modified or deleted by him (or deleted by the system +if the associated calendar object has been deleted). + +==== {blank} +A user wants to mark a calendar object, on which he has at least read access, to +specify that it should impact his free busy time info. + +=== Delete calendar object + +==== {blank} +A user wants to mark for deletion one or multiple instances of an existing event/task +in a way that the information for the marked instances will be preserved. + +==== {blank} +A user wants to unmark one or multiple instances of an existing event/task that are +marked for deletion. + +==== {blank} +A user wants to delete a calendar object. + +==== {blank} +A user wants to delete one or multiple calendar objects based on search criteria +(e.g., all events that occurred more than six months ago). + +==== {blank} +A user wants to delete (permanently remove) all the calendar objects marked for +deletion in his calendar. + +=== Query calendar object + +==== {blank} +A user wants to find all the events or tasks in a given calendar. + +==== {blank} +A user wants to find all the events in a given calendar that have an instance +scheduled to overlap a given time period (e.g., a day, a week, a month, etc.). + +==== {blank} +A user wants to find all the tasks in a given calendar that have an instance with a +start date or due date included in a given time period (e.g., a day, a week, a month, +etc.). + +==== {blank} +A user wants to find all the tasks in a given calendar that have a pasted due date +and that are not completed. + +==== {blank} +A user wants to find all the events/tasks in a given calendar that have an instance +with an alarm scheduled to trigger during a given time period (e.g., later today). + +==== {blank} +A user wants to find all the events in a given calendar for which a particular user +is the organizer. + +==== {blank} +A user wants to find all the events in a given calendar for which he needs to respond +to confirm his participation status. + +==== {blank} +A user wants to find all the events in a given calendar for which a specific user was +an attendee. + +==== {blank} +A user wants to find all the events in a given calendar for which there are attendees +that have not yet confirmed their participation status. + +==== {blank} +A user wants to find all the events in a given calendar for which the summary or +description or location contains a given sub-string (e.g., "Project ABC"). + +==== {blank} +A user wants to find all the events/tasks in a given calendar that have a specific +category. + +=== Synchronization + +==== {blank} +A user wants to synchronize in an efficient matter the calendar objects in the cache +of his calendar client application with the calendar objects currently stored in his +calendar on the calendar server. + +==== {blank} +A user wants to synchronize in an efficient matter the calendar objects, scheduled to +overlap a given time period, in the cache of his calendar client application with the +calendar objects currently stored in his calendar on the calendar server. + +=== Import/Export + +==== {blank} +A user wants to import an entire calendar, or series of calendars, from another system. + +==== {blank} +A user wants to export an entire calendar, or series of calendars, to another system. + + +==== {blank} +A user wants to export calendar objects that meet a certain set of restrictions +(e.g., calendar objects with the category "Business") from a calendar to another +system. + +== Calendar Management + +=== Create calendar + +==== {blank} +A user wants to create a calendar. + +=== Modify calendar + +==== {blank} +A user wants to rename a calendar. + +==== {blank} +A user wants to modify the description of a calendar. + +=== Delete calendar + +==== {blank} +A user wants to delete a calendar. + +=== Find calendar + +==== {blank} +A user would like to find the calendars of other users that may be visible to him. + +==== {blank} +A user would like to find the calendars, of a given user, that may be visible to him. + +=== Copy and Move calendar + +==== {blank} +A user would like to copy / move an entire calendar in a different location in a hierarchy. + +=== Copy and Move calendar objects between calendar + +==== {blank} +A user wants to copy / move one or more calendar objects from one calendar to another +calendar. + +== Scheduling + +=== Event and Task + +==== {blank} +A user wants to submit an event / task announcement to one or more users. + +==== {blank} +An organizer wants to invite one or multiple users to an event. + +==== {blank} +An organizer wants to assign a task to one or more users. + +==== {blank} +An attendee wants to respond to an event invitation / task assignment. + +==== {blank} +An organizer wants to reschedule an existing event / task. + +==== {blank} +An attendee of an existing event / task wants to request an updated description of +the event / task from the organizer. + +==== {blank} +An organizer wants to respond to the request of an attendee to get an updated +description of an event / task. + +==== {blank} +An organizer wants to change the organizer for an existing event / task. + +==== {blank} +An organizer wants to update the status of attendees of an existing event / task, +without rescheduling it. + +==== {blank} +An organizer wants to update the details of an existing event / task, without +rescheduling it. + +==== {blank} +An organizer wants to reconfirm an existing event / task, without rescheduling it. + +==== {blank} +An organizer wants to request an updated status from one or more attendees of an +event / task. + +==== {blank} +A user wants to delegate / re-assign an existing event / task to another user. + +==== {blank} +A user wants to respond to an event / task delegation request. + +==== {blank} +A user wants to forward an event / task to another uninvited user. + +==== {blank} +An organizer wants to add one or more instances to an existing event / task. + +==== {blank} +An organizer wants to send a cancellation notice for one or more instances of an +existing event / task. + +==== {blank} +An attendee of an existing event / task wants to send a counter proposal to the event +/ task description (e.g., different start time) to the organizer. + +==== {blank} +An organizer of an existing event / task wants to reject a counter proposal submitted +by an attendee. + +=== Free/Busy + +==== {blank} +A user wants to send busy time data to one or more users. + +==== {blank} +A user wants to ask one or more users their busy time information (for a specific +date and time interval or not). + +==== {blank} +A user wants to respond to a busy time request of another user. + +== Access Control + +=== Access control for calendars + +==== {blank} +A user wants to grant/deny to security principals the right to +create/read/modify/delete calendars on his behalf. + +EDITOR: read and modify operations on calendars are limited to attributes of the +calendars themselves such as their name, description, creation date, etc. + +==== {blank} +A user wants to know which security principals are granted/denied the right to +create/read/modify/delete calendars on his behalf. + +==== {blank} +A user wants to know whether he is granted/denied the right to +create/read/modify/delete a given calendar. + +==== {blank} +A user wants to know whether a given user is granted/denied the right to +create/read/modify/delete one of his calendar. + +==== {blank} +A user wants to grant/deny to security principals the right to read/modify the +access control lists of his calendars. + +==== {blank} +A user wants to know which security principals are granted/denied the right to +read/modify the access control lists of his calendars. + +==== {blank} +A user wants to know whether he is granted/denied the right to read/modify the access +control list of a given calendar. + +==== {blank} +A user wants to know the set of privileges that applies to him on a given calendar. + +=== Access control for calendar objects + +==== {blank} +A user wants to grant/deny to security principals the right to create new events / +tasks that meets a certain set of restrictions (e.g., events / tasks that are +classified as confidential) in his calendar. + +==== {blank} +A user wants to know which security principals are granted/denied the right to create +new events / tasks that meet a certain set of restrictions (e.g., events / tasks that +are classified as confidential) in his calendar. + +==== {blank} +A user wants to know whether he is granted/denied the right to create new events / +tasks that meet a certain set of restrictions (e.g., events / tasks that are +classified as confidential) in a given calendar. + +==== {blank} +A user wants to know whether a given user is granted/denied the right to create new +events / tasks that meet a certain set of restrictions (e.g., events / tasks that are +classified as confidential) in a given calendar. + +==== {blank} +A user wants to grant/deny to the right to read/modify/delete a subset (or all) of +his events / tasks (e.g., events / tasks classified as private) in his calendar. + +==== {blank} +A user wants to know which security principals are granted/denied the right to +read/modify/delete a subset (or all) of his events / tasks (e.g., events / tasks +classified as private) in his calendar. + +==== {blank} +A user wants to know whether he is granted/denied the right to read/modify/delete a +subset (or all) of his events / tasks (e.g., events / tasks classified as private) in +a given calendar. + +==== {blank} +A user wants to know whether a given user is granted/denied the right to +read/modify/delete a subset (or all) of his events / tasks (e.g., events / tasks +classified as private) in a given calendar. + +==== {blank} +A user wants to grant/deny to security principals the right to obtain free/busy +information derived from a specific subset (or all) of the events (e.g., events +classified as public) in a given calendar. + +==== {blank} +A user wants to know which security principals are granted/denied the right to obtain +free/busy information derived from a specific subset (or all) of the events (e.g., +events classified as public) in a given calendar. + +==== {blank} +A user wants to know whether he is granted/denied the right to obtain free/busy +information derived from a specific subset (or all) of the events (e.g., events +classified as public) in a given calendar. + +==== {blank} +A user wants to know whether a given user is granted/denied the right to obtain +free/busy information derived from a specific subset (or all) of the events (e.g., +events classified as public) in a given calendar. + +==== {blank} +A user wants to know the set of privileges that applies to him on a given event or +tasks in a given calendar. + +==== {blank} +A user wants to grant/deny to security principals the right to read/modify the access +control lists of a subset (or all) of his events / tasks (e.g., events / tasks +classified as private) in a given calendar. + +==== {blank} +A user wants to know which security principals are granted/denied the right to +read/modify the access control lists of a subset (or all) of his events / tasks +(e.g., events / tasks classified as private) in a given calendar. + +==== {blank} +A user wants to know whether he is granted/denied the right to read/modify the access +control lists of a subset (or all) of events / tasks (e.g., events / tasks classified +as private) in a given calendar. + +==== {blank} +A user wants to know whether a given user is granted/denied the right to read/modify +the access control lists of a subset (or all) of events / tasks (e.g., events / tasks +classified as private) in a given calendar. + +=== Scheduling Access Control + +==== {blank} +A user wants to grant/deny to security principals the right to invite him to events. + +==== {blank} +A user wants to know which security principals are granted/denied the right to invite +him to events. + +==== {blank} +A user wants to know whether he is granted/denied the right to invite a given user to +events. + +==== {blank} +A user wants to grant/deny to security principals the right to assign him tasks. + +==== {blank} +A user wants to know which security principals are granted/denied the right to assign +him tasks. + +==== {blank} +A user wants to know whether he is granted/denied the right to assign tasks to a +given user. + +==== {blank} +A user wants to grant/deny to security principals the right to reply to events / +tasks that meet a certain set of restrictions (e.g., events / tasks that are +classified as confidential) on his behalf. + +==== {blank} +A user wants to know which security principals are granted/denied the right to reply +to events / tasks that meet a certain set of restrictions (e.g., events / tasks that +are classified as confidential) on his behalf. + +==== {blank} +A user wants to know whether he is granted/denied the right to reply to events / +tasks that meet a certain set of restrictions (e.g., events / tasks that are +classified as confidential) on behalf of a given user. + +==== {blank} +A user wants to grant/deny to security principals the right to send event invitations +that meet a certain set of restrictions (e.g., events that are classified as +confidential) on his behalf. + +==== {blank} +A user wants to know which security principals are granted/denied the right to send +event invitations that meet a certain set of restrictions (e.g., events that are +classified as confidential) on his behalf. + +==== {blank} +A user wants to know whether he is granted/denied the right to send event invitations +that meet a certain set of restrictions (e.g., events that are classified as +confidential) on behalf of a given user. + +==== {blank} +A user wants to know whether a given user is granted/denied the right to send event +invitations that meet a certain set of restrictions (e.g., events that are classified +as confidential) on his behalf. + +==== {blank} +A user wants to grant/deny to security principals the right to assign tasks that meet +a certain set of restrictions (e.g., tasks that are classified as private) to other +users on his behalf. + +==== {blank} +A user wants to know which security principals are granted/denied the right to assign +tasks that meet a certain set of restrictions (e.g., tasks that are classified as +private) to other users on his behalf. + +==== {blank} +A user wants to know whether he is granted/denied the right to assign tasks that meet +a certain set of restrictions (e.g., tasks that are classified as private) to other +users on behalf of a given user. + +==== {blank} +A user wants to know whether a given user is granted/denied the right to assign tasks +that meet a certain set of restrictions (e.g., tasks that are classified as private) +to other users on his behalf. diff --git a/sources/cc-0508-pres-overview/document.adoc b/sources/cc-0508-pres-overview/document.adoc new file mode 100644 index 0000000..0a24faf --- /dev/null +++ b/sources/cc-0508-pres-overview/document.adoc @@ -0,0 +1,370 @@ += Overview of The Calendaring and Scheduling Consortium +:docnumber: 0508 +:copyright-year: 2005 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2005-10-11 +:published-date: 2005-10-11 +:technical-committee: CALCONNECT +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:imagesdir: images + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks +and Disclaimer of Warranty for External (Public) Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +Permission is granted to existing and potential members of the Consortium to reproduce and distribute this +presentation within their organizations so long as the presentation is not altered in any way and the Consortium +is acknowledged as the originator. + +== What is CalConnect? + +. A Partnership +** Between Calendaring & Scheduling Vendors and Customers + +. Mission +** To provide a general understanding of, promote, and provide mechanisms so that +Calendaring and Scheduling methodologies, tools and applications +can enter the mainstream of computing + +. Not a standards development organization +** Promotes development and adoption of standards +** Influence SDOs and vendors + +== Why a Consortium? + +A focused environment to + +* Re-energize Calendaring and Scheduling +* Provide a forum to discuss the direction for +standards and implementations +* Validate the existing standards +* Provide interoperability testing +* Drive requirements for changes to existing +standards, new and complementary standards +back into IETF, other bodies +* Promote standards and technologies to the vendor +and user communities + +== How did it evolve? + +[%unnumbered] +image::img01.png[] + +== Goals of the Consortium + +* Promote Calendaring & Scheduling +* Help drive the evolution of open standards +for Calendaring & Scheduling (iCalendar, +iMIP, iTIP, CalDAV) +* Conduct interoperability testing +* Collegial partnership between all members +to achieve Consortium mission and goals +* Develop a shared vision for the Calendaring +& Scheduling community + +== Goals and Activities of the Consortium + +. Promote Calendaring & Scheduling +** Press releases +** Media publications +** Trade shows +** Op ed pieces, articles and white papers +** Trade shows and speaking opportunities +** Regular Roundtables for members + +. Interoperability testing and certification +** Periodic interoperability testing events +** Promotional events and publicity to announce +successful completion of testing +** Analyze results and report findings to IETF or +other relevant standards bodies on correctness +and completeness of standards +** Develop and implement independent test suites +for interoperability conformance tests +** Potential to eventually certify applications for +interoperability and conformance to Calendaring +& Scheduling standards + +. Promote design and deployment of +standards and implementations +** Feedback on existing standards on correctness +and completeness +** Requirements assessment and development for +extensions to existing standards or new, +complementary standards +** Study and report needs of user community at +large for standards and products + +. Promote collaboration among members +** Promote inter-member collaboration to improve +interoperability +** Promote inter-member collaboration on +instruction and training +** Support inter-member efforts to define new +areas for Calendaring and Scheduling + +. Support common goals of members +** Member forum to establish and promote common +goals for Calendaring and Scheduling products +** Establish common messages of member +community as basis for promotional materials and +publicity on Calendaring and Scheduling +** Possible annual conference + +. Develop a shared vision for the Calendaring +and Scheduling community +** Seek broad representation from vendors, academia, +customers and the open source community +** Sponsor roundtable discussions, online forums + +== Events + +. Interops (Interoperability Testing) +** Participation open to members and non-members (significant discount +for members) +** Two day event usually co-located with Roundtable +** Results published to relevant standards org +** Public version on Consortium website + +. Roundtables +** "All hands" plenary meeting of membership +** Three per year midway between IETF meetings +*** help to drive each other +** Held in conjunction with Interops +** Technical committee working meetings +** Steering Committee meeting +** Review and status of technical committees +** Consensus on direction, next steps of Consortium + +. Workshops +** First workshop tentatively planed for 1Q2006 +** Public workshop or invitational depending on goal & topic +** Open to non-Consortium members +** Could be co-hosted with Roundtable or independent event + +. Annual Conference +** Need is still under evaluation +** Would offer technology and product overviews, tutorials and classes, +demonstrations and vendor offerings +** Public conference with member discounts +** Could be co-hosted or co-located with another organization or +outsourced to a providing organization + +== Organizational Structure + +[%unnumbered] +image::img02.png[] + +== Steering Committee + +. Membership +** Initially, Founding Members of the Consortium +** Will expand to include at least one of each membership +category + +. Operations +** Monthly teleconference +** Meetings at Roundtables or other activities if needed +Governance +** Chair chosen by Steering Committee members +** Chair participates in Board of Directors meetings + +. Activities +** Overall technical direction +** Management of Technical Committees +** Consortium program elements +** Advice to the Board of Directors + +== Technical Committees + +. Membership +** Individual TC members provided by Member Organizations +. Operations +** Determined by TC Chair and TC membership +** TC Chair provides regular status to Steering Committee +. Governance +** Any Consortium member may propose new work +** Charter, scope and deliverables identified in the proposal +** Chair confirmed by SC +** Committee terminates when chartered work is complete +. Operational policies +** In-progress work confidential to Consortium members only +** Completed work published and freely available on +Consortium web site +** No proprietary information discussed + +=== AUTHENTICATE + +Identify & recommend +authentication and +authorization solutions +for Calendaring data +exchange + +=== CalDAV + +Define problems +CalConnect wishes to +solve with extensions to +WebDAV; assist IETF +with development of +CalDAV Specification + +=== EVENTPUB + +Define event publishing +& establish differences +from regular +calendaring and +scheduling + +=== IOPTEST + +Support interoperability +testing for all technical +committees, develop +test suites & reference +implementation, publish +interop results + +=== MOBILE + +Define issues for mobile +support of standards-based +Calendaring and +recommend extensions +to standards for mobile +support + +=== REALTIME + +Clarify issues involved +with real-time server-to-server +calendaring and +scheduling issues & +provide +recommendations + +=== RECURR + +Review problems in +current alternative +approaches towards +handling recurrences & +recommend a preferred +approach or guidelines + +=== TIMEZONE + +Identify requirements for +& a strategy to establish a +global timezone reference +available to CalDAV & +other calendaring and +scheduling server +implementations + +=== USECASE + +Develop sets of real +world use cases that +can be used to validate +identified functionality & +testing scenarios for +existing & future C&S +implementations + +== Intellectual Property Rights + +. Consortium policy +** Members will not introduce or share proprietary or +encumbered information in the course of +participating in consortium activities +. Resolution of ambiguous situations +** Reasonable compliance with IETF policy on IPR +*** "Section 10" of IETF RFC2026, Internet Standards Process +*** http://www.ietf.org/IESG/Section10.txt + +== Membership + +. Eligibility +** Any company, institution or individual who +*** supports the goals of the Consortium +*** agrees to abide by its rules +*** submits the proper membership application +*** pays the appropriate membership fee +. Fees +** Published on the Consortium web site +** Based on membership category +** Due annually upon anniversary of joining the +Consortium +. Categories +** Commercial Vendor +*** >$100 million annual revenue +*** $10-100 million annual revenue +*** >$10 million annual revenue +** Customer Organizations/Companies +** Non-Profit Organizations +** Open Source Organizations +** Academic Institutions +** Standards Setting Organizations +** Individuals +. Benefits +** Voice in achieving Consortium objectives +*** Propose new work +*** Engage in one or more Technical Committees +*** Influence direction of TCs and Steering Committee +*** Participate in technical governance +** Recognition and publicity +*** Listing on Consortium web site +*** Opportunity for recognition in Consortium PR initiatives +** Reduced rate for Interop events +** Opportunity to host Roundtable or Interop events +** Help create true interoperable Calendaring & +Scheduling + +=== Founding Members + +[%unnumbered] +image::img03.png[] + +=== Recent Members + +* Carnegie Mellon +* Dartmouth +* Rensselaer Polytechnic +* CSU Fresno +* IBM +* Trumba +* 2 Individual Members + +== Status + +[%unnumbered] +image::img04.png[] + +== More Info; How to Get Involved + +. Website: http://www.calconnect.org +. Contact us: info@calconnect.org +. Attend the next Roundtable as an observer: January 10-12, Provo, Utah +. For more information: ++ +-- +Dave Thewlis, Executive Director + +The Calendaring and Scheduling Consortium + +4390 Chaffin Lane + +McKinleyville, CA 95519-8028 + +Voice: +1 707 840 9391 + +FAX: +1 415 946 3454 + +Mobile: +1 707 498 2238 + +Email: Dave.Thewlis@calconnect.org +-- diff --git a/sources/cc-0508-pres-overview/images/img01.png b/sources/cc-0508-pres-overview/images/img01.png new file mode 100644 index 0000000..24a7c6b Binary files /dev/null and b/sources/cc-0508-pres-overview/images/img01.png differ diff --git a/sources/cc-0508-pres-overview/images/img02.png b/sources/cc-0508-pres-overview/images/img02.png new file mode 100644 index 0000000..3126984 Binary files /dev/null and b/sources/cc-0508-pres-overview/images/img02.png differ diff --git a/sources/cc-0508-pres-overview/images/img03.png b/sources/cc-0508-pres-overview/images/img03.png new file mode 100644 index 0000000..7a402e2 Binary files /dev/null and b/sources/cc-0508-pres-overview/images/img03.png differ diff --git a/sources/cc-0508-pres-overview/images/img04.png b/sources/cc-0508-pres-overview/images/img04.png new file mode 100644 index 0000000..0f5b289 Binary files /dev/null and b/sources/cc-0508-pres-overview/images/img04.png differ diff --git a/sources/cc-0509-pres-overview/document.adoc b/sources/cc-0509-pres-overview/document.adoc new file mode 100644 index 0000000..7f86c06 --- /dev/null +++ b/sources/cc-0509-pres-overview/document.adoc @@ -0,0 +1,143 @@ += EDUCAUSE 2005 Overview of The Calendaring and Scheduling Consortium +:docnumber: 0509 +:copyright-year: 2005 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2005-10-11 +:published-date: 2005-10-11 +:technical-committee: CALCONNECT +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks +and Disclaimer of Warranty for External (Public) Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Goals of the Consortium + +. Promote Calendaring & Scheduling via a +partnership between Vendors and +Customers +. Help drive the evolution of open standards +for Calendaring & Scheduling (iCalendar, +iMIP, iTIP, CalDAV) +. Conduct interoperability testing +. Develop a shared vision for the Calendaring +& Scheduling community + +== Academic Members + +* Carnegie Mellon University +* California State University Fresno +* Dartmouth College +* Duke University +* Harvard ASCS +* Massachusetts Institute of Technology +* NASA Jet Propulsion Laboratory (Cal Tech) +* Rensselaer Polytechnic Institute +* Stanford University +* University of California Berkeley +* University of Washington +* University of Wisconsin + +== Vendors and Open Source Implementers + +* EVDB +* IBM +* Meeting Maker +* Mozilla Foundation +* Novell +* Open Source Applications Foundation +* Oracle +* Symbian +* Trumba +* Yahoo! + +If your vendor isn't listed here, ask them why! + +== Technical Committees + +=== AUTHENTICATE + +Better HTTP +authentication +in CalDAV. + +=== CalDAV + +Calendar access +use cases and +problems. + +=== EVENTPUB + +Event +publishing. + +=== IOPTEST + +Interoperability +testing & +reporting. +Test suites. + +=== MOBILE + +Issues for +mobile devices. + +=== REALTIME + +Calendaring +across +organizational +boundaries. + +=== RECURR + +Handling of +recurrences. + +=== TIMEZONE + +Issues with +timezone +support. Define +timezone +registry. + +=== USECASE + +Real world use +cases to be +solved. + +== Events + +. Interops (Interoperability Testing) +** Participation open to members and non-members +(significant discount for members) +** Two day event usually co-located with Roundtable +** Results published to relevant standards org +** Public version on Consortium website +. Roundtables +** Three per year midway between IETF meetings +** Held in conjunction with Interops +** Technical committee working meetings +** Review and status of technical committees +** "All hands" plenary meeting of membership +** Consensus on direction, next steps of Consortium + +== How to Get Involved + +. Website: http://www.calconnect.org +. Contact us: info@calconnect.org +. Attend the next Roundtable as an observer: January 10-12, Provo, Utah +. Flyers with more information and business cards available at the front +. This presentation: http://www.calconnect.org/presentations/educause2005.ppt diff --git a/sources/cc-0510-questionnaire-results-timezone/document.adoc b/sources/cc-0510-questionnaire-results-timezone/document.adoc new file mode 100644 index 0000000..7d93ee4 --- /dev/null +++ b/sources/cc-0510-questionnaire-results-timezone/document.adoc @@ -0,0 +1,374 @@ += Report on TIMEZONE Questionnaire Results +:docnumber: 0510 +:copyright-year: 2005 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2005-10-03 +:published-date: 2005-10-03 +:technical-committee: TIMEZONE +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Cyrus Daboo +:role: editor + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +This document is one in a series of documents summarizing the +results of questionnaires that the Calendaring and Scheduling +Consortium has conducted to help better understand the +requirements, problems and needs for calendaring and +scheduling solutions. It is expected that the results of these +questionnaires will be used to help define requirements and +recommendations for calendaring & scheduling products. + +This particular document summarizes the results of the +Timezone Technical Committee's questionnaire on Timezone +support in iCalendar products. Other questionnaire summary +documents will cover different areas of calendaring and +scheduling, and will be made available by the Consortium. + +== Report on Timezone Questionnaire Results + +=== Introduction + +The Timezone Technical Committee of the Calendaring & Scheduling +Consortium (http://www.calconnect.org) developed a questionnaire about +timezone usage in iCalendar products. The goal of this questionnaire was to +determine how and to what extent timezones are being used, with a view to +using those results to aid in the development of recommendations on how to +improve timezone support in iCalendar. + +A number of responses were received, and summary and conclusions drawn +from these results. This document presents a summary of the results and brief +conclusions based on those results. + +Whilst each vendor submitted their own results, the summary presented here is +an aggregate of those results, and has any information that could identify +vendors removed. + +=== Summary of individual responses + +A total of 19 responses were received from a total of 17 vendors over a period of +about 1 month. The products covered by these responses include clients (both +desktop and web-based), servers and libraries (which are used by different +clients and servers). Both commercial and open source vendors are represented. +Many responses were based on currently shipping products, and some were +based on products currently under development. + +Of these products, a total of 7 did not implement timezone support at all, either +because it was not relevant (e.g. timezone was left as a presentation issue for +clients) or because the feature had not currently been implemented, but plans +were in place to eventually do so. + +=== Results + +The results of the questionnaire are tabulated below. + +A number of questions required a "yes", "no", "other" response. Products that +did not support timezones at all (answered "no" to all such questions) were +moved into the "other" column. The percentage totals were calculated from the +number of "yes" answers compared to the total of "yes" and "no" answers. The +"other" value was excluded from the percentage. In other words, the percentage +represents the amount of support for timezones by those who have made some +attempt to support it. + +Descriptive answers and comments in the table below are summaries of each +result received. + +[%landscape] +<<< + +==== Questionnaire Results (Questions 1 -- 4) + +[%unnumbered,options=header,headerrows=2,cols=10] +|=== +.2+| Question .2+| Description 8+| Answers +| 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%* +| 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%* +|=== + +[%portrait] +<<< + +==== Questionnaire Results (Questions 5 onwards) + +[%unnumbered,options=header,cols=6] +|=== +| 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%* +| 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 ``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". | +| 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). | +| 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' ``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 + +RFCs tend to describe the expected behaviour, but leave the implementations up to +the authors. This is understandable, but when all the developers have to reinvent the +processing algorithms you get flaky results. I notice that the experience with TCP and +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 +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 +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 +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 +fairly complete, with most vendors both consuming and producing such +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 +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. + +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 +Olsen timezone database, timezone information built into OS's (e.g. Windows), +those provided with other environments (Java). The naming of these components +usually followed the scheme of the original data source. In one case a private +namespace was used for timezone names. + +Only 1/3 of products provide a way to update the built-in timezone via some +automated process. + +Only 1/4 of products were able to adjust future events, tasks etc when a +timezone definition changed. + +About 2/3 products would take in timezone definitions from outside sources. A +number of products would attempt to match an "external" definition to the builtin +ones and substitute any matching built-in definition in place of the "external" +one. + +==== Timezone Registry + +About 2/3 of respondents said they would use a standard timezone registry if +one were available. However, given the wide variety of timezone naming +schemes for built-in timezones, its not clear how long it would take for products +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. + +==== Future Work + +The Timezone Technical Committee is using the results of this questionnaire to +formulate its recommendations document that will be made available by the +Consortium. + +[appendix] +== The questionnaire as sent via email + +Questionnaire on Timezones in iCalendar + + +=== Introduction + +This questionnaire is being used to determine support for iCalendar +(RFC2445) timezone support. The specific sections in RFC2445 that +are being queried are: + +* 4.6.5 Time Zone Component +* 4.8.2.4 Date/Time Start +* 4.8.3 Time Zone Component Properties + +( and sub-sections ) +* 4.8.5.3 Recurrence Date/Times +* 4.8.5.4 Recurrence Rule +* 4.8.7.3 Last Modified +* 4.8.8.1 Non-standard Properties + +These may involve reference to other sections. + +=== How to answer + +Please copy the text from the '-------' divider below to the end of +this message into a new message and address it to: + +questionnaire@calconnect.org + +=== To fill it out + +For 'y/n/o': + +* 'y' means yes +* 'n' means no +* 'o' means other or not applicable + +Delete two letters to leave the one for your answer. + +If you have specific comments you can add about your answers, +please do so at the end and reference the question number to which +the comment applies. + +For \______\______\_________: enter text for the answer. + +=== Product Details + +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 +|=== + +.Properties supported +|=== +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` +| | 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` +| | 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 +|=== + +=== General + +[pseudocode%unnumbered] +==== +Q5: Do you always send DATE-TIME values with a timezone? y/n/o + +Q6: Do you always send DATE-TIME values in UTC or floating? y/n/o + +Q7: Do you provide a standard set of timezones built-in to your product? y/n/o + +if yes to Q7, then +{ + Q8: Where did you get your timezone definitions? + + \______\______\_________ + + Q9: How many timezone definitions do you have? + + \______\______\_________ + + Q10: Do you have a special naming scheme for ``TZID``s, and if so what is it? + + \______\______\_________ + + Q11: Do you provide a mechanism for updating built-in timezones? y/n/o + + if yes to Q11, then + { + Q12: Do you adjust future times to account for timezone definition changes? y/n/o + } +} + +Q13: Do you accept and use timezone definitions from imported iCalendar data? y/n/o + +if yes to Q13, then +{ + 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? + +\______\______\_________ + +Q16: Would you use timezone definitions from a standard timezone registry if one were created? y/n/o + +Q17: What problems would be involved in changing a timezone definition if DST was changed at some point in the future? + +\______\______\_________ + +C1: Comments on specific answers (include Q number for cross-reference to original question): + +\______\______\_________ + +C2: Comments on the format and ease of use of this questionnaire: + +\______\______\_________ + +C3: Are there any additional questions we should be asking, and if so what are they? + +\______\______\_________ +==== diff --git a/sources/cc-0511-report-roundtable-2/document.adoc b/sources/cc-0511-report-roundtable-2/document.adoc new file mode 100644 index 0000000..e2ba7e0 --- /dev/null +++ b/sources/cc-0511-report-roundtable-2/document.adoc @@ -0,0 +1,148 @@ += Report on Roundtable II, 11-13 January 2005 +:docnumber: 0511 +:copyright-year: 2005 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2005-01-13 +:published-date: 2005-01-13 +:technical-committee: CALCONNECT +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Introduction + +The first post-launch event of The Calendaring and Scheduling Consortium took place on 11-13 +January, 2005, sponsored by the University of Washington in Seattle. The event was attended by +31 people representing 16 organizations. The Roundtable event consisted of two days of Technical +Committee meetings, followed by an all-hands plenary meeting of the membership and attendees. +The first two days, a CalConnect Interoperability Event was held in parallel with the Technical +Committee meetings. The Technical Committee sessions were organized sequentially, to allow all +attendees who wished to be involved in the discussions of a Technical Committee the opportunity +to do so, and there was definitely "drift" between TC sessions and those participating in the +CalConnect Interoperability Event. + +== New Initiatives + +*TC-TIMEZONE* was formed as a result of work being done in CalDAV showing the need for a +formal time zone registry; iCAL needs this as well. Some work has been done in the past in this +area; the new Technical Committee will gather the work that has been done and develop a +proposal as to how best to move this forward. + +*TC-EVENTPUB* was formed based on work being done at UC Berkeley and elsewhere to +develop a precise understanding of event publishing and how it differs from general scheduling +problems, with the goal of attracting efforts being done in several academic institutions and +elsewhere to combine into a single work project and Technical Committee within CalConnect. + +*TC-CALSIFY* was re chartered with an expanded scope to support and help drive the CALSIFY +effort in the IETF via a Working Group to consider the potential revision of RFC 2445. + +*Glossary Project*: The work done in the USECASE Technical Committee has shown the need for +a taxonomy document for common vocabulary and glossary for calendaring and scheduling. Ms. +Egan volunteered to act as Project Editor to compile a first draft document for circulation by mid- +February. The Glossary, once complete, will be posted and publicly available on the CalConnect +website. + +*External Communications*: The Consortium has chartered an ad hoc group to develop proposals +for publicity, promotion, and recruitment, e.g. ways of communicating activities in calendaring +and scheduling, such as an RSS Feed for the C&S space, speaking appearances at technical +conferences and trade shows, and an expanded website presence including links to sites offering +calendaring functionality. + +== CalConnect Interoperability Event + +Participants in the CalConnect Interoperability Event included Isamet, Mozilla, Oracle, and the +University of Washington. The major part of the CalConnect Interoperability Event was CalDAV +testing; this was the first formal interoperability testing of CalDAV implementations, and +demonstrated basic interoperability between two CalDAV servers (Isamet, Oracle) and three +clients (Isamet Mulberry Desktop and Mobile Clients and Mozilla). The results of the CalConnect +Interoperability Event should be available by early February and will be posted on the Consortium +website and delivered to the IETF. + +== Technical Committees + +Five Technical Committees met on Tuesday and Wednesday. + +The Min-IOP Technical Committee is working to develop a comprehensive table of which features +of iCAL are actually implemented in which Calendaring products and are able to interoperate +successfully. The goal is to determine the minimum interoperable subset of functions defined by +the three RFCs which are actually in use and which must be succesfully carried forward into any +revision or "simplification" of RFC 2445, iCalendar. The Technical Committee is actively +involved in developing this matrix and determining how well the matrix maps to what the needed +minimum actually is. + +The CALDAV Technical Committee will produce scenarios for additional CalDAV testing for the +next CalConnect Interoperability Event, then turn to assisting CalDAV authors in submitting the +CalDAV draft to the IETF. They expect to use the use cases from the USECASE TC and anticipate +contributing additional use cases. CALDAV is very interested in being able to conduct virtual +Interops on a monthly basis and will work with IOP/TEST and the IOP Manager to accomplish +this under Consortium auspices. The Oracle and Isamet CalDAV servers are available on the +internet for client testing. + +The CALDAV participants were heavily involved in the CalConnect Interoperability Event and +also provided several demonstrations to the Roundtable: + +* Mozilla's Sunbird and Oracle Calendar with CalDAV protocol adapter +* Mozilla's Sunbird and Oracle's Exchange CalDAV protocol adapter +* Isamet Mulberry Desktop Client and Isamet CalDAV server +* Isamet Mulberry Mobile Client and Isamet CalDAV server + +The IOP/TEST Technical Committee is working to develop and formalize the Consortium's +CalConnect Interoperability Event testing. Among the issues being addressed by the Technical +Committee are planning and implementing virtual and ad hoc interops; how to contact nonmembers +about CalConnect Interoperability Event testing; how to establish CalConnect +Interoperability Event planning early on and integrate product planning; and how to conduct +multiple CalConnect Interoperability Event tests together. The Committee is also beginning +discussions on a reference implementations which for ad hoc testing by implementers as a service +from the Consortium to promote calendaring and scheduling standards. + +The RECURR Technical Committee was only able to meet briefly as the Chair was not able to +come to the Roundtable and had to join the TC by teleconference. The problem statement for the +TC was reviewed and narrowed to focus on recurrence rule problems. An additional effort will be +to identify and document the specifics of existing problems with recurrence rules as part of the +MIN-IOP effort. + +The USECASE Technical Committee spent substantial time compiling a set of Use Cases +identifying "real world" requirements for interoperable calendaring and scheduling +implementations. Some 29 specific use cases were documented. The next steps will be to develop +a ranking method and continue to add use cases from other members, and from other Technical +Committees. + +== Future Meetings + +Three regular meetings per year were agreed, roughly in January, May, and September. The +membership is strongly in favor of holding combined 2-1/2 day events featuring a CalConnect +Interoperability Event, Technical Committee meetings, and a membership plenary, after the model +followed at this Roundtable. The Consortium will attempt to alternate meetings between the east +and west coasts. The next meeting (Roundtable III) will take place 1-3 June, 2005, hosted by Duke +University in Durham, North Carolina. The following meeting will be in mid- to late September, +on the west coast. diff --git a/sources/cc-0512-report-roundtable-3/document.adoc b/sources/cc-0512-report-roundtable-3/document.adoc new file mode 100644 index 0000000..ebcbc7c --- /dev/null +++ b/sources/cc-0512-report-roundtable-3/document.adoc @@ -0,0 +1,119 @@ += Report on Roundtable III, 1-3 June 2005 +:docnumber: 0512 +:copyright-year: 2005 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2005-06-03 +:published-date: 2005-06-03 +:technical-committee: CALCONNECT +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Introduction + +The second formal event of The Calendaring and Scheduling Consortium took place on 1-3 June, +2005, hosted by Duke University Durham, North Carolina. The event was attended by +representatives of seventeen Consortium members. The Roundtable event consisted of two days of +Technical Committee meetings, and an all-hands plenary meeting of the membership and +attendees. The first two days, a CalConnect Interoperability Eventt was held in parallel with the +Technical Committee meetings. The Technical Committee sessions were organized sequentially, to +allow all attendees who wished to be involved in the discussions of a Technical Committee the +opportunity to do so, and there was definitely "drift" between TC sessions and those participating +in the CalConnect Interoperability Event. + +== Update on Initiatives + +*Glossary Project*: The Calendaring Glossary should be ready for initial publication on the +Consortium website within the next few weeks; it is currently in Last Call within the Consortium. + +*Recurrence Questionnaire*: The results of the Recurrence Questionnaire conducted by TCRECURR +on the internet will be posted publicly to the Consortium website as soon as the results +document completes Final Call within the Consortium. + +*TC-REALTIME* has been on hold pending the completion of other work, and will begin its work +in mid to late June. + +*TC-MIN-IOP* was disbanded and folded into TC-IOPTEST. + +*External Communications*: The Consortium will be announcing an RSS feed for Calendaring +issues and announcements in the next several weeks. + +*New initiatives*: The Consortium is considering initiating work in three new areas, if there is +sufficient interest among existing and new members and if resources are available to work in these +areas: + +* Calendar user address discovery and calendar server discovery +* Cross domain security and access control +* Todos for project management + +== CalConnect Interoperability Event + +Participants in the CalConnect Interoperability Event included Isamet, Mozilla, Novell, Oracle, +and Rensselaer Politechnic Institute. The CalConnect Interoperability Event was focused on +CalDAV testing and tested three CalDAV servers and four clients with very positive results. The +results of the CalConnect Interoperability Event should be available soon and will be posted on +the Consortium website and delivered to the IETF. + +== Technical Committees + +All CalConnect Technical Committees met during the course of the Roundtable to review their +status and work to date with the entire set of attendees and to progress their work with the large +input from the Roundtable. Of particular note: + +TC-CALDAV has made its CalDAV test script available on the Consortium website (under +"Resources"). + +TC-CALSIFY has been re-chartered more explicitly as a coordination effort between Consortium +Technical Committees and the incipient IETF CALISFY working group. The intent is to feed +information to the working group as rapidly as possible and ensure that TC work being done for +consumption by the working group meets the needs of the WG. + +TC-EVENTPUB is developing a survey on Event Publication, which will be distributed as widely +as possible, and may require some level of publicity to draw attention to it. + +TC-IOPTEST has taken on the tasks associate with the former TC-MIN-IOP to determine the +"minimum interoperability subset" for iCalendar. This is in addition to TC-IOPTEST's charter to +plan for, develop and formalize the Consortium's CalConnect Interoperability Event testing. + +TC-RECURR is planning a second questionnaire to delve more deeply into some specific +recurrence issues identified by the first questionnaire. The Committee intends to have results and +recommendations by the next Consortium Roundtable, and make them available to the IETF +CALSIFY working group before the November IETF meeting. + +TC-TIMEZONE is conducting a questionnaire on Timezone implementations as part + +== Future Meetings + +The next meeting (Roundtable IV) will take place 13-15 September in San Francisco, hosted by +the Open Source Applications Foundation. The following meeting (Roundtable V) will take place +in mid-January in Provo, Utah, hosted by Novell, Inc. diff --git a/sources/cc-0513-report-roundtable-4/document.adoc b/sources/cc-0513-report-roundtable-4/document.adoc new file mode 100644 index 0000000..0187efe --- /dev/null +++ b/sources/cc-0513-report-roundtable-4/document.adoc @@ -0,0 +1,110 @@ += Report on Roundtable IV, 13-15 September 2005 +:docnumber: 0513 +:copyright-year: 2005 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2005-09-15 +:published-date: 2005-09-15 +:technical-committee: CALCONNECT +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Introduction + +Roundtable IV took place on 13-15 September, 2005, hosted by the Open Souce Applications +Foundation in San Francisco, California. The event was attended by 43 representatives from +seventeen Consortium members and four observers. The Roundtable event consisted of two days +of Technical Committee meetings, and an all-hands plenary meeting of the membership and +attendees. The first two days, a CalConnect Interoperability Event was held in parallel with the +Technical Committee meetings. The Technical Committee sessions were organized sequentially, to +allow all attendees who wished to be involved in the discussions of a Technical Committee the +opportunity to do so. + +== Update on Initiatives + +*Published documents*: The Consortium has published the Results of the Recurrence +Questionnaire, the Results of the Timezone Questionnaire, and the CalDAV Use Cases document. +The Min-IOP Use Cases Document, Timezone Recommendations, Timezone Registry/Resource +Recommendations, Calendaring Glossary and others are in preparation. + +*TC-CALSIFY* was disbanded as its function was duplicated by the TC-CHAIRS coordination +committee. + +*TC-REALTIME* will be rechartered and will act as a research TC to look at a variety of serverserver +issues and determine whether specific work needs to be undertaken in the area. + +*TC-AUTHENTICATE* (calendaring authentication and authorization) and *TC-MOBILE* +(calendaring on mobile devices) were chartered at this Roundtable. + +*External Communications*: The Consortium will be announcing an RSS feed for Calendaring +issues and announcements in the next several weeks. + +== CalConnect Interoperability Event + +Participants in the CalConnect Interoperability Event included EVDB, IBM, Isamet, Mozilla, +Novell, Oracle, OSAF, RPI (Rensselaer Polytechnic Institute) and Sun Microsystems. Results +from the CalConnect Interoperability Event are posted at Past CalConnect Interoperability Event +Reports. + +== Technical Committees + +All CalConnect Technical Committees met during the course of the Roundtable to review their +status and work to date with the entire set of attendees and to progress their work with the large +input from the Roundtable. Of particular note: + +TC-CALDAV has made its CalDAV test script available on the Consortium website (under +"Resources"). + +TC-EVENTPUB will complete its survey at the end of September. TC members are investigating +ways to extend iCalendar function in the area of location and are looking at alternatives including +vCard. + +TC-IOPTEST is accumulating a set of specific iCalendar and related test scripts with the plan to +develop them, in addition to other purpose-developed material, into a test suite. + +TC-RECURR intends to have results and recommendations by the next Consortium Roundtable, +and make them available to the IETF CALSIFY working group at the November IETF meeting. + +TC-TIMEZONE has completed its questionnaire on Timezone implementations and is developing +a recommendations document on the results of the questionnaire, and another document on the +subject of a Timezone Registry and a Timezone Resource. + +== Future Meetings + +The next meeting (Roundtable V) will take place 09-12 January, 2006, hosted by Novell in Provo, +Utah. Starting with this meeting, the CalConnect Interoperability Event will be conducted prior to +the beginning of the Roundtable. Specifically the IOP event will begin on on Monday the 9th, and +continue on Tuesday morning the 10th, followed by the Roundtable from Tuesday afternoon +through Thursday afternoon. (Participants found that trying to do both the CalConnect +Interoperability Event and the Roundtable TC sessions in parallel weren't working very well.) The +following meeting (Roundtable VI) will be held in mid-May; a host has not yet been established. diff --git a/sources/cc-0514-dst-adv-notice/document.adoc b/sources/cc-0514-dst-adv-notice/document.adoc new file mode 100644 index 0000000..8fefc4b --- /dev/null +++ b/sources/cc-0514-dst-adv-notice/document.adoc @@ -0,0 +1,207 @@ += DST Advisory Notice +:docnumber: 0514 +:copyright-year: 2005 +:language: en +:doctype: advisory +:edition: 1 +:status: published +:revdate: 2005-06-29 +:published-date: 2005-16-29 +:technical-committee: DST ADHOC +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Introduction + +H.R. 6: Energy Policy Act of 2005, which recently passed the US +House of Representatives, contains an 'energy saving' provision +which may have broad impact on users of existing Calendaring and +Scheduling systems and manufacturers of software that support +calendaring and scheduling functions. This document explains the +impact and our concerns. + +== Energy Bill + +=== What the bill says + +H.R. 6: Energy Policy Act of 2005, which recently passed the US +House of Representatives, contains an 'energy saving' provision +regarding Daylight Savings Time (DST). It calls for a change in start +and end dates of DST observed in the United States, with the new +DST period stretching from March to November. This change would +take effect in March 2006 if the House language prevails over Senate +language, which does not contain the extension. + +=== Our Concerns + +Members of the Calendaring and Scheduling Consortium, +comprising both product vendors and end-user groups, are +concerned about the proposed timing of this change. + +It's not a matter of whether the proposal is right or wrong. It's a +matter of practicality. The Consortium hopes that the bill will not go +forward with the current language on daylight savings time. We +suggest a simple delay of the effective date to insure that calendaring +and scheduling vendors and consumers have ample time to prepare +for the changes. Without surveying a reasonable number of affected +parties, we cannot offer an 'ideal' effective date, but would be +pleased to offer whatever information and expertise we have +available. + +=== What its impact is + +If this legislation is approved, software and hardware calendaring +and scheduling products based on the iCalendar standard will need +to be changed. Users of such products--universities, companies of all +sizes, and many other types of organizations--as well as their +suppliers will face a major challenge: + +* How can vendors efficiently issue "patches" to the problem in +so short a time? Additionally, how could their customers--with +millions of end users--deploy those fixes in so short a time? +* As a corollary, how can organizations in the U.S. that depend +on such products make the necessary changes and remain +synchronized with colleagues outside of the US? + +To complicate matters, this generally affects any calendaring and +scheduling product whether or not it's based on the iCalendar +standard. Anything that keeps a calendar, including cell phones, is +potentially affected. Many embedded environmental systems such as +building management systems, time-lock control, work-shift and +time clocks, may also be affected. + +It is also not clear whether other countries that currently share the +same timezone and DST definitions as the US will adopt the new +definitions at the same time, or stay with the current ones. This has +serious impact for cross-border commerce as for two months in the +year, regions of the US will have a local time one hour different than +similar regions in other countries. + +== What iCalendar has to do to adapt + +=== DST + +Daylight Savings Time (DST), sometimes called 'Summer Time', is +the period during the course of a year in which a particular +geopolitical region advances its local time by one hour compared to +the standard time for that region (as determined by its 'timezone'). +The goal is to better match hours of work and school to real daylight +hours during the course of a day, for better productivity and +potential energy savings. + +For a more complete description and a history of DST, see +http://en.wikipedia.org/wiki/Daylight_savings_time. + +=== iCalendar's dependency on DST + +The Internet Calendaring and Scheduling Core Object Specification, +or iCalendar, is an Internet Engineering Task Force (IETF) proposed +standard defined in the document RFC2445 +(http://www.ietf.org/rfc/rfc2445.txt) and further described in a guide to +calendaring RFC3283 (http://www.ietf.org/rfc/rfc3283.txt). In addition, +specifications also exist that describe how iCalendar can be used for +scheduling between multiple parties (RFC2446 +(http://www.ietf.org/rfc/rfc2446.txt) and RFC 2447 +(http://www.ietf.org/rfc/rfc2447.txt)). + +iCalendar describes a data format to encapsulate calendaring data +such as events and tasks which can be passed between different +systems in an interoperable way. As part of this, timezone +information is also required in order to allow times to be specified +relative to a particular locality. To that end iCalendar defines a +'VTIMEZONE' object that encapsulates timezone information. These +objects provide for both 'STANDARD' and 'DAYLIGHT' subcomponents +that can be used to represent the standard timezone +offset, as well as the timezone offset when DST is in effect. In +addition, these sub-components also specify, via a set of rules or a list +of explicit dates, the dates and times at which DST starts and ends. +Typically rules are used, and those specify the DST changes from +some point in the past, into the future for an indeterminate amount of +time. + +=== Changes need to iCalendar Products + +If this legislation goes forward, the following changes will need to +take place: + +. Any iCalendar product that currently uses timezone +information will have to have their timezone 'definitions' +updated to reflect the new start and end periods for DST. This +affects both calendaring servers and clients, including desktop +and mobile clients. +** In the case of servers, this may be a simple process of +upgrading timezone definitions. +** In the case of clients, either an automated or manual +upgrade of the timezone definitions will be required, subject +to the other issues described below. This process will have to +take place on ALL systems using iCalendar -- potentially tens +or hundreds of millions of users. +** This change is not just limited to US systems -- anyone +outside the US that needs to do business with the US or +travel to the US will need their definitions updated. +. Given that the legislation proposes this change taking effect in +March 2006, it is quite likely that there are already schedules of +events defined for the period when DST is extended. The +question arises as to how these existing events should be +adjusted. +. Typically there are two ways in which timezone definitions are +enumerated. ++ +-- +.. [[case-a]]Using the naming scheme defined in the 'Olsen' timezone +database (ftp://elsie.nci.nih.gov/pub/). This splits the +timezone name into two parts: a region (typically a +continent) and a city. For example: 'America/New_York', +'America/Montreal', 'Europe/London'. +.. [[case-b]]Using the colloquial timezone name, e.g. 'Eastern', +'Central', 'GMT'. + +For <>, updating timezone definitions is a matter of +identifying which cities are in the US and changing just those +definitions. If other countries (e.g. Canada) choose not to adopt +the same changes, then the definitions for cities in Canada +could remain the same. i.e. 'America/New_York' would be +changed and 'America/Montreal' would be unchanged. + +For <> the situation is more complex if other countries do +not adopt the changes. In that case the existing definitions +would need to be split into separate items to reflect the +different timezone rules in each region -- using Canada as an +example again: 'US-Eastern' and 'Canada-Eastern'. Any +upgrade process to existing systems would have to determine +whether an event that currently uses the 'Eastern' definition +should be assigned 'US-Eastern' or 'Canada-Eastern'. It may +not be possible to automatically determine that in all cases and +explicit human intervention may be required. +-- +. The Calendaring and Scheduling consortium recently carried +out a survey on timezone support in calendar products. One +conclusion from that is that a number of products convert local +time information with a supplied timezone into UTC (the +'standard' time reference) as a simplification. As a result of this, +timezone information is effectively lost. Such products will +need to determine how to do any adjustment of the UTC times +based on the proposed DST changes. + +== Contact + +The Calendaring and Scheduling Consortium is composed of ten +universities, seven corporations, two foundations, and one research +facility. More information is available at www.calconnect.org. + +For further information or to discuss these issues, contact Dave +Thewlis, Executive Director: dave.thewlis@calconnect.org + +1550 Dena Drive + +McKinleyville, CA 95519 + +(707) 840 9391 + +www.calconnect.org diff --git a/sources/cc-0601-miniop-usecases-1.0/document.adoc b/sources/cc-0601-miniop-usecases-1.0/document.adoc new file mode 100644 index 0000000..b00f9a3 --- /dev/null +++ b/sources/cc-0601-miniop-usecases-1.0/document.adoc @@ -0,0 +1,688 @@ += Min-IOP (Minimum Interoperable Subset) Use Cases +:docnumber: 0601 +:copyright-year: 2005 +:language: en +:doctype: specification +:edition: 1 +:status: published +:revdate: 2005-11-30 +:published-date: 2005-11-30 +:technical-committee: USECASE +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Jeff McCullouch +:affiliation: UC Berkeley +:role: editor + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +This document was created by the Use Case Technical Committee of +the Calendaring and Scheduling Consortium. The document defines +the use cases for minimum interoperability of calendaring and +scheduling. Minimum interoperability is the basic level of functionality +our collective experience tells us is necessary to have a useful +system. We realize that in some cases it may be more than is +currently offered by "basic" calendaring and scheduling applications. + +== Introduction + +This document was created by the Use Case Technical Committee of the +Calendaring and Scheduling Consortium. The document defines the use cases +for minimum interoperability of calendaring and scheduling. Minimum +interoperability is the basic level of functionality our collective experience tells us +is necessary to have a useful system. We realize that in some cases it may be +more than is currently offered by "basic" calendaring and scheduling applications. + +Areas covered are: + +. Setting up regularly scheduled events +. Scheduling with people in other timezones. +. Scheduling while traveling to other timezones. +. Scheduling and Negotiating meetings with others +. Announcing events + +Please send any changes or corrections to the document editor. + +[heading=terms and definitions] +== Definitions + +The definitions below are taken from the "Calendaring and Scheduling Glossary +of Terms" from CalConnect. + +=== Alarm + +A reminder for an event or a to-do. Alarms may be used to define a +reminder for a pending event or an overdue to-do. + +=== 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. + +[.source] +<> + +=== Calendar User (CU) + +An entity (often a human) that accesses calendar +information. + +[.source] +<> + +=== Calendaring + +An application domain that covers systems that allow the +interchange, access and management of calendar data. + +=== CalConnect + +The Calendaring and Scheduling Consortium consisting of +vendors and user groups interested in promoting and improving calendaring and +scheduling standards and interoperability. + +=== Coordinated Universal Time (UTC) + +An atomic realization of Universal Time +(UT) or Greenwich Mean Time, the astronomical basis for civil time. Time zones +around the world are expressed as positive and negative offsets from UT. UTC +differs by an integral number of seconds from International Atomic Time (TAI), as +measured by atomic clocks and a fractional number of seconds from UT. + +[.source] +<> + +=== Counter + +A counter-proposal request a participant may send to an event or task +organizer to suggest a change to the event or task such as the scheduled +date/time, list of participants, etc. + +=== Daylight Savings Time (DST) + +The period of the year in which the local time of +a particular time zone is adjusted forward, most commonly by one hour, to +account for the additional hours of daylight during summer months. + +=== Event + +A calendar object that usually takes up time on an individual calendar. +Events are commonly used to represent meetings, appointments, anniversaries, +and day events. + +=== Free time search + +(Bounded) Common free time. +This is typically a search +generated by an application to show time on a calendar that is available or open. + +=== Freebusy + +A database and/or listing of times when a potential attendee or +resource is free or busy. Used when scheduling calendar events. + +=== iCalendar + +The Internet Calendaring and Scheduling Core Object Specification. +An IETF standard (RFC 2445) for a text representation of calendar data. + +=== Instance + +When used with recurrences, an instance refers to an item in the set +of recurring items. + +=== Invite + +To request the attendance of someone to a calendar event. + +=== Negotiation + +Resource conflict resolution. Negotiation is the process of resolving +conflicts either programmatically or via direct communication with the participants +and invitees of meetings and events. + +=== Notification + +. The action of making known, an intimation, a notice. +. Reminder or alarm sent when any resource or parties interested in the resource need an +indicator that some attention is required. Possible notification methods include +email, paging, audible signal at the computer, visual indicator at the computer, +voice mail, telephone. + +=== Organizer + +The originator of a calendar event typically involving more than one +attendee. + +=== Publish + +Make known publicly calendar information such as `freebusy` times. + +=== Recurring + +Happening more than once over a specified interval, such as +weekly, monthly, daily, etc. See {{Repeating}}. + +=== Repeating + +An event that happens more than once. You might want an event to +occur on a regular basis. To do this you schedule a repeating event. Any +changes you make to the event can automatically be made to all occurrences of +the event. If necessary, changes can be made to individual events without +affecting the others. For example, if you need to attend a weekly meeting, you +can schedule a repeating event on your calendar. Using another example, if you +want to schedule a five day vacation, schedule an all-day event that repeats daily +for a total of five times. If you have to cancel one of the days, delete the one day +without deleting the whole event. + +=== Reminders + +See {{Notification}}. + +=== Time zone + +Areas of the Earth that have adopted the same local time. Time +zones are generally centered on meridians of a longitude, that is a multiple of +stem:[15 "unitsml(deg)"], thus making neighboring time zones one hour apart. However, the one hour +separation is not universal and the shapes of time zones can be quite irregular +because they usually follow the boundaries of states, countries or other +administrative areas. + +[.source] +<> + +== Use Cases + +=== General + +==== {blank} + +An organizer wants to invite attendees to a meeting on a single date + +[example] +Let's play tennis next Wednesday. + +==== {blank} + +An organizer wants to setup an event with only a start time where there is no +end time or the end time is unknown. + +[example] +At 2 pm I need to take my pills. + +[example] +Party at my house starting at 6:30 pm. + +[example] +Rolling Stones, Red Rocks Ampitheatre, 12/14/05, 7:00 pm + +[example] +Leave at 3:30 pm to go pickup the kids. + +[example] +A reminder that I need to turn in a project report at 3pm + +==== {blank} + +A calendar user wants to set a personal alarm or reminder for an upcoming +event with a specified lead time, and for the alarm or reminder to be triggered at +the appropriate time. + +[example] +I want to be reminded 5 minutes before a meeting starts. + +=== Basic Recurrence + +==== Intervals + +For the basic recurrence intervals below, a calendar user/organizer may wish to +create meetings/events that are unbounded, i.e. no clear end date. Some +examples include birthdays, anniversaries, staff meetings. While different +implementations may or may not allow creation of these types of +meetings/events, the unboundedness should be retained when the +meeting/event is transferred between systems. + +===== Every Nth Interval + +An organizer wants to invite attendees to a meeting that repeats on a +regular interval (hourly, daily, weekly, monthly, yearly). + +[example] +Class is on Tue/Thu of each week + +[example] +Every Wednesday we have a meeting + +[example] +Every year on July 4^th^ + +[example] +Every 3 Sundays play poker + +===== Day of week/month + +An organizer wants to invite attendees to a meeting on a day of the Nth +week/month. + +[example] +Every 3^rd^ Tuesday of the month go to the beach + +[example] +The last Friday in November is black Friday + +===== Nth date of month + +An organizer wants to invite attendees to a meeting on the Nth date of a +month or year. + +[example] +Pay bills on the 15^th^ of the month. + +[example] +Pay day is the last day of the month. + +[example] +Annual report due by end of February every year. + +===== Custom list of dates + +An organizer wants to invite attendees to a meeting with a custom list of +days/dates. + +[example] +The dates for a lecture series: Tuesday this week, +Wednesday next week, & Friday the following week. + +===== Basic combinations + +An organizer wants to invite attendees to a meeting that includes dates +from a combination of regular intervals. + +[example] +The 2^nd^ Sunday every 3 months for a small church that only +has communion every 3 months. + +[example] +The 1^st^ day of every other month + +===== Exceptions + +An organizer wants to invite attendees to a meeting that includes dates +from a regular interval with an exception. + +[example] +Last Friday every month except November + +[example] +Meeting on Mondays January through March except for +Monday holidays. + +[example] +Moving a meeting. We have a status meeting every Monday +except next Monday is Labor Day, so we'll have to move that meeting to +Tuesday. + +[example] +Meeting every 5 weeks on Thursday plus next Wednesday. + +=== Basic Time Zone + +==== Meetings across time zones + +===== Repeating meeting involving multiple time zones + +An organizer wants to schedule a repeating meeting (phone/video +conference) with people working in many different time zones. Note: some +time zones have fifteen or thirty minute offsets rather than the more +standard one hour offset. Also some people may be in time zones currently +in daylight savings time, while others may not. + +[example] +A product manager wants to schedule several video conferences for 9am +`GMT0BST` in a multi-national corporation across 10 time zones. One +participant is in Chatham, New Zealand which has 12 hours, 45 minutes +time zone offset from UTC. + +===== Events with begin and end times in different time zones +An airline reservation system is used to book a flight which leaves at +1:10 pm PST from San Francisco, and arrives at 9:43 pm EST in New +York, NY (5 hours 33 mins flying time) or one that leaves at 1:45 pm from +Sydney, Australia and arrives in San Francisco, CA at 10:05 am PST(13 +hours 20 mins flying time). An ICS file is sent to user to add to their +calendar. + +==== Meetings involving daylight savings time + +===== Monthly meetings + +An organizer wants to create a monthly meeting between February and +August with participants in United States, Germany and Japan. (Japan +does not have daylight savings time). + +===== Shift work + +An organizer wants to create a schedule where the end time is fixed and +the schedule crosses a daylight savings time change. + +[example] +For hospital staff the shifts are normally 8 hours long. When +there is a daylight savings time change, one of the shifts will be longer or +shorter depending on the direction of the time change. + +===== Flight schedules + +An organizer wants to create a schedule where the duration is fixed and +the schedule crosses a daylight savings time change. + +[example] +Flight schedules are dependent on the actual flight duration. +The arrival time will need to be shifted across a daylight savings time +change. + +===== Changes in Daylight Saving Time definitions + +An organizer creates a meeting with a person in a different time zone +where the government may change the dates for daylight savings time +each year, and the time zone definition is changed after the meeting +creation time. + +[example] +Israel moves their DST time changes each year. + +[example] +Brazil once moved their DST time change to accommodate +the arrival of the Pope. + +=== Scheduling + +==== Inviting attendees + +===== {blank} + +An organizer wants to send out an invitation to people that are both +within and external to their calendar server. + +===== {blank} + +An organizer wants to track responses or view the attendee list for their +meeting invitation for both intra and external participants. + +===== {blank} + +An organizer wants to modify the meeting, and have those changes +reflected on all invitees calendars. (Start time, duration, date, location, +invitees, body) + +===== {blank} + +An organizer wants to modify the meeting, and let the participants know +about the change. (Start time, duration, date, location, invitees, body) + +===== {blank} + +An organizer wants to cancel a meeting. + +==== Responding + +===== {blank} + +An attendee wants to accept/decline a meeting invitation. They may wish +to change their status later. + +===== {blank} + +An attendee wants to counter a non-repeating invitation. + +[example] +Joe creates a meeting and invites Mary. Mary can't make it at +the time Joe selected, and counters the meeting, offering a time 3 hours +later in the day. Joe accepts the counter and the meeting is rescheduled to +3 hours later in the day. + +===== {blank} + +An attendee wants to view the attendee list and/or acceptance of other +attendees + +[example] +Joe wants to come to a proposed meeting only if the right +people are attending, so Joe needs to see who is invited and who has +accepted. + +==== Free/Busy Time + +===== {blank} + +A calendar user wants to allow another calendar user to see their +calendar. + +[example] +While organizing a meeting, the organizer wants to view all +the schedules of all the participants to determine when there are no +conflicts. + +[example] +Joe is wants to ask Sam a quick question. Joe looks at Sam's +calendar to determine if he might be available. + +[example] +Samantha is analyzing how much time is spent on various +projects. She looks at staff member calendars, and adds the time spent. +She may need to view the details of meetings to determine this correctly. + +[example] +Your spouse wants to see if you can pickup the kids. They +may notice that you have something else scheduled or that you already +have marked it on your schedule. They don't necessarily want to add +anything to your schedule. + +==== Recurrence + +Similar to basic recurrence, changes to unbounded, repeating meetings/events +should retain their unboundedness when a change is made to one or all +instances of the meeting/event. + +===== Change all instances + +An organizer wants to change all of the instances of a repeating meeting to +another date/time. + +[example] +==== +Chair sends recurring meeting to invitee that starts Monday April 11, 2005 +and repeats every day for 5 days from 0900-1000. This should yield a +recurring meeting with following date/times: + +04/11/05:: 0900-1000 +04/12/05:: 0900-1000 +04/13/05:: 0900-1000 +04/14/05:: 0900-1000 +04/15/05:: 0900-1000 + +Chair reschedules time portion for all instances of the recurring meeting +1 +hr, so from 1000-1100. This should yield a recurring meeting with following +date/times: + +04/11/05:: 1000-1100 +04/12/05:: 1000-1100 +04/13/05:: 1000-1100 +04/14/05:: 1000-1100 +04/15/05:: 1000-1100 +==== + +===== Change one instance + +An organizer wants to change one instance of a repeating meeting to +another date/time. + +[example] +==== +Chair sends recurring meeting to invitee that starts Monday April 25, 2005 +and repeats everyday for 5 days from 0900-1000. This should yield a +recurring meeting with following date/times: + +04/25/05:: 0900-1000 +04/26/05:: 0900-1000 +04/27/05:: 0900-1000 +04/28/05:: 0900-1000 +04/29/05:: 0900-1000 + +Chair reschedules a single instance's (Tuesday's) time portion +1 hr, so +from 1000-1100 on Tuesday April 26, 2005. This should yield a recurring +meeting with following date/times: + +04/25/05:: 0900-1000 +04/26/05:: 1000-1100 +04/27/05:: 0900-1000 +04/28/05:: 0900-1000 +04/29/05:: 0900-1000 +==== + +===== Extending a series + +An organizer creates a repeating meeting for some day of the week, then +later needs to add another meeting to the series on the same day of the +week. + +[example] +==== +Chair sends recurring meeting to invitee that starts Wednesday April 27, +2005 and repeats every Wednesday for the next 5 weeks from 0900-1000. +This should yield a recurring meeting with following date/times: + +04/27/05:: 0900-1000 +05/04/05:: 0900-1000 +05/11/05:: 0900-1000 +05/18/05:: 0900-1000 +05/25/05:: 0900-1000 + +Chair extends the series of meetings to six weeks by adding a single +instance, Wednesday June 1, 2005. All other attributes are the same. This +should yield a recurring meeting with following date/times: + +04/27/05:: 0900-1000 +05/04/05:: 0900-1000 +05/11/05:: 0900-1000 +05/18/05:: 0900-1000 +05/25/05:: 0900-1000 +06/01/05:: 0900-1000 +==== + +===== Adding an extra date that is an exception to a series + +An organizer creates a repeating meeting for some day of the week, then +later needs to add another meeting to the series on a different day of the +week. + +[example] +==== +Chair sends recurring meeting to invitee that starts Wednesday April 27, +2005 and repeats every Wednesday for the next 5 weeks from 0900-1000. +This should yield a recurring meeting with following date/times: + +04/27/05:: 0900-1000 +05/04/05:: 0900-1000 +05/11/05:: 0900-1000 +05/18/05:: 0900-1000 +05/25/05:: 0900-1000 + +Chair adds a single instance, Tuesday May 31, 2005. This should yield a +recurring meeting with following date/times: + +04/27/05:: 0900-1000 +05/04/05:: 0900-1000 +05/11/05:: 0900-1000 +05/18/05:: 0900-1000 +05/25/05:: 0900-1000 +05/31/05:: 0900-1000 +==== + +===== Change the body of all instances +An organizer wants to change the body of all the instances of a repeating +meeting. + +[example] +==== +Chair sends recurring meeting to invitee that starts Monday April 18, 2005 +and repeats everyday for 5 days from 0900-1000. This should yield a +recurring meeting with following date/times: + +04/18/05:: 0900-1000 +04/19/05:: 0900-1000 +04/20/05:: 0900-1000 +04/21/05:: 0900-1000 +04/22/05:: 0900-1000 + +Chair sends an update to the body part for all instances of the recurring +meeting to add a rough agenda format to the description field. +==== + +===== Change the body of one instance + +An organizer wants to change the body of one of the instances of a +repeating meeting. + +[example] +Chair needs to make changes to individual meeting agendas +before each meeting. + +===== Add/Remove attendee to all instances + +An organizer wants to add/remove an attendee to all the instances of a +repeating meeting + +===== Add/Remove attendee to one instance + +An organizer wants to add/remove an attendee to/from one of the +instances of a repeating meeting + +===== This and future + +An organizer wants to change all dates/times for a meeting from now until +the end of the interval. + +[example] +Joe creates a five day repeating meeting (M-F) and invites some people. +Later, while trying to get a room, Joe needs to reschedule Weds and All +Future to be an hour later in the day. + +[example] +Susan created a repeating staff meeting on the first Monday of the month +two months ago. She wants to change the meeting to be the first Tuesday +of the month from now onward. + +==== Time Zone + +===== Repeating Meeting across time zones with reschedule + +An organizer has scheduled a repeating meeting (phone/video conference) +with people working in many different time zones and wants to change the +time of one of the meetings. + +[example] +==== +A product manager wants to schedule several video conferences for 9am +`GMT0BST` on Tuesdays in a multi-national corporation across 10 time +zones. One participant is in Chatham, New Zealand which has 12 hours, +45 minutes time zone offset from UTC. The third in the series needs to be +changed to Wednesday to accommodate two of the participants. + +NOTE: For this to work properly, the dates must be stored with time zone +format +==== + +[bibliography] +== Bibliography + +* [[[rfc3283,RFC 3283]]] + +* [[[wiki,Wikipedia]]], https://www.wikipedia.org/ diff --git a/sources/cc-0601-miniop-usecases-v1.1/document.adoc b/sources/cc-0601-miniop-usecases-v1.1/document.adoc new file mode 100644 index 0000000..2630b80 --- /dev/null +++ b/sources/cc-0601-miniop-usecases-v1.1/document.adoc @@ -0,0 +1,692 @@ += Min-IOP (Minimum Interoperable Subset) Use Cases +:docnumber: 0601 +:copyright-year: 2006 +:language: en +:doctype: specification +:edition: 1.1 +:status: published +:revdate: 2006-01-24 +:published-date: 2006-01-24 +:technical-committee: USECASE +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Jeff McCullouch +:affiliation: UC Berkeley +:role: editor + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +This document was created by the Use Case Technical Committee of +the Calendaring and Scheduling Consortium. The document defines +the use cases for minimum interoperability of calendaring and +scheduling. Minimum interoperability is the basic level of functionality +our collective experience tells us is necessary to have a useful +system. We realize that in some cases it may be more than is +currently offered by "basic" calendaring and scheduling applications. + +== Introduction + +This document was created by the Use Case Technical Committee of the Calendaring +and Scheduling Consortium. The document defines the use cases for minimum +interoperability of calendaring and scheduling. Minimum interoperability is the basic level +of functionality our collective experience tells us is necessary to have a useful system. +We realize that in some cases it may be more than is currently offered by "basic" +calendaring and scheduling applications. + +Areas covered are: + +. Setting up regularly scheduled events +. Scheduling with people in other time zones. +. Scheduling while traveling to other time zones. +. Scheduling and Negotiating meetings with others +. Announcing events + +Please send any changes or corrections to the document editor. + +[heading=terms and definitions] +== Definitions + +The definitions below are taken from the "Calendaring and Scheduling Glossary of +Terms" from CalConnect. + +=== Alarm + +A reminder for an event or a to-do. Alarms may be used to define a reminder for +a pending event or an overdue to-do. + +=== 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. + +[.source] +<> + +=== Calendar User (CU) + +An entity (often a human) that accesses calendar information. + +[.source] +<> + +=== Calendaring + +An application domain that covers systems that allow the interchange, +access and management of calendar data. + +=== CalConnect + +The Calendaring and Scheduling Consortium consisting of vendors and +user groups interested in promoting and improving calendaring and scheduling +standards and interoperability. + +=== Coordinated Universal Time (UTC) + +An atomic realization of Universal Time (UT) or +Greenwich Mean Time, the astronomical basis for civil time. Time zones around the +world are expressed as positive and negative offsets from UT. UTC differs by an integral +number of seconds from International Atomic Time (TAI), as measured by atomic clocks +and a fractional number of seconds from UT. + +[.source] +<> + +=== Counter + +A counter-proposal request a participant may send to an event or task +organizer to suggest a change to the event or task such as the scheduled date/time, list +of participants, etc. + +=== Daylight Savings Time (DST) + +The period of the year in which the local time of a +particular time zone is adjusted forward, most commonly by one hour, to account for the +additional hours of daylight during summer months. + +=== Event + +A calendar object that usually takes up time on an individual calendar. Events +are commonly used to represent meetings, appointments, anniversaries, and day +events. + +=== Free time search + +(Bounded) Common free time. +This is typically a search generated +by an application to show time on a calendar that is available or open. + +=== Freebusy + +A database and/or listing of times when a potential attendee or resource is +free or busy. Used when scheduling calendar events. + +=== iCalendar + +The Internet Calendaring and Scheduling Core Object Specification. An +IETF standard (RFC 2445) for a text representation of calendar data. + +=== Instance + +When used with recurrences, an instance refers to an item in the set of +recurring items. + +=== Invite + +To request the attendance of someone to a calendar event. + +=== Negotiation + +Resource conflict resolution. Negotiation is the process of resolving +conflicts either programmatically or via direct communication with the participants and +invitees of meetings and events. + +=== Notification + +. The action of making known, an intimation, a notice. +. Reminder or alarm sent when any resource or parties interested in the resource need an indicator +that some attention is required. Possible notification methods include email, paging, +audible signal at the computer, visual indicator at the computer, voice mail, telephone. + +=== Organizer + +The originator of a calendar event typically involving more than one +attendee. + +=== Publish + +Make known publicly calendar information such as `freebusy` times. + +=== Recurring + +Happening more than once over a specified interval, such as weekly, +monthly, daily, etc. See {{Repeating}}. + +=== Repeating + +An event that happens more than once. You might want an event to occur +on a regular basis. To do this you schedule a repeating event. Any changes you make to +the event can automatically be made to all occurrences of the event. If necessary, +changes can be made to individual events without affecting the others. For example, if +you need to attend a weekly meeting, you can schedule a repeating event on your +calendar. Using another example, if you want to schedule a five day vacation, schedule +an all-day event that repeats daily for a total of five times. If you have to cancel one of +the days, delete the one day without deleting the whole event. + +=== Reminders + +See {{Notification}}. + +=== Time zone + +Areas of the Earth that have adopted the same local time. Time zones are +generally centered on meridians of a longitude, that is a multiple of stem:[15 "unitsml(deg)"], thus making +neighboring time zones one hour apart. However, the one hour separation is not +universal and the shapes of time zones can be quite irregular because they usually +follow the boundaries of states, countries or other administrative areas. + +[.source] +<> + +== Use Cases + +=== General Calendaring + +==== Basic invitation + +An organizer wants to invite attendees to a meeting on a single date + +[example] +Let's play tennis next Wednesday. + +==== Events with no end time + +An organizer wants to setup an event with only a start time where there is no +end time or the end time is unknown. + +[example] +At 2 pm I need to take my pills. + +[example] +Party at my house starting at 6:30 pm. + +[example] +Rolling Stones, Red Rocks Ampitheatre, 12/14/05, 7:00 pm + +[example] +Leave at 3:30 pm to go pickup the kids. + +[example] +A reminder that I need to turn in a project report at 3pm + +==== Alarms/Reminders + +A calendar user wants to set a personal alarm or reminder for an upcoming +event with a specified lead time, and for the alarm or reminder to be triggered at +the appropriate time. + +[example] +I want to be reminded 5 minutes before a meeting starts. + +=== Basic Recurrence (Intervals) + +For the basic recurrence intervals below, a calendar user/organizer may wish to +create meetings/events that are unbounded, i.e. no clear end date. Some examples +include birthdays, anniversaries, staff meetings. While different implementations may +or may not allow creation of these types of meetings/events, the unboundedness +should be retained when the meeting/event is transferred between systems. + +==== Every Nth Interval + +An organizer wants to invite attendees to a meeting that repeats on a regular +interval (hourly, daily, weekly, monthly, yearly). + +[example] +Class is on Tue/Thu of each week + +[example] +Every Wednesday we have a meeting + +[example] +Every year on July 4^th^ + +[example] +Every 3 Sundays play poker + +[example] +Every 4 hours take a 15 min break + +==== Day of week/month + +An organizer wants to invite attendees to a meeting on a day of the Nth +week/month. + +[example] +Every 3^rd^ Tuesday of the month go to the beach + +[example] +The last Friday in November is black Friday + +==== Nth date of month + +An organizer wants to invite attendees to a meeting on the Nth date of a month +or year. + +[example] +Pay bills on the 15^th^ of the month. + +[example] +Pay day is the last day of the month. + +[example] +Annual report due by end of February every year. + +==== Custom list of dates + +An organizer wants to invite attendees to a meeting with a custom list of +days/dates. + +[example] +The dates for a lecture series: Tuesday this week, +Wednesday next week, & Friday the following week. + +==== Basic combinations + +An organizer wants to invite attendees to a meeting that includes dates from a +combination of regular intervals. + +[example] +The 2^nd^ Sunday every 3 months for a small church that only +has communion every 3 months. + +[example] +The 1^st^ day of every other month + +==== Exceptions + +An organizer wants to invite attendees to a meeting that includes dates from a +regular interval with an exception. + +[example] +Last Friday every month except November + +[example] +Meeting on Mondays January through March except for +Monday holidays. + +[example] +Moving a meeting. We have a status meeting every Monday +except next Monday is Labor Day, so we'll have to move that meeting to +Tuesday. + +[example] +Meeting every 5 weeks on Thursday plus next Wednesday. + +=== Basic Time Zone + +==== Meetings across time zones + +===== Repeating meeting involving multiple time zones + +An organizer wants to schedule a repeating meeting (phone/video +conference) with people working in many different time zones. Note: some +time zones have fifteen or thirty minute offsets rather than the more +standard one hour offset. Also some people may be in time zones currently +in daylight savings time, while others may not. + +[example] +A product manager wants to schedule several video conferences for 9am +`GMT0BST` in a multi-national corporation across 10 time zones. One +participant is in Chatham, New Zealand which has 12 hours, 45 minutes +time zone offset from UTC. + +===== Events with begin and end times in different time zones + +An airline reservation system is used to book a flight which leaves at +1:10 pm PST from San Francisco, and arrives at 9:43 pm EST in New +York, NY (5 hours 33 mins flying time) or one that leaves at 1:45 pm from +Sydney, Australia and arrives in San Francisco, CA at 10:05 am PST(13 +hours 20 mins flying time). An ICS file is sent to user to add to their +calendar. + +==== Meetings involving daylight savings time + +===== Monthly meetings + +An organizer wants to create a monthly meeting between February and +August with participants in United States, Germany and Japan. (Japan +does not have daylight savings time). + +===== Shift work + +An organizer wants to create a schedule where the end time is fixed and +the schedule crosses a daylight savings time change. + +[example] +For hospital staff the shifts are normally 8 hours long. When +there is a daylight savings time change, one of the shifts will be longer or +shorter depending on the direction of the time change. + +===== Flight schedules + +An organizer wants to create a schedule where the duration is fixed and +the schedule crosses a daylight savings time change. + +[example] +Flight schedules are dependent on the actual flight duration. +The arrival time will need to be shifted across a daylight savings time +change. + +===== Changes in Daylight Saving Time definitions + +An organizer creates a meeting with a person in a different time zone +where the government may change the dates for daylight savings time +each year, and the time zone definition is changed after the meeting +creation time. + +[example] +Israel moves their DST time changes each year. + +[example] +Brazil once moved their DST time change to accommodate +the arrival of the Pope. + +=== Scheduling + +==== Inviting attendees + +===== Invitations for users on and external to your server + +An organizer wants to send out an invitation to people that are both within +and external to their calendar server. + +===== Track responses + +An organizer wants to track responses or view the attendee list for their +meeting invitation for both intra and external participants. + +===== Modify a meeting + +An organizer wants to modify the meeting, and have those changes +reflected on all invitees calendars. (Start time, duration, date, location, +invitees, body) + +===== Modify a meeting with an alert + +An organizer wants to modify the meeting, and let the participants know +about the change. (Start time, duration, date, location, invitees, body) + +===== Cancel a meeting + +An organizer wants to cancel a meeting. + +==== Responding + +===== Accept an invitation + +An attendee wants to accept/decline a meeting invitation. They may wish to +change their status later. + +===== Counter a non-repeating meeting + +An attendee wants to counter a non-repeating invitation. + +[example] +Joe creates a meeting and invites Mary. Mary can't make it at +the time Joe selected, and counters the meeting, offering a time 3 hours +later in the day. Joe accepts the counter and the meeting is rescheduled to +3 hours later in the day. + +===== View attendance list + +An attendee wants to view the attendee list and/or acceptance of other +attendees + +[example] +Joe wants to come to a proposed meeting only if the right +people are attending, so Joe needs to see who is invited and who has +accepted. + +==== Free/Busy Time + +===== View free/busy time of another user + +A calendar user wants to allow another calendar user to see their calendar. + +[example] +While organizing a meeting, the organizer wants to view all +the schedules of all the participants to determine when there are no +conflicts. + +[example] +Joe is wants to ask Sam a quick question. Joe looks at Sam's +calendar to determine if he might be available. + +[example] +Samantha is analyzing how much time is spent on various +projects. She looks at staff member calendars, and adds the time spent. +She may need to view the details of meetings to determine this correctly. + +[example] +Your spouse wants to see if you can pickup the kids. They +may notice that you have something else scheduled or that you already +have marked it on your schedule. They don't necessarily want to add +anything to your schedule. + +==== Recurrence + +Similar to basic recurrence, changes to unbounded, repeating meetings/events +should retain their unboundedness when a change is made to one or all +instances of the meeting/event. + +===== Change all instances + +An organizer wants to change all of the instances of a repeating meeting to +another date/time. + +[example] +==== +Chair sends recurring meeting to invitee that starts Monday April 11, 2005 +and repeats every day for 5 days from 0900-1000. This should yield a +recurring meeting with following date/times: + +04/11/05:: 0900-1000 +04/12/05:: 0900-1000 +04/13/05:: 0900-1000 +04/14/05:: 0900-1000 +04/15/05:: 0900-1000 + +Chair reschedules time portion for all instances of the recurring meeting +1 +hour, so from 1000-1100. This should yield a recurring meeting with +following date/times: + +04/11/05:: 1000-1100 +04/12/05:: 1000-1100 +04/13/05:: 1000-1100 +04/14/05:: 1000-1100 +04/15/05:: 1000-1100 +==== + +===== Change one instance + +An organizer wants to change one instance of a repeating meeting to +another date/time. + +[example] +==== +Chair sends recurring meeting to invitee that starts Monday April 25, 2005 +and repeats everyday for 5 days from 0900-1000. This should yield a +recurring meeting with following date/times: + +04/25/05:: 0900-1000 +04/26/05:: 0900-1000 +04/27/05:: 0900-1000 +04/28/05:: 0900-1000 +04/29/05:: 0900-1000 + +Chair reschedules a single instance's (Tuesday's) time portion +1 hr, so +from 1000-1100 on Tuesday April 26, 2005. This should yield a recurring +meeting with following date/times: + +04/25/05:: 0900-1000 +04/26/05:: 1000-1100 +04/27/05:: 0900-1000 +04/28/05:: 0900-1000 +04/29/05:: 0900-1000 +==== + +[example] +Chair sends monthly recurring staff meeting held on first Tuesday of the +month to staff members. The first meeting is Tuesday, February 7, 2006. +The meetings will continue indefinitely into the future. Normally the location +for the meeting is fixed, but needs to be changed for the June meeting. +Chair changes the location, and resends the invitation. + +===== Extending a series + +An organizer creates a repeating meeting for some day of the week, then +later needs to add another meeting to the series on the same day of the +week. + +[example] +==== +Chair sends recurring meeting to invitee that starts Wednesday April 27, +2005 and repeats every Wednesday for the next 5 weeks from 0900-1000. +This should yield a recurring meeting with following date/times: + +04/27/05:: 0900-1000 +05/04/05:: 0900-1000 +05/11/05:: 0900-1000 +05/18/05:: 0900-1000 +05/25/05:: 0900-1000 + +Chair extends the series of meetings to six weeks by adding a single +instance, Wednesday June 1, 2005. All other attributes are the same. This +should yield a recurring meeting with following date/times: + +04/27/05:: 0900-1000 +05/04/05:: 0900-1000 +05/11/05:: 0900-1000 +05/18/05:: 0900-1000 +05/25/05:: 0900-1000 +06/01/05:: 0900-1000 +==== + +===== Adding an extra date that is an exception to a series + +An organizer creates a repeating meeting for some day of the week, then +later needs to add another meeting to the series on a different day of the +week. + +[example] +==== +Chair sends recurring meeting to invitee that starts Wednesday April 27, +2005 and repeats every Wednesday for the next 5 weeks from 0900-1000. +This should yield a recurring meeting with following date/times: + +04/27/05:: 0900-1000 +05/04/05:: 0900-1000 +05/11/05:: 0900-1000 +05/18/05:: 0900-1000 +05/25/05:: 0900-1000 + +Chair adds a single instance, Tuesday May 31, 2005. This should yield a +recurring meeting with following date/times: + +04/27/05:: 0900-1000 +05/04/05:: 0900-1000 +05/11/05:: 0900-1000 +05/18/05:: 0900-1000 +05/25/05:: 0900-1000 +05/31/05:: 0900-1000 +==== + +===== Change the body of all instances + +An organizer wants to change the body of all the instances of a repeating +meeting. + +[example] +==== +Chair sends recurring meeting to invitee that starts Monday April 18, 2005 +and repeats everyday for 5 days from 0900-1000. This should yield a +recurring meeting with following date/times: + +04/18/05:: 0900-1000 +04/19/05:: 0900-1000 +04/20/05:: 0900-1000 +04/21/05:: 0900-1000 +04/22/05:: 0900-1000 + +Chair sends an update to the body part for all instances of the recurring +meeting to add a rough agenda format to the description field. +==== + +===== Change the body of one instance + +An organizer wants to change the body of one of the instances of a +repeating meeting. + +[example] +Chair needs to make changes to individual meeting agendas +before each meeting. + +===== Add/Remove attendee to/from all instances + +An organizer wants to add/remove an attendee to all the instances of a +repeating meeting + +===== Add/Remove attendee to/from one instance + +An organizer wants to add/remove an attendee to/from one of the +instances of a repeating meeting + +===== This and future + +An organizer wants to change all dates/times for a meeting from now until +the end of the interval. + +[example] +Joe creates a five day repeating meeting (M-F) and invites some people. +Later, while trying to get a room, Joe needs to reschedule Weds and All +Future to be an hour later in the day. + +[example] +Susan created a repeating staff meeting on the first Monday of the month +two months ago. She wants to change the meeting to be the first Tuesday +of the month from now onward. + +==== Time Zone + +===== Repeating Meeting across time zones with reschedule + +An organizer has scheduled a repeating meeting (phone/video conference) +with people working in many different time zones and wants to change the +time of one of the meetings. + +[example] +==== +A product manager wants to schedule several video conferences for 9am +`GMT0BST` on Tuesdays in a multi-national corporation across 10 time +zones. One participant is in Chatham, New Zealand which has 12 hours, +45 minutes time zone offset from UTC. The third in the series needs to be +changed to Wednesday to accommodate two of the participants. + +NOTE: For this to work properly, the dates must be stored with time zone +format) +==== + +[bibliography] +== Bibliography + +* [[[rfc3283,RFC 3283]]] + +* [[[wiki,Wikipedia]]], https://www.wikipedia.org/ diff --git a/sources/cc-0602-ical-tz-problems/document.adoc b/sources/cc-0602-ical-tz-problems/document.adoc new file mode 100644 index 0000000..53a71cc --- /dev/null +++ b/sources/cc-0602-ical-tz-problems/document.adoc @@ -0,0 +1,299 @@ += iCalendar Timezone Problems and Recommendations +:docnumber: 0602 +:copyright-year: 2006 +:language: en +:doctype: report +:edition: 1 +:status: published +:revdate: 2006-01-24 +:published-date: 2006-01-24 +:technical-committee: TIMEZONE +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Simon Vaillancourt +:affiliation: Oracle Corporation +:role: editor + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +This document was created by the TIMEZONE Technical Committee +of the Calendaring and Scheduling Consortium. It contains +information about common time zone implementation issues and +recommendations on how to resolve these issues. We first justify the +need for time zones, then we identify time zone implementation +problems, and then offer some guidelines and recommendations. +Take note that the listed recommendations often describe what +vendors are currently doing to solve the problems. + +== Introduction + +This document contains information about common time zone implementation issues and +recommendations on how to resolve these issues. We first justify the need for time zones, +then we identify time zone implementation problems, and then offer some guidelines and +recommendations. Take note that the listed recommendations often describe what +vendors are currently doing to solve the problems. + +== Why do we need time zones? + +This section contains emails gathered on various mailing lists (e.g.: +ietfcalsify@osafoundation.org, tc-timezone-l@calconnect.org...) and a summary of +discussions between Calendaring and Scheduling Consortium members. + +=== Why should time zone information be preserved in a `VCALENDAR` object rather than converting to UTC? + +==== {blank} +Recurring events that occur on both sides of a daylight savings time change need the +appropriate time zone information to ensure they happen at the correct local time. + +==== {blank} +Keeping the time zone information during the whole life of the event is important because +it allows the events to be adjusted if a change to the time zone rules occurs. + +==== {blank} +Interoperability with well-established products is a requirement for most calendar +applications. Anything that those products support will most likely have to be supported +by the majority of standards-based calendar applications, so we should keep time zones +in the standard, clarifying them if needed instead of removing them entirely. + +==== {blank} +It gives more context information about the meeting creation that can be used in the +future if the meeting times have to be adjusted. + +==== {blank} +Because the day of the week corresponding to a local time and a UTC time may be +different, recurrence rules cannot reliably be expanded using only UTC time. + +[example] +A meeting occurring every first Monday of the month at 0:30 CEST would be +22:30 every Sunday in UTC. Since the first Sunday of the month is not always occurring +just before the first Monday of the month, converting that event to UTC would not expand +that rule correctly. + +=== Should a `VCALENDAR` object contain whole `VTIMEZONE` objects or reference to a time zone? + +Here are some arguments for having a whole `VTIMEZONE` object inside a +`VCALENDAR` object instead of just a reference to an external time zone definition: + +==== {blank} +Including the `VTIMEZONE` data in the `VCALENDAR` object makes the entity self +contained and very portable. + +==== {blank} +An application with only offline viewing capabilities does not have to worry about keeping +a time zone database if all the `VCALENDAR` objects contain the necessary time zone +information. + +== Identified implementation problems and recommendations + +Implementing a standards-compliant calendar client or server that supports time zones +correctly is not an easy task. This section describes some common implementation +problems and recommendations in italics. + +=== General time zone issues + +==== {blank} +How should a client / server react towards existing meetings when a time zone rule +changes? For example, if DST changes for a time zone, should the existing meetings +created in that time zone be adjusted to the new rules or should they remain the same +and let the changes be applied only to newly created events? + +===== {blank} +In most cases, meetings created using a time zone should use the new time +zone definition so that effected recurrences reflect the time zone change +(Example: Lunch at noon every day). Cases where the timing has to be fixed +should be created in UTC (Example: Enter a few digits on a terminal every +108 minutes), which has no dependency on time zone rules. + +==== {blank} +How should a client / server handle a new time zone? + +===== {blank} +If a client /server model is used, the server should have a means of updating +the time zone list. This can be accomplished in many different ways such as +keeping a checksum of the "current" time zone list; when that list changes on +the server, clients simply re-download their local copies. + +===== {blank} +If a PIM client is used (no server), a patch could be issued updating its time +zone list. + +==== {blank} +How should a client / server handle a time zone fork? (For example: if DST changes in +the US only and not in Canada and meetings were created using an `EST5EDT` time +zone). This could create two new time zones `EST5EDT_CA` for Canada and +`EST5EDT_US` for the US (and deprecating `EST5EDT`). + +===== {blank} +The `GEO` property might be used to detect which of the new time zones +every meeting belongs in. + +===== {blank} +The `LOCATION` property can also be used to detect the appropriate time +zone for the meetings. + +===== {blank} +If no information in the calendar object can be used to detect the appropriate +new time zone, a default choice could be used based on where the majority +of the meetings usually occur. + +=== Consuming time zones + +Quite often, applications have a list of time zones stored internally or in a non-standard +registry, and when a meeting is created with a time zone, the application will: + +. Try to match the supplied time zone with its internal representation. This match +can be accomplished by using any of these techniques: +** Have an algorithm pick an internal time zone with the closest corresponding +set of rules to the supplied one. +** Try to match the `TZID` with its internal counterpart. +. If no match can be found the application will do one of these: +** Return an error. +** Add the new time zone to its internal time zone list. + +At this point, these problems can occur: + +==== {blank} +If the application cannot add "unmatchable" time zones to its internal list, even a perfectly +valid VTIMEZONE can be rejected. + +===== {blank} +The meeting could be converted to UTC using the provided time zone, take +note that this solution is less than ideal since time zone information is lost. + +==== {blank} +If the application has in its internal list a `TZID` "America/New_York", and receives a +`VTIMEZONE` with a `TZID` "America/New_York" with a different definition than its internal +one, the server may react unpredictably. + +===== {blank} +If using a time zone registry the time zone definition of the registry should be +the one used. + +===== {blank} +If using an internal time zone list that can be changed, a versioning of the +`TZID` could be used allowing different versions of the same ``TZID``s to be kept. +This would allow applications to have events using different time zones with +the same `TZID`. Take note however that consuming and preserving all time +zones can become quite problematic: + +* Since time zone ids are often shown to users, the time zone list could +become quite large and confusing over time. +* The need to "preserve" the original consumed time zone can also look +like a bad idea when a time zone rule changes; meetings that have yet to +occur will most likely need to be updated with the new time zone rule. + +=== Client application time zone issues + +==== How should client applications present a choice of time zones to users? + +===== {blank} +Use `TZDATA` database (a.k.a. Olson Database, "America/New_York") +names. + +===== {blank} +Use a GMT Offset scheme ("GMT+2, Cairo"...). + +===== {blank} +Use common name presentation (`EST5EDT`, `PST8PDT`...). + +===== {blank} +Additionally, a "clickable" world map is often used. + +==== Where should a client application get its supported time zone list? + +===== {blank} +Use `TZDATA` database (a.k.a. Olson Database). + +===== {blank} +Use standardized registry. + +==== How can a client application map the Operating System time zone to the calendar server time zone? + +===== {blank} +Time zone registry with "aliases" could be used. The mapping of OS time +zone to a standardized time zone database could be provided by OS +Vendors or by a third party. For the long term, platform vendors should +ideally start using data coming from a standardized registry. + +==== How often should a client update its time zone definition + +===== {blank} +Clients can compare a checksum of its time zone list against the server's +checksum, if it's different; the client refreshes its time zone list with the +server's time zone list. + +===== {blank} +By doing periodic checks on the server. + +===== {blank} +Using a push mechanism notifying the client that a time zone has been +updated. Possibly by adding a new iTIP method. + +=== Time zone registry and service issues + +==== Why do we need a time zone registry and service? + +===== {blank} +A time zone registry would be useful in producing a standardized list of time +zones. + +===== {blank} +A time zone service protocol would be useful in defining how time zones +should be retrieved and in what format. + +===== {blank} +A time zone registry and service would promote interoperability. + +===== {blank} +A time zone registry and service would solve the problems encountered +when trying to consume time zones. + +===== {blank} +A time zone service means having centralized time zone definitions that are +easy to update. + +===== {blank} +A time zone registry and service could open the door for time zones being +sent by reference (Useful for mobile devices and other bandwidth limited +platforms). + +==== How should a time zone registry be implemented? + +===== {blank} +By using an IANA registry to store time zone data with a standardized +naming scheme. + +==== How should a time zone service be implemented? + +===== {blank} +By defining a standardized way to retrieve the IANA registered time zones +(i.e.: `VTIMEZONE` objects accessible through an extension of CalDAV, DNS, +HTTP....). + +==== Who should be responsible for updating it, how can it be trusted? + +===== {blank} +Updates could be done through: RFC, informational RFC, appointed/elected +committee/individual who approves updates to the list. + +[bibliography] +== References + +* [[[tz,1]]], Time zone registry draft http://www.ietf.org/internet-drafts/draft-royer-timezone-registry-02.txt + +* [[[wtz,2]]], Windows time zones to TZID mapping http://unicode.org/cldr/data/diff/supplemental/supplemental.html#windows___tzid + +* [[[cd,3]]], CalDAV Draft http://ietfreport.isoc.org/all-ids/draft-dusseault-caldav-08.txt + +* [[[rfc2445,RFC 2445]]] + +* [[[rfc2446,RFC 2446]]] + +* [[[tzdb,6]]], TZ Database (Olson) http://www.twinsun.com/tz/tz-link.htm diff --git a/sources/cc-0603-report-ioptest/document.adoc b/sources/cc-0603-report-ioptest/document.adoc new file mode 100644 index 0000000..4f936bb --- /dev/null +++ b/sources/cc-0603-report-ioptest/document.adoc @@ -0,0 +1,422 @@ += January 2006 CalConnect Interoperability Test Report +:docnumber: 0603 +:copyright-year: 2006 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2006-02-09 +:published-date: 2006-02-09 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Patricia Egen +:role: author +:fullname_2: David Nuttell +:role_2: author +:fullname_3: Dave Camp +:role_3: author +:fullname_4: Joey Minta +:role_4: author +:fullname_5: Grant Baillie +:role_5: author +:fullname_6: Simon Vaillancourt +:role_6: author +:fullname_7: Chuck Norris +:role_7: author +:fullname_8: Dan Markham +:role_8: author +:fullname_9: Dan Hickman +:role_9: author +:fullname_10: Mike Douglass +:role_10: author + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Introduction + +The following document contains notes and results from the January 2006 calendar +interoperability event held at the Novell complex in Provo, Utah. + +The chart below shows the attendees, their organization and the products they were testing. + +=== Attendees + +[%unnumbered,options=header] +|=== +| Attendees | Organization | Products +| Chuck Norris | EVDB | CALDAV server +| Danny Markham | EVDB | CALDAV server +| Joey Minta | Mozilla | Mozilla client +| Dave Camp | Novell | Hula, Evolution +| Dave Nuttell | Novell | Groupwise +| Simon Vaillancourt | Oracle | Oracle CALDAV server +| Grant Bailey | OSAF | Chandler and Cosmo +| Mike Douglass | RPI | RPI CALDAV Server +| Dan Hickman | Trumba | OneCalendar +|=== + +== General Comments + +After introductions there were general discussions about testing and requirements for suites. The +Open Source tool, iCal 4J, does have a parser so we are considering pointing people at already-developed +implementations for testing iCalendar streams. + +We talked about the concept of using a public CALDAV server to help test calendar objects. +This server and suite would need to do the following tasks: Import events, do some actions, +export and compare. It would then present the final state to the tester. A good parser will test +and decompile into components. + +The purpose of this test event was to test CALDAV clients and servers and iCalendar +implementations. Exhibit A are the test scenarios used for iCalendar testing. All products tested +during this event are "not shipping application." Therefore, in this pubic document, we do not +explicitly name products or note how each product works. Comments are general and generic. +To help differentiate notes, we have named the participants as Vendor one, Vendor two, Vendor +three, Vendor four, Vendor five, Vendor six and Vendor 7. + +== Vendor Notes and Comments + +The following are various notes, including comments provided by vendors that reflect their +findings and thoughts from the interoperability event. + +The CALDAV server implementations had the easiest task at the event. Their job was to ensure +the servers were available and to monitor the traffic from the various clients. As clients sent +requests, various bugs were fixed and added to list of items that need to be repaired. + +Several clients went through the CALDAV scenarios (details are attached to this report). Each +time we hold the interoperability events, we uncover more bugs that each client and server +repairs. + +One thing noted was a difference in CALDAV specifications within products. The spec is now +at version 8; however, some of the other clients and/or server were still only at version 7. This +caused some things to not be able to be tested at this event. However, this is common when a +draft is not a finalized RFC. + +Some servers imported timezones well. Recurrence is not working yet for some of the clients. +This shows how two vendors have two different interpretations of the same object. + +One vendor had a few problems with timezone ids. They appeared to be too verbose for their +product. There were little issues with starts and ends. The vendor said it was helpful to hear +other issues. + +Not every client supports RFC 2446 or 2447. These are the scheduling and email transport +protocols. In general, it seemed that the majority of clients did not have much support for +attendees, and as such, a vast portion of the testing scenarios were not applicable. + +Vendor one noted they lack implementations of some of the more complex `RRULE` (like +BySETPOS), and struggled with overridden instances of recurring events. Publishing and +subscribing seemed to work quite well with all clients. Their CalDAV support is rather limited +at this stage, but they were able to do basic event adding/deleting with all servers except for one. +That vendor was running a different version of the spec, and as such, could not return their +queries. + +Vendor two reported the following items: + +* They currently support import and export of RFC 2445 iCalendar objects and also allow +clients to publish and subscribe to calendars via Webdav. +* Calendar objects from Vendor three were successfully published and subscribed to their +calendars via Webdav. Webdav connectivity worked quite well. +* They noted that they were not able to map Vendor one's ``TZID``s to their timezones. +* In this case, timezones were interpreted in UTC. +* Their floating dates and all day events imported correctly into another vendor's product. +* They also successfully mapped the other vendor's timezones to their internal timezones. +* Their application did not correctly import private event status (`CLASS:PRIVATE`). This +has since been fixed. +* Vendor four noted that importing their ics object into Vendor two's application worked +well. Currently Vendor four does not support recurrence or timezones. +* Importing one time event ics objects from Vendor five worked correctly. The sample +recurring event instance provided from Vendor five included multiple `DTSTART` +properties which is not valid and could not be imported. Importing their recurring events +into Vendor five's application worked for the most part. Import of a rescheduled +occurrence of a recurring event left the original date in addition to the new date/time in +Vendor five's application. +* When importing Vendor six's ics files, timezone ID's were not correctly mapped to their +timezones. They had to implement enhanced mapping logic. Imported recurrence +samples worked very well with all rescheduled events importing properly. Export of +Vendor six's client recurring event did not import correctly. The master event included +only `RDATE` objects to specify recurrence set and did not include an `RRULE` which is +not currently supported by Vendor two. +* Vendor seven provided four sample ics files which all successfully imported. Examples +included multiple timezones, all day events and recurrence. Vendor two exports include +a custom attribute in the `VTIMEZONE` component which caused issues when importing +into Vendor seven's application. These should be ignored. + +Vendor seven reported the following items: + +* A couple of bugs relating to Vendor eight's handling of recurring events and ``EXDATE``s. +* An issue where they were ``PROPPATCH``'ing calendar collections (to set their display +names). However, not all servers support this, and they need to ignore returned errors in +this case. +* A couple of Vendor five problems that were fixed, allowing tests to proceed. +* A issue where they do not correctly interpret an empty multistatus response to a +`PROPFIND` (Vendor five does this, and it's allowed by the WebDAV spec), leading to a +failure in creating calendar collections. +* Updating events on Vendor six is broken right now, apparently because of a known issue +with Vendor seven not preserving X-properties. +* They are unable to parse .ics files from Vendor two - (a bug in the way we parse +`VTIMEZONE`). +* Some of the other vendors noticed that they are exporting events in UTC timezone +incorrectly. +* A couple of bugs in their subscription to http: ics URLs were uncovered. +* There were initially some problems with Vendor five's client that turned out to be a result +of client and server having implemented different versions of the CalDAV spec. +* Vendor five updated their calendar-query ``REPORT``s to match the latest spec, but was +unable to retrieve events from our application. This was tracked down to being an +indexing issue, and was fixed. Subsequently, the testing ran OK. +* After the above fix, Vendor three had similar behavior retrieving events. It turned out +this was a result of ``PUT``-ing illegal iCalendar data (an empty `STATUS` value in a +`VEVENT`). Vendor three worked around the problem, and was able to proceed. However, +our application should have rejected the initial `PUT` request: This problem is being +investigated. + +Vendor five reported the following items: + +* Vendor five more interested in finding out what worked and what didn't than in actually +following the test scenarios. So the matrix was filled in with what seemed to work and +where problems were found. +* Most of the other vendors didn't actually send invitations but rather sent emails with the +ICS file attachments that were then imported. Therefore there was not a lot of Accept and +Decline testing done. Delegate, Counter and Reschedule was not tested with any vendors. +* They felt it was very helpful and they are busy working on the problems they found. +* They noted that their CALDAV implementation has problems with "@" in URLs. It also +isn't happy with `PUT` not returning an `ETAG`. +* Their CALDAV application had problems with Vendor six's Auto-added organizer. +* Vendor eight doesn't add a "calendar-access" DAV header. + +== Summary + +Once again, this was a good event. We tried a new approach for testing -- instead of trying to +work through any bugs, we decided to continue testing all items that we could and only go back +to fix bugs if they were holding up continuing with testing. This turned out to be a good +approach and we were able to get the majority of vendor products tested. + +Location turned out to be an important issue during the interop. Location appears to be useless +in iCalendar. Some clients use locations, some do not. There needs to be a definition of +properties that are absolutely required. Mozilla commented that they drop the location details on +their recurrence items. Everyone wanted to be able to ingest location items and then know what +to do with them. There may need to be extensions put in place within the specifications or via +the Calsify efforts to handle them. Xprops are what need to be enhanced/fixed/resolved. + +For the next interop, items to add to interop testing include: + +* how many people use the language property on iCalendar objects +* how many can support daily savings time changes that will happen in 2007 +* Free busy testing within CALDAV +* Tasks testing +* More testing of RFC2446 and RFC2447 scheduling events +* and the next phase of the CALDAV specification. + +Following this report are the test results for the scenario testing for both CALDAV and the +iCalendar specifications. + +My thanks to everyone who furnished their notes and results. + +Respectfully submitted, + +Pat Egen + +Interoperability Event Manager + +== Exhibit A - iCalendar Test Scenarios + +Basic test scenarios: + +[pseudocode%unnumbered] +==== +A: Non-repeating cases: + 1: User A PUBLISHes an event + 2: User A invites Users B, C, D & E to a meeting: + A: ATTACHments: + 1: 0 + 2: 1 + 3: 1+ + B: ALTREPs of: + 1: DESCRIPTION + 2: COMMENT + 3: CONTACT + 4: LOCATION + 5: RESOURCES + 6: SUMMARY + 7: iana-token (TBD usage but legal) + 8: x-token (TBD usage but legal) + C: Including ALARMs: + 1: AUDIO only + 2: DISPLAY only + 3: EMAIL only + 4: PROCEDURE only + 5: iana-token only (TBD value but non X- type) + 6: x-token only (TBD value but anything made up is ok) + 7+: Multiple alarm types (mix & match 1-6 above as desired) + D: COMMENTs: + 1: 0 + 2: 1 + 3: 1+ + E: CONTACTs: + 1: 0 + 2: 1 + 3: 1+ + F: ATTENDEE property parameters: + 1: CUTYPE: + A: INDIVIDUAL (Default) + B: GROUP + C: RESOURCE + D: ROOM + E: UNKNOWN + F: x-name (TBD case, perhaps SKiCAL?) + G: iana-token (TBD case) + H: Multiple values (Illegal case) + 2: MEMBER + A: 0 + B: 1 + C: 1+ + 3: ROLE: + A: CHAIR + B: REQ-PARTICIPANT (Default) + C: OPT-PARTICIPANT + D: NON-PARTICIPANT + E: x-name (TBD case, perhaps SKiCAL?) + F: iana-token + G: Multiple values (Illegal case) + 4: PARTSTAT: + A: NEEDS-ACTION (Default) + B: ACCEPTED + C: DECLINED + D: TENTATIVE + E: DELEGATED + F: x-name (TBD case, perhaps SKiCAL?) + G: iana-token + H: COMPLETED (Illegal for VEVENTs) + I: IN-PROCESS (Illegal for VEVENTs) + J: Multiple values (Illegal case) + 5: RSVP + A: TRUE + B: FALSE (Default) + C: Any other value (Illegal case) + D: Multiple values (Illegal case) + 6: DELEGATED-TO + A: 0 + B: 1 + C: 1+ + 7: DELEGATED-FROM + A: 0 + B: 1 + C: 1+ + 8: SENT-BY + A: 0 + B: 1 + C: 1+ (Illegal case) + 9: CN + A: 0 + B: 1 + C: 1+ (Illegal case) + 10: DIR + A: 0 + B: 1 + C: 1+ (Illegal case) + 3: User B Accepts the invitation: + A: but then Declines the invitation: + B: but then requests a Refresh of the invitation: + 4: User C Declines the invitation: + A: but then Accepts the invitation: + B: but then requests a Refresh of the invitation: + 5: User D Counters with a new meeting time: + A: User A Declines the Counter: + B: User A Accepts the Counter and reschedules the meeting: + 6: User E Delegates to User G: + A: User G Accepts the invitation: + B: User G Declines the invitation: + C: User G requests a Refresh of the invitation: + D: User G Counters with a new meeting time: + E: User G Delegates to User I: + 7: User A reschedules the meeting: + Repeat permutations of 1-6 below here as necessary. + +B: Repeating cases: + (Repeat A. subcases but expand for instance manipulation including entire + set, 1 instance, THISANDPRIOR & THISANDFUTURE ranges + Tests should include the following permutations: + RDATEs only + RRULEs only + RDATEs and RRULEs + RDATEs & EXDATEs only + RRULEs & EXDATEs only + RDATEs & EXRULEs only + RRULEs & EXRULEs only + RDATEs, EXDATEs & EXRULEs + RRULEs, EXDATEs & EXRULEs + RDATEs, RRULEs & EXDATEs + RDATEs, RRULEs & EXRULEs + RDATEs, RRULEs, EXDATEs & EXRULEs +==== + +== Exhibit B - CALDAV Testing Scenarios + +[%unnumbered,cols=2] +|=== +h| 1. h| Event creation. +| 1.1. | Create new single-instance meeting titled "Meeting 1.1" with the location "Durham". +| 1.2. | Create new meeting titled "Meeting 1.2" recurring every Monday from 10:00 AM to 11:00 AM for 4 weeks. +| 1.3. | Create new single-instance meeting titled "Meeting 1.3" with 2 other attendees. +| 1.4. | Create new single-instance meeting titled "Meeting 1.4" with an alarm set to trigger 15 minutes prior to the schedule time of the meeting. +h| 2. h| Event modification +| 2.1. | Modify the title of meeting "Meeting 1.1" to "Meeting 1.1bis". +| 2.2. | Modify the location of the meeting "Meeting 1.1bis" to "Seattle bis". +| 2.3. | Reschedule meeting "Meeting 1.1bis" to the next day. +| 2.4. | Add an attendee to "Meeting 1.1bis". +| 2.5. | Add an alarm to "Meeting 1.1bis". +| 2.6. | Modify the title of the 1st instance of the recurring meeting created in 1.2. +| 2.7. | Modify the participation status of the 1st attendee in meeting 1.3 to `DECLINED`. +| 2.8. | Cancel the 4th instance of the recurring meeting created in 1.2. +| 2.9. | One client changes "Meeting 1.1bis" to a different time, second client 'refreshes' its display to see the modification. +h| 3. h| Event retrieval +| 3.1. | calendar-query `REPORT` +| 3.1.1. | No filtering (match everything) +| 3.1.1.1. | Query all components and return all data. (tests and ) +| 3.1.1.2. | Query all components and return ETag WebDAV property and all data. (tests + and ) +| 3.1.1.3. | Query all components and return just entire `VEVENT` components. (tests , +) +| 3.1.1.4. | Query all components and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests , +, ++) +| 3.1.2. | time-range filtering +| 3.1.2.1. | Query all components within a one day time-range and return all data. Make sure that there is a recurring event that starts prior to the chosen time-range but has one non-overridden instance within the time-range. (tests , +) +| 3.1.2.2. | Query all components within a one week time-range and return just entire `VEVENT` components. Make sure that there is a recurring event that starts prior to the chosen time-range but has one overridden instance within the time-range. (tests , +) +| 3.1.3. | component based filtering +| 3.1.3.1. | Query all components that contain an embedded `VALARM` component. (tests , +) +| 3.1.3.2. | Query all components that contain an embedded `VALARM` component whose trigger falls within a specific time-range. (tests , +++) +| 3.1.4. | property based filtering +| 3.1.4.1. | Query all components that contain any `ORGANIZER` property. (tests , ++) +| 3.1.4.2. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-insensitively. (tests , +++) +| 3.1.4.3. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-senstively. (tests , +++) +| 3.1.5. | parameter based filtering +| 3.1.5.1. | Query all components that contain a `DTSTART` property with a `TZID` parameter. (tests , ++++) +| 3.1.5.2. | Query all components that contain an `ATTENDEE` property with `PARTSTAT=NEEDS-ACTION` parameter. (tests , ++++) +| 3.2. | calendar-multiget `REPORT` +| 3.2.1. | Query a specific href and return all data. (tests ) +| 3.2.2. | Query multiple hrefs (some of which do not exist) and return all data. (tests ) +| 3.2.3. | Query a specific href and return ETag WebDAV property and all data. (tests +) +| 3.2.4. | Query multiple hrefs (some of which do not exist) and return ETag WebDAV property and all data. (tests +) +| 3.2.5. | Query a specific href and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests , ++) +| 3.2.6. | Query multiple hrefs (some of which do not exist) and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests , ++) +h| 4. h| Event deletion +| 4.1. | Delete a single non-recurring meeting. +| 4.2. | Delete a single recurring meeting with no overridden instances. +| 4.3. | Delete a single recurring meeting with overridden instances. +| 4.4. | Delete a non-overridden instance of a recurring meeting. +| 4.5. | Delete an overridden instance of a recurring meeting. +h| 5. h| Access Control +| 5.1. | View access control details on current user's main calendar. +| 5.2. | Change access control details on current user's main calendar to add another user with read-only access. Verify that other user can view the calendar but not change it. +| 5.3. | Change access control details on current user's main calendar to add another user with read-write access. Verify that other user can view the calendar and change it. Verify that changes done by one user are seen by the other. +| 5.4. | Remove another user's access to the current user's main calendar and verify they can no longer access the calendar. +h| 6 h| Calendar Management +| 6.1 | Browse the list of calendars on the server, including the current user's personal calendars. +| 6.2 | Create a new calendar in the current user's personal calendar space. +| 6.3 | Create a regular collection in the current user's personal calendar space. +| 6.4 | Create a new calendar inside the collection created in 6.3. +| 6.5 | Delete the calendar created in 6.2. +| 6.6 | Delete the collection created in 6.3. +|=== diff --git a/sources/cc-0604-ical-recurrence-problems/document.adoc b/sources/cc-0604-ical-recurrence-problems/document.adoc new file mode 100644 index 0000000..af9e713 --- /dev/null +++ b/sources/cc-0604-ical-recurrence-problems/document.adoc @@ -0,0 +1,651 @@ += iCalendar Recurrence Problems and Recommendations +:docnumber: 0604 +:copyright-year: 2006 +:language: en +:doctype: report +:edition: 1 +:status: published +:revdate: 2006-03-16 +:published-date: 2006-03-16 +:technical-committee: RECURR +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Chris Stoner +:affiliation: IBM +:role: editor +:email: cstoner1@us.ibm.com + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Introduction + +This document contains information about recurrence implementation issues and +recommendations on how to resolve these issues. We first explain what recurrences are, +justify the need for recurrences, identify recurrence implementation problems and +ambiguities, and then offer some guidelines and recommendations to solve these +issues. + +== What are recurrences and why do we need them? + +The word "recurrence" in iCalendar refers to the ability of an event to repeat, i.e. +schedule a meeting to occur every Wednesday for the next 3 weeks. This sort of +scheduling can be represented in iCalendar using a recurrence rule. +The purpose of using the recurrence properties is to have the ability to transmit many +related event dates in a single transaction. For example, it is possible to create a +recurring meeting that will repeat every day for 5 days in one transaction to the invitee +list, instead of sending five transactions (one for each day) to the invitee list. +Recurrence properties also offer synchronization from desktop to mobile device, for +example, a way to quickly send information about many related event dates in a single +transaction. + +The receiver expands the rule to display the actual dates during processing. + +== Recurrence Issues with iTIP + +There are some ambiguities in iCalendar that have led some implementers to interpret +the same iCalendar stream in very different ways. This difference in interpretation has +lead to low interoperability of some of the features of recurrences. + +=== How should recurrence modifications be handled? + +==== {blank} + +There are interoperability problems when the sender is attempting to +reschedule an entire event, but does not send recurrence properties and +does not wish to replace the recipients set with the new set. The sender +is trying to simply move the set from one time to another (1pm to 2pm), +adjust duration, etc. A simple example would be a recurring meeting that +is currently from 1pm to 2pm, that is being rescheduled to 4pm to 5pm, +for all instances. Implementers might not want to lose the recipient's +changes, personal notes, and updates to the set by replacing their set +with what's received. + +==== {blank} + +There are additional interoperability problems when a sender attempts to +reschedule a recurrence set with a new rule, which should replace the +existing rule. An example would be a recurring meeting that follows one +rule pattern, say daily for 5 days, and is replaced with another rule pattern +that may or may not match the original number of instance, say weekly for +3 weeks. + +=== When should the `ADD` method be used? + +==== {blank} +There's some ambiguity in iTIP involving when these properties: `RRULE`, +`EXRULE`, `RDATE`, `EXDATE` and some others of the master instance +should be sent to the recipient. It's unclear if the master instance +properties should be sent to the recipient during an `ADD`. + +=== How should the scheduling of an unbounded rule be solved? + +==== {blank} +Since there is no limit to the set of recurrences, it's unclear what is +expected to happen when scheduling, e.g. how can an attendee verify +that they are free or busy for each event in the unbounded (infinite) set? + +=== Can unbounded rules be truncated? + +==== {blank} +It's unclear what an implementer should do if unbounded rules do not fit +the business case the application was written for, i.e. if the iCalendar +stream contains an unbounded rule that repeats every second forever. If +the implementer's application expands ``RRULE``s upon receiving them, it's +unclear if it's acceptable to truncate and what response, if any, should go +back to the sender. + +=== How should calendar objects occurring during a daylight time change be handled? + +==== {blank} +It's unclear what should happen if an iCalendar object occurs during a +daylight time change, like April 4, 2005 at 2am EST, what should +happen? + +=== If an event is set to repeat on the 31st of each month, what do you do in months with fewer than 31 days? + +==== {blank} +Should the instance roll to the next day or be dropped? + +=== How do we create a rule that excludes weekends and holidays? + +==== {blank} +It's unclear how to describe the sender's idea of holidays (say US +holidays) when the recipient could have a different holiday set (say Israeli +holidays). + +== Recommendations for iTIP + +=== Recurrence properties modifications + +==== {blank} +To reschedule an event to a set of explicit dates/times but not replace the +set with a new rule pattern, the sender should send a set of components +with `RECURRENCE-ID` being set in each to handle the explicit override of +the rule's date/time. + +==== {blank} +If an `RRULE` is changed, then the entire iCalendar object should be resent +in the reschedule. This tells the receiver that all exceptions should +be removed and replaced with this new rule. The new `RRULE` properties +are required in order for the recipient to know that they need to replace +the set they have with the incoming set. + +===== {blank} +In iTIP there is currently the possibility of adding an `RRULE` to an +event using the `ADD` method, discussions about this should be +brought to a public forum. See next topic for details on the `ADD` +method. + +=== When should the `ADD` method be used? + +==== {blank} +The `ADD` method should only be used to add occurrences to an existing +calendar object, the supplied `VEVENT`/`VJOURNAL`/`VTODO` component +data must not contain these properties: `RRULE`, `EXRULE`, `RDATE`, +`EXDATE` (and all other properties that can only be in the master +instance). Currently iTIP does allow recurrence properties in an ADD +method's data. + +=== How should the scheduling of an unbounded rule be solved? + +==== {blank} +A free busy request must always have a start and end date, only the +occurrences of the unbounded rule that match the free busy request timerange +should be expanded. + +=== Can unbounded rules be truncated? + +==== {blank} +The implementer can truncate an unbounded rule if unbounded rules do +not fit the business case the application was written for. The implementer +must however make sure that when that calendar object is exported, the +original rule is preserved; a warning could also be issued indicating that +the calendar object was truncated. + +==== {blank} +The application truncating an incoming calendar object could implement +an internal mechanism that would send an iTIP refresh request to the +organizer requesting additional occurrences as time goes by. + +=== How should calendar objects occurring during a daylight saving time change be handled? + +==== {blank} +An explicit instance specified using an `RDATE` with a `PERIOD` value +should be used to fix the required duration for the event spanning the +daylight saving time change. + +=== If an event is set to repeat on the 31st of each month, what do you do for months with fewer than 31 days? + +==== {blank} +The instance needs to be dropped as specified in <>. + +=== How do we create a rule that excludes weekends and holidays? + +==== {blank} +Use `BYDAY` without specifying Saturday and Sunday and use ``EXDATE``s to remove holidays. + +=== Implementations without `RRULE` support + +==== {blank} +A new iTIP response could be created indicating to a sender that the +recipient does not support ``RRULE``s, the sender could then decide to +"explode" the calendar object into ``RDATE``s and send that `RRULE`-less +calendar object. A link to `RRULE` processing reference table and `FREQ` +example streams can be found at the end of this document. + +== Recurrence Issues with iCalendar + +=== Usefulness vs. Cost of implementation of some properties + +==== {blank} +Some of the `RRULE` grammar is cumbersome and difficult to use. + +==== {blank} +Some of the `RRULE` grammar is not needed for human-interaction +systems. + +== Recommendations for iCalendar + +=== Usefulness vs. Cost of implementation of some properties + +==== {blank} +Further discussions on public forums are needed about the usefulness of +the following properties and if there could be simpler ways to solve the +use cases they were made for: + +===== {blank} +`EXRULE` -- This recurrence property is cumbersome to use and the +equivalent can be generated with a list of ``EXDATE``s. This property +could be removed for better interoperability. + +===== {blank} +`BYSECOND` -- This recurrence rule part is not useful in a human-interaction +system and since that is our target, not automated +systems, this rule part should be removed for better interoperability. + +====== {blank} +How to handle seconds if they are received? If a client receives +an `RRULE` with a `DTSTART` that has non-zero seconds, the +client can ignore the seconds without having to round up, which +might have pushed the time into the next hour or day. + +===== {blank} +`BYSETPOS` - This `RRULE` property is useful in that it has the +"payday" use case, ie. last workday of the month, but can be +complicated to implement. The sender could use ``RDATE``s as well but +could be a lengthy list if this goes on yearly, etc. It is better to send a +list of ``RDATE``s with exceptions already taken into account, and +refresh this at appropriate intervals to extend the set. If that is +recommended in the RFC, then this property could be removed. +Recommend going to the `CALSIFY` list to see if this is deemed a +workable solution. + +===== {blank} +Multiple ``EXRULE``s and ``RRULE``s -- These properties combined are +complicated to implement, are not supported by many implementers, +so support for multiple ``EXRULE``s and ``RRULE``s should be removed +from the iCalendar RFC and related memos. + +== Best Practices + +=== When should the `SEQUENCE` value change? + +==== {blank} +The `SEQUENCE` value should be changed when the date, time, or +duration of one or more instances, of the master instance, change. This +refers to a scheduling time change, say a meeting that was from 1pm to +2pm is being rescheduled to 3pm to 4pm. + +==== {blank} +The `SEQUENCE` value should not be changed when the only properties +that are changed are those not having to do with meeting date, time, or +duration change. This refers to changing `SUMMARY` or `LOCATION`, for +example. When changing these properties, it's best not to change the +`SEQUENCE` value if a meeting time change is not also involved in the +update. The `SEQUENCE` value is used to denote a date, time, or +duration change; not a change in other properties. + +===== {blank} + +[example] +Chair sends out a 3 day recurring meeting that repeats +Monday through Wednesday. Chair later changes the `LOCATION` for +all the instances, but did not change the date, time, or duration. The +receiver will note the `SEQUENCE` value has not changed, and can +simply apply the other properties sent to the recurrence set. If the +sender had changed the `SEQUENCE` value, the receiver could +believe this to mean a date, time, or duration change, and attempt to +apply a reschedule to the set when one did not occur. + +=== {blank} +If you want to reschedule the first instance, you'd send `DTSTART` and +`DTEND`, `RECURRENCE-ID`, and `UID`. (iTIP) + +=== {blank} +Reschedules occur in two different varieties (iTIP), rescheduling where the +`RECURRENCE-ID` is supposed to be changed and when `RECURRENCE-ID` +is not supposed to change. + +==== {blank} +Rescheduling of one or more instances where `RECURRENCE-ID` is not +subject to change. In this case, recurrence properties are not sent, so the +receiver is expected to keep the current recurrence set and simply +reschedule what's already on the calendar to different dates/times. + +===== {blank} +Single Instance example: Chair sends out a 5 day recurring meeting +that repeats Monday through Friday. Chair later reschedules only +Wednesday to a different time. The Wednesday instance should +retain it's original `RECURRENCE-ID`; this property should not be +updated. + +===== {blank} +Many instance example: Chair sends out a 5 day recurring meeting +that repeats Monday through Friday. Chair later reschedules +Wednesday and Thursday to a different time. The Wednesday and +Thursday instances should retain their original `RECURRENCE-ID`; +this property should not be updated. + +==== {blank} +Rescheduling of the entire set, where `RECURRENCE-ID` is expected to +change. In this case, recurrence properties are sent, so that the receiver +is expected to replace the existing recurrence set with the incoming set. + +===== {blank} + +[example] +Chair sends out a 5 day recurring meeting that repeats +Monday through Friday. Chair later reschedules the entire event to +follow a different rule pattern; this time weekly for 5 weeks on +Monday. All of the instances should be replaced with new instances +containing data from the master that was sent, with new +`RECURRENCE-ID` properties generated for each. + +==== {blank} +Why not always update `RECURRENCE-ID`? Since `RECURRENCE-ID` is +our key to find that particular instance, it should not be changed unless +the entire set is being replaced. The reason is best explained with an +example: Chair sends out a 5 day recurring meeting, Monday thru Friday, +from 9am to 10am. Chair later reschedules Wednesday to be from 1pm +to 2pm. One of their recipients does not receive the reschedule for +Wednesday. Chair reschedules Wednesday again this time from 3pm to +4pm. If the `RECURRENCE-ID` was changed during the 1-2pm +reschedule, then the recipient will not be able process this reschedule or +any subsequent reschedules or updates. That `RECURRENCE-ID` will +never match any instances on their calendar. + +=== {blank} + +When processing a `RANGE` that is set to `THISANDFUTURE` for recurrences, +the order in which components have been overridden must be used to define +which instances are affected by `THISANDFUTURE`. For example, say an +event has three instances A, B and C. If B is overridden with a component +with a `RANGE=THISANDFUTURE` parameter, then both B and C will be +affected by the change. However, if C were subsequently changed, the +change to C would not incorporate the changes done in B. Alternatively, if C +was overridden first, and then B overridden with `THISANDFUTURE`, then the +changes in B would be incorporated into C. Note that this means that the +overridden component for C is effectively not used. + +== Conclusion + +In conclusion, this document has attempted to trim recurrences to a subset of features +that are common to implementations in the market, offer real value in the end result +product, and would be deemed require functionality to the end user. Additional +modifications that could be discussed for the new drafts are: + +. Are multiple ``RRULE``s and ``EXRULE``s really useful, could we do without them? +. Are ``EXRULE``s really useful, could we do without them? +. Removal of `THISANDPRIOR`, since `THISANDPRIOR` always refers to a finite +number of occurrences it could be done with exceptions. + +[[appendixA]] +[appendix] +== `RRULE` Processing + +A particular `BYxxx` rule part may expand or limit the set of date/times +generated by the rule. The expand or limit behaviour is governed by the `FREQ` +value used for the rule. + +[example] +==== +`RRULE:FREQ=MONTHLY;BYMONTH=1,3,5;BYDAY=MO,TU` + +The `FREQ=MONTHLY` value would match each of the twelve +months in a year. + +The `BYMONTH=1,3,5` rule part limits the matching months to just +the 1st, 3rd and 5th in a year. + +The `BYDAY=MO,TU` rule part adds each Monday and Tuesday within +the matching months to the recurrence set. +==== + +The table below shows the dependency of `BYxxx` rule part expand or limit +behaviour on the `FREQ` value in the rule. When evaluating a rule, each `BYxxx` +rule part must be evaluated in the order it appears in the table (i.e. `BYMONTH` +evaluated before `BYWEEKNO`), irrespective of the expand or limit behaviour. + +`BYDAY` has some special behaviour depending on the `FREQ` value and this is +described in separate notes below the table. + +[%unnumbered,cols=8] +|=== +| | `SECONDLY` | `MINUTELY` | `HOURLY` | `DAILY` | `WEEKLY` | `MONTHLY` | `YEARLY` +| `BYMONTH` | Limit | Limit | Limit | Limit | Limit | Limit | Expand +| `BYWEEKNO` | Limit | Limit | Limit | Limit | Limit | N/A | Expand +| `BYYEARDAY` | N/A | N/A | N/A | N/A | N/A | N/A | Expand +| `BYMONTHDAY` | Limit | Limit | Limit | Limit | N/A | Expand | Expand +| `BYDAY` | Limit | Limit | Limit | Limit | footnoteblock:[note1] | footnoteblock:[note2] | footnoteblock:[note3] +| `BYHOUR` | Limit | Limit | Limit | Expand | Expand | Expand | Expand +| `BYMINUTE` | Limit | Limit | Expand | Expand | Expand | Expand | Expand +| `BYSECOND` | Limit | Expand | Expand | Expand | Expand | Expand | Expand +| `BYSETPOS` | Limit | Limit | Limit | Limit | Limit | Limit | Limit +|=== + +[[note1]] +[NOTE] +-- +Special expand for `WEEKLY`. + +A `BYDAY` rule part cannot have a numeric value in a +`FREQ=WEEKLY` rule (i.e. '`MO`', '`TU`' etc is allowed, but +'`1MO`', '`2TU`' is not allowed). +-- + +[[note2]] +[NOTE] +-- +Limit if `BYYEARDAY` or `BYMONTHDAY` is present, +otherwise special expand for `MONTHLY`. + +The numeric value in a `BYDAY` rule part in a `FREQ=MONTHLY` +rule corresponds to an offset with the month. +-- + +[[note3]] +[NOTE] +-- +Limit if `BYYEARDAY` or `BYMONTHDAY` is present, +otherwise special expand for `WEEKLY` if `BYWEEKNO` present, +otherwise special expand for `MONTHLY` if `BYMONTH` present, +otherwise special expand for `YEARLY`. + +A `BYDAY` rule part cannot have a numeric value in a +`FREQ=YEARLY` rule (i.e. '`MO`', '`TU`' etc is allowed, but +'`1MO`', '`2TU`' is not allowed), if `BYWEEKNO` is specified. + +The numeric value in a `BYDAY` rule part in a `FREQ=YEARLY` +rule with a `BYMONTH` present corresponds to an offset with +the month. + +The numeric value in a `BYDAY` rule part in a `FREQ=YEARLY` +rule without `BYWEEKNO` or `BYMONTH` present corresponds to +an offset within the year. +-- + +[[appendixB]] +[appendix] +== Recurrence `FREQ` Examples + +.Monthly by Day: Every Month on the 1st Monday for 5 months +[example] +==== +[source%unnumbered] +---- +BEGIN:VCALENDAR +X-LOTUS-CHARSET:UTF-8 +VERSION:2.0 +PRODID:-//Lotus Development Corporation//NONSGML Notes 7.0//EN +METHOD:REQUEST +BEGIN:VTIMEZONE +TZID:Eastern +BEGIN:STANDARD +DTSTART:19501029T020000 +TZOFFSETFROM:-0400 +TZOFFSETTO:-0500 +RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=-1SU;BYMONTH=10 +END:STANDARD +BEGIN:DAYLIGHT +DTSTART:19500402T020000 +TZOFFSETFROM:-0500 +TZOFFSETTO:-0400 +RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=1SU;BYMONTH=4 +END:DAYLIGHT +END:VTIMEZONE +BEGIN:VEVENT +DTSTART;TZID="Eastern":20100802T100000 +DTEND;TZID="Eastern":20100802T110000 +TRANSP:OPAQUE +RRULE:FREQ=MONTHLY;COUNT=5;BYDAY=1MO +DTSTAMP:20050822T203750Z +SEQUENCE:0 +ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN="Chris Stoner/Westford/IBM" +;RSVP=FALSE:mailto:Chris_Stoner@notesdev.ibm.com +ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE +:mailto:green_jellybean@mac.com +CLASS:PUBLIC +DESCRIPTION;ALTREP="CID:" +:Every Month on the 1st Monday for 5 months +SUMMARY:FREQ =BYMONTH Limit Example +ORGANIZER;CN="Chris Stoner/Westford/IBM" +:mailto:Chris_Stoner/Westford/IBM@ +UID:A8398E9A6BBE453F8525706500712C84-Lotus_Notes_Generated +END:VEVENT +END:VCALENDAR +---- +==== + +[example] +.Monthly By Day Expand Example: Every month on the 6th day +==== +[source%unnumbered] +---- +BEGIN:VCALENDAR +X-LOTUS-CHARSET:UTF-8 +VERSION:2.0 +PRODID:-//Lotus Development Corporation//NONSGML Notes 7.0//EN +METHOD:REQUEST +BEGIN:VTIMEZONE +TZID:Eastern +BEGIN:STANDARD +DTSTART:19501029T020000 +TZOFFSETFROM:-0400 +TZOFFSETTO:-0500 +RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=-1SU;BYMONTH=10 +END:STANDARD +BEGIN:DAYLIGHT +DTSTART:19500402T020000 +TZOFFSETFROM:-0500 +TZOFFSETTO:-0400 +RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=1SU;BYMONTH=4 +END:DAYLIGHT +END:VTIMEZONE +BEGIN:VEVENT +DTSTART;TZID="Eastern":20100906T100000 +DTEND;TZID="Eastern":20100906T110000 +TRANSP:OPAQUE +RRULE:FREQ=MONTHLY;COUNT=5;BYMONTHDAY=6 +DTSTAMP:20050822T204655Z +SEQUENCE:0 +ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN="Chris Stoner/Westford/IBM" +;RSVP=FALSE:mailto:Chris_Stoner@notesdev.ibm.com +ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE +:mailto:gb@foo.com +CLASS:PUBLIC +DESCRIPTION;ALTREP="CID:": +Every month on the 6th day +SUMMARY:Every month on the 6th day +ORGANIZER;CN="Chris Stoner/Westford/IBM" +:mailto:Chris_Stoner/Westford/IBM@ +UID:9DF697E752368AE78525706500721DC4-Lotus_Notes_Generated +END:VEVENT +END:VCALENDAR +---- +==== + +[example] +.Daily every other day for 5 days +==== +[source%unnumbered] +---- +BEGIN:VCALENDAR +X-LOTUS-CHARSET:UTF-8 +VERSION:2.0 +PRODID:-//Lotus Development Corporation//NONSGML Notes 7.0//EN +METHOD:REQUEST +BEGIN:VTIMEZONE +TZID:Eastern +BEGIN:STANDARD +DTSTART:19501029T020000 +TZOFFSETFROM:-0400 +TZOFFSETTO:-0500 +RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=-1SU;BYMONTH=10 +END:STANDARD +BEGIN:DAYLIGHT +DTSTART:19500402T020000 +TZOFFSETFROM:-0500 +TZOFFSETTO:-0400 +RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=1SU;BYMONTH=4 +END:DAYLIGHT +END:VTIMEZONE +BEGIN:VEVENT +DTSTART;TZID="Eastern":20100906T100000 +DTEND;TZID="Eastern":20100906T110000 +TRANSP:OPAQUE +RRULE:FREQ=DAILY;COUNT=3;INTERVAL=2 +DTSTAMP:20050822T204514Z +SEQUENCE:0 +ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN="Chris Stoner/Westford/IBM" +;RSVP=FALSE:mailto:Chris_Stoner@notesdev.ibm.com +ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE +:mailto:green_jellybean@foo.com +CLASS:PUBLIC +SUMMARY:Daily every other day +ORGANIZER;CN="Chris Stoner/Westford/IBM" +:mailto:Chris_Stoner/Westford/IBM@ +UID:FACE7CA46BE8B3F3852570650071F380-Lotus_Notes_Generated +END:VEVENT +END:VCALENDAR +---- +==== + +[example] +.Daily every day for 5 days +==== +[source%unnumbered] +---- +BEGIN:VCALENDAR +X-LOTUS-CHARSET:UTF-8 +VERSION:2.0 +PRODID:-//Lotus Development Corporation//NONSGML Notes 7.0//EN +METHOD:REQUEST +BEGIN:VTIMEZONE +TZID:Eastern +BEGIN:STANDARD +DTSTART:19501029T020000 +TZOFFSETFROM:-0400 +TZOFFSETTO:-0500 +RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=-1SU;BYMONTH=10 +END:STANDARD +BEGIN:DAYLIGHT +DTSTART:19500402T020000 +TZOFFSETFROM:-0500 +TZOFFSETTO:-0400 +RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=1SU;BYMONTH=4 +END:DAYLIGHT +END:VTIMEZONE +BEGIN:VEVENT +DTSTART;TZID="Eastern":20100906T100000 +DTEND;TZID="Eastern":20100906T110000 +TRANSP:OPAQUE +RRULE:FREQ=DAILY;COUNT=5 +DTSTAMP:20050822T204315Z +SEQUENCE:0 +ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN="Chris Stoner/Westford/IBM" +;RSVP=FALSE:mailto:Chris_Stoner@notesdev.ibm.com +ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE +:mailto:green_jellybean@foo.com +CLASS:PUBLIC +SUMMARY:Daily every day for 5 days +ORGANIZER;CN="Chris Stoner/Westford/IBM" +:mailto:Chris_Stoner/Westford/IBM@ +UID:217C3BD27E9FDF9E852570650071C753-Lotus_Notes_Generated +END:VEVENT +END:VCALENDAR +---- +==== + +[bibliography] +== References + +* [[[rfc2445,RFC 2445]]] + +* [[[rfc2446,RFC 2446]]] diff --git a/sources/cc-0605-pres-omads-briefing/document.adoc b/sources/cc-0605-pres-omads-briefing/document.adoc new file mode 100644 index 0000000..9f6369a --- /dev/null +++ b/sources/cc-0605-pres-omads-briefing/document.adoc @@ -0,0 +1,409 @@ += OMA-DS CalConnect Liaison Briefing +:title-main-en: OMA DS - CalConnect Primer +:docnumber: 0605 +:copyright-year: 2006 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2006-04-05 +:published-date: 2006-04-05 +:technical-committee: CALCONNECT +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:imagesdir: images + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks +and Disclaimer of Warranty for External (Public) Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +Permission is granted to existing and potential members of the Consortium to reproduce and distribute this +presentation within their organizations so long as the presentation is not altered in any way and the Consortium is +acknowledged as the originator + +OMA DS Face-to-Face location:: Vancouver, British Colombia + +== What is CalConnect? + +=== What is the Consortium + +* "Provide a general understanding of, +promote, and provide mechanisms so that +Calendaring and Scheduling methodologies, +tools and applications can enter the +mainstream of computing" +* A Nonprofit Mutual Benefit Association +incorporated in the State of California +* Granted 501(‌c)6 tax-exempt status by the +Federal Government + +=== Why does it exist + +* Progress of Calendaring and Scheduling +standards seemed to be stalled +** Existing specifications insufficient and incomplete +** Existing products do not interoperate well +** Products continuing to diverge +* Need for a separate, focused environment to +take the next steps in Calendaring +** Establish value of C&S standards in the marketplace +** Help bring applications into mainstream use +* Help standards progress +** Promote use of current and new standards to vendor, +corporate and educational communities +** Influence how standards evolve +** Influence vendors to implement the standards +** CalConnect is not itself a standards body + +=== Goals of the Consortium + +* Promote Calendaring & Scheduling +* Interoperability testing and Certification +* Promote design & implementation of +* Calendaring & Scheduling Standards and +implementations +* Promote collaboration among members +* Support common goals of members +* Develop a shared vision for the Calendaring +& Scheduling community + +=== Technical Committees + +==== TC-CalDAV + +Define problems +CalConnect wishes to +solve with extensions to +WebDAV; assist IETF +with development of +CalDAV Specification + +==== TC-Authenticate + +Clarify issues involved +with authentication and +provide +recommendations + +==== TC-EVENTPUB + +Define event publishing +& establish differences +from regular +calendaring and +scheduling + +==== TC-IOP/TEST + +Support interoperability +testing for all technical +committees, develop +test suites & reference +implementation, publish +interop results + +==== TC-REALTIME + +Clarify issues involved +with real-time server-to-server +calendaring and +scheduling issues & +provide +recommendations + +==== TC-RECURR + +Review problems in +current alternative +approaches towards +handling recurrences & +recommend a preferred +approach or guidelines + +==== TC-TIMEZONE + +Identify requirements for +& a strategy to establish a +global timezone reference +available to CalDAV & +other calendaring and +scheduling server +implementations + +==== TC-USECASE + +Develop a set of real +world use cases that +can be used to validate +identified functionality & +testing scenarios for +existing & future C&S +implementations + +==== TC-MOBILE + +Identify the issues +associated with mobile +calendaring & +scheduling and propose +recommendations on +how to address any +problem areas + +=== Events + +. CalConnect Interoperability Testing Events (CITE) +** Participation open to members and non-members (significant discount +for members) +** Two day event co-located with Roundtable +** Results presented at relevant standards organization meetings +** Public version on Consortium website +. Roundtables +** "All hands" plenary meeting of membership +** Three per year midway between IETF meetings +*** help to drive each other +** Held in conjunction with Interoperability Testing Events +** Technical committee working meetings +** Steering Committee meeting +** Review and status of technical committees +** Special Workshops on selected topics of interest +** Consensus on direction, next steps of Consortium + +=== Founding Members + +[%unnumbered] +image::img01.png[] + +== Calsify + +=== TC Calsify versus Calsify + +TC started to support Calsify effort in IETF to develop +revisions of iCalendar and related specifications and +progress to standards. Function taken over by TC Chairs +now that Calsify working group established +within IETF. + +Anyone can participate in effort through the IETF. + +* General Discussion: ietf-calsify@osafoundation.org +* To Subscribe: http://lists.osafoundation.org/mailman/listinfo/ietf-calsify +* Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/ + +Current focus is on clarification (not simplification) +and they could use help. + +=== RFC 2445bis + +* http://www.ietf.org/internet-drafts/draft-ietf-calsifyrfc2445bis-00.txt +* Changes done so far mostly clerical to make +document more readable +* http://ietf.webdav.org/calsify/meetings/IETF65_CALSIFY.ppt +* http://www.calconnect.org/publications/icalendarrecurrenceproblemsandrecommendationsv1.0.pdf +* Are there issues related to sync that should be +considered? +** What needs to get done for implementers to jump from +vCal? + +=== CalConnect Interoperability Testing Events (CITE) + +CalConnect hosted testing sessions will help +push new drafts to full standard. + +OMA TestFest results could potentially help +with this as well (if more client vendors +switched from vCal to iCAL!!!!) + +== "Cardsify"? + +=== TC Cardsify + +As with TC Calsify such a TC could support a +Cardsify effort in IETF to develop revisions +of vCARD if it existed. + +Preliminary BOF Call hosted by CalConnect +held. +* Should this be considered within the scope of +CalConnect? +* Are there sufficient resources to make such a TC +viable (CalConnect is still a fairly small +organization)? +* Any issues from IMC? + +=== RFC2426bis? + +* Should effort be made? +** vCard is sort of calendar, sort of email, sort of +directory. It ends up falling through the crack and +no one takes real ownership. Effort seems well +overdue. +* Should CalConnect undertake Effort? +** New membership willing to actively work as part +of such a TC would need to be identified. +* OMA DS could equally shepherd such an +effort +* Any interested persons can submit draft of +new vCard to IETF. + +== Time zone registry and service + +=== TC Timezone + +* Technical Committee investigating the +problems with the usage of time zones. +* Findings published by CalConnect: +** iCalendar time zone problems and +recommendations +http://www.calconnect.org/publications/icalendartimezoneproblemsandrecommendationsv1.0.pdf +* Time zone registry and service +recommendations. +** To be published in April + +=== Standardized Time Zones + +Why are standardized time zones needed? + +* For improved interoperability: Calendar +applications need to have a reliable list of +time zones and their associated rules in +order to avoid the following common +problems: +** Consuming unknown time zones. +** Consuming known time zones with identical ``TZID``s +but different rule. +* Calendar applications need to have means +of updating time zones and all affected data +(i.e. previously created recurring meetings.) +in an efficient and correct manner. +* Having standardized time zones would open +the door to using time zones by reference +rather than by value (Sending only the time +zone id rather than the whole time zone +with its rules). This could potentially help +applications where bandwidth usage is +important such as mobile devices. +* Any other non-iCalendar products having to +deal with time zones could also benefit from +it (Operating systems, java...). + +=== Time zone registry + +What do we want (or not) in a time zone registry? + +* `TZID` and Rules should both be in a registry. +* Re-use what's already there (TZ Database). +* Versioning is not necessary, since time zone +changes occur in the future; existing events +shouldn't be affected by a new time zone. A +timestamp on each time zone should be +sufficient to cover most use cases. +* Final implementation should be done using a +standardized process, the new time zone +registry should be coordinated by IANA + +Who should publish? + +=== Time zone service + +What do we want (or not) in a time zone service? + +* The time zones should be in a `VTIMEZONE` +format as defined in RFC 2445. +* The time zone service should be built on top +of a known platform such as: HTTP, CalDAV, +DNS, or ITIP. +* The time zone service should be able to return +a time zone based on a supplied TZID and/or +`VTIMEZONE` object (Closest match). + +Who should host such services? + +== The future of mobile calendaring + +=== TC MOBILE + +Our goals are: + +* to identify the issues associated with mobile +calendaring & scheduling +* to propose a vision of what mobile calendaring +should be +* to propose recommendations on how to address +any problem areas +** For example, extensions or additions to existing standards +or profiles for mobile devices +** The recommendations are aimed at vendors and standards +developers + +We are keen to promote adoption of open +calendaring standards for mobile devices +(e.g. iCalendar, OMA DS, and CalDAV). + +=== TC MOBILE Questionnaire + +We have created a questionnaire on mobile +device capabilities. +The aim is to better understand what feature sets +are currently supported, and what is desired by +users. + +We will analyse the questionnaire results +and identify the gap between user needs +and current capabilities. + +The questionnaire is available at http://www.calconnect.org/mobileQs_v2.html. + +Results to be presented at Roundtable VI. + +=== Vision for mobile calendaring + +We are creating a 'Vision for interoperable +calendaring on mobile devices' + +* This document will describe how use cases +desired by users can be implemented using open +standards and identify new problems to be solved +* We are gathering user requirements through a +questionnaire and by organising discussions with +specific user groups +* We would like more participants from +organisations and vendors in the mobile industry + +=== How can you participate? + +OMA DS members can participate by: + +* completing our questionnaire on Mobile device +capabilities; +* attending the TC Mobile session at the CalConnect +May Round Table meeting. We would like for this +session to be a half day mobile calendaring +workshop. + +== What's Next? + +=== Looking for Feedback + +* Does OMA DS have any special +requirements for the Calsify Effort? +* Would OMA DS be supportive of a time zone +registry and service? +* Can OMA DS member companies commit to +helping along a Cardsify effort? +* Do OMA DS member companies have +thoughts on what they foresee as the future +of mobile calendaring? + +=== Roundtable VI + +* Roundtable VI -- 23-25 May 2006 +* Cambridge, MA +* Invitation to OMA DS to present feedback to +Consortium +* Planning session for half day mobile +calendaring workshop. diff --git a/sources/cc-0605-pres-omads-briefing/images/img01.png b/sources/cc-0605-pres-omads-briefing/images/img01.png new file mode 100644 index 0000000..bc9ca6f Binary files /dev/null and b/sources/cc-0605-pres-omads-briefing/images/img01.png differ diff --git a/sources/cc-0606-timezone-registry/document.adoc b/sources/cc-0606-timezone-registry/document.adoc new file mode 100644 index 0000000..1397a24 --- /dev/null +++ b/sources/cc-0606-timezone-registry/document.adoc @@ -0,0 +1,249 @@ += Timezone Registry and Service Recommendations +:docnumber: 0606 +:copyright-year: 2006 +:language: en +:doctype: standard +:edition: 1 +:status: published +:revdate: 2006-04-17 +:published-date: 2006-04-17 +:technical-committee: TIMEZONE +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Simon Vaillancourt +:affiliation: Oracle Corporation +:role: editor +:email: simon.vaillancourt@oracle.com + +== Introduction + +This document contains technical recommendations on implementing a time zone registry +and a time zone service. + +Why are standardized time zones needed? + +* For improved interoperability: Calendar applications need to have a reliable list of +time zones and their associated rules in order to avoid the following common +problems: +** Consuming unknown time zones. +** Consuming known time zones with identical ``TZID``s but different rule. +* Calendar applications need to have means of updating time zones and all affected +data (i.e.: Previously created recurring meetings.) in an efficient and correct manner. +* Having standardized time zones would open the door to using time zones by +reference rather than by value (Sending only the time zone id rather than the whole +time zone with its rules). This could potentially help applications where bandwidth +usage is important such as mobile devices. +* Any other non-iCalendar products having to deal with time zones could also benefit +from it (Operating systems, java...). + +== Time zone registry + +=== Implementation recommendations for a time zone registry + +[recommendation] +==== +[specification] +-- +The registry should contain both the name and the rules of the time zones. Storing only +the names of the time zones or the names of the rule would mean having some other sort +of registry to map these names to meaningful values. +-- +==== + +[recommendation] +==== +[specification] +-- +Leveraging what already exists in terms of time zone database should be seriously +considered in order to speed up the process of establishing the time zone registry +standard. As of now, the Olson Database seems to be the most widely used "source of +truth" in the software world. +-- +==== + +[recommendation] +==== +[specification] +-- +Adding a version per time zone is not seen as a requirement because time zone changes +usually occur in the future which means that past events will remain the same even if a +new rule is added to an existing time zone. A time stamp should be sufficient for most +use cases. +-- +==== + +[recommendation] +==== +[specification] +-- +Final implementation should be done using a standardized process, the new time zone +registry should be coordinated by IANA. +-- +==== + +[recommendation] +==== +[specification] +-- +Updates of the registry could be done through: RFC, informational RFC, +appointed/elected committee/individual who approves updates to the list. +-- +==== + +== Time zone service + +=== Implementation recommendations for a time zone service + +[recommendation] +==== +[specification] +-- +The time zone should be in a `VTIMEZONE` format as defined in RFC 2445. +-- +==== + +[recommendation] +==== +[specification] +-- +The time zone service should be build on top of a known platform such as: HTTP, +CalDAV, DNS, or ITIP. +-- +==== + +[recommendation] +==== +[specification] +-- +The time zone service should be able to return only modified time zones; given the last +time the time zone were fetched from the service and/or a list of ``TZID``-TimeStamp, return +the time zones that have changed. +-- +==== + +[recommendation] +==== +[specification] +-- +The time zone service should be able to return a time zone based on a supplied alias; +given an OS based time zone name, return the corresponding `VTIMEZONE` object. For +example: The windows time zone name:"(GMT -05:00) Eastern Time (US & Canada)" +would return the `VTIMEZONE` Object with the `TZID: "/IANA/America/New_York"`. +-- +==== + +[recommendation] +==== +[specification] +-- +The time zone service should be able to return a time zone based on a supplied `TZID`. +-- +==== + +[recommendation] +==== +[specification] +-- +The time zone service should be able to return a time zone based on a `VTIMEZONE` +object (Closest match). The "closest match" feature would be useful for consuming +iCalendar objects originating from applications that don't have any time zone service +knowledge. +-- +==== + +== Incremental implementation proposal + +Implementing a standardized time zone registry and service is no easy task. Here is a +tentative proposal on how it could be done incrementally by leveraging what already +exists. This is just describing how it could be done and is by no means set in stone. + +=== Milestone 1: Publish the registry file + +[recommendation] +==== +[specification] +-- +A group (Let's call it the TZ Group) agrees to generate a `VTIMEZONE` object file every +time a new TZDB (Olson database) file is released we'll cal that file the "TZ registry file". +-- +==== + +[recommendation] +==== +[specification] +-- +The TZ Group registers a domain name to host the TZ Group web site. This site is to be +used for the distribution of the newest "TZ registry file". +-- +==== + +=== Milestone 2: Define and setup the time zone service + +[recommendation] +==== +[specification] +-- +A new RFC is written using CalDAV as a base protocol, that draft would describe how to +search based on time zone ids, how to retrieve all time zones, how to return only time +zones whose time stamp has changed... +-- +==== + +[recommendation] +==== +[specification] +-- +Current implementers of CalDAV servers and clients implement their first iteration of the +new draft. +-- +==== + +[recommendation] +==== +[specification] +-- +The RFC draft becomes an official standard. +-- +==== + +[recommendation] +==== +[specification] +-- +Implementers release their applications. +-- +==== + +=== Milestone 3: Formalizing the registry + +[recommendation] +==== +[specification] +-- +The TZ Group takes steps to standardize the way the "TZ registry file" is generated and +distributed. +-- +==== + +[recommendation] +==== +[specification] +-- +Another RFC is created to define and setup the IANA time zone registry. +-- +==== + +[bibliography] +== References + +* [[[tz-draft,1]]], Time zone registry draft http://ietfreport.isoc.org/idref/draft-royer-timezone-registry/ + +* [[[tz-database,2]]], Time zone database http://www.twinsun.com/tz/tz-link.htm + +* [[[windows-tz,3]]], Windows time zones to TZID mapping http://unicode.org/cldr/data/diff/supplemental/supplemental.html - windows___tzid + +* [[[caldav,4]]], CalDAV Draft http://ietfreport.isoc.org/idref/draft-dusseault-caldav/ +RFC 2445 http://www.ietf.org/rfc/rfc2445.txt + +* [[[tz-problems,5]]], Time zone problems and recommendations document http://www.calconnect.org/publications/icalendartimezoneproblemsandrecommendationsv1.0.pdf diff --git a/sources/cc-0607-report-ioptest/document.adoc b/sources/cc-0607-report-ioptest/document.adoc new file mode 100644 index 0000000..32f4f62 --- /dev/null +++ b/sources/cc-0607-report-ioptest/document.adoc @@ -0,0 +1,170 @@ += May 2006 CalConnect Interoperability Test Report +:docnumber: 0607 +:copyright-year: 2007 +:language: en +:doctype: administrative +:edition: 1.1 +:status: published +:revdate: 2007-06-12 +:published-date: 2007-06-12 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Patricia Egen +:role: author +:fullname_2: Simon Vaillancourt +:role_2: author +:fullname_3: Chuck Norris +:role_3: author +:fullname_4: Mike Douglass +:role_4: author +:fullname_5: Patricia Egen +:affiliation_5: CalConnect +:role_5: editor +:contributor-position_5: IOP Test Manager + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Introduction + +This document contains notes and results from the May 2006 calendar interoperability test event +held at the IBM/Lotus complex in Boston, MA. The basic purpose of the event was to start +testing Free Busy, which has recently been added to the CALDAV specification. In addition, +there was continued testing of iCalendar events by the Eventful organization. + +The chart below shows the attendees, their organization and the products they were testing. + +=== Attendees + +[%unnumbered,options=header] +|=== +| Attendees | Organization | Products +| Chuck Norris | EVDB | CALDAV server +| Simon Vaillancourt | Oracle | Oracle CALDAV server +| Jeffrey Harris | OSAF | Chandler and Cosmo +| Mike Douglass | RPI | Bedework CALDAV Server +| Dan Gurney | IBM | Lotus Notes (mostly an observer) +|=== + +== General Comments + +Free Busy is a very recent addition to CALDAV. As such, there are only a few clients that are +available for testing interoperability. The following is what was tested: Three CALDAV +servers, One CALDAV client and absorbing Recurrence rules (RFC 2445 and RFC 2447). + +=== Vendor 1 Testing + +Using a sample Free Busy demo client, Vendor 1 tested the CalDAV servers. The demo +application is designed to show how to connect to different CALDAV servers to do free busy, +acting like a small client. The following chart shows how this client worked against various +CALDAV servers. + +[cols=5,options=header,cols="^,^,^,^,<"] +.Free Busy Report Chart +|=== +| Vendor1 | Vendor2 | Vendor3 | 7 | Free Busy Reports +| N | N | N | Setup a| Create a new calendar and populate it with the following +for one week: + +Event on Monday, 9 am - 11 am, recurs every day for +five times + +Event on Monday, 12 pm - 1 pm, status tentative + +Event on Monday, 2 pm - 3 pm, status cancelled + +Event on Tuesday, 11 am - 12 pm + +Event on Tuesday, 2 pm - 4 pm, recurs every day for four times + +Event on Tuesday, 3 pm - 5 pm + +Event on Wednesday, 11 am - 12 pm, status tentative + +Event on Wednesday, 3 pm - 5 pm, status tentative + +Event on Thursday, 11 am - 12 pm, status cancelled + +Event on Thursday, 3 pm - 5 pm, status cancelled +| P | | P | 7.1 | Run a free-busy report for the entire week. +| P | | P | 7.1.1 | Verify two `FREEBUSY` periods for Monday, the second is `BUSY-TENTATIVE`. +| P | | P | 7.1.2 | Verify two `FREEBUSY` periods for Tuesday. +| P | | P | 7.1.3 | Verify four `FREEBUSY` periods for Wednesday, second and fourth are `BUSY-TENTATIVE` and one hour long. +| P | | P | 7.1.4 | Verify two `FREEBUSY` periods for Thursday. +| P | | P | 7.1.5 | Verify two `FREEBUSY` periods for Friday. +|=== + +=== Vendor 4 Testing + +Since the Vendor 4 organization joined the interoperability testing events after several other +organizations had done their testing, they were very happy to exchange iCalendar objects to send +to their server. Several attendees sent objects to help them test their iCalendar support, in +particular recurring events. They found issues when absorbing iCalendar recurrence events. +These will be useful in helping them streamline their software. + +=== Vendor 3 Testing + +Vendor 3 noted that the Vendor2 server sent items that caused issues on the Vendor 3 server. +They resolved several of them onsite and uncovered a few more problems that they will work on +later. Vendor 3 uses write content. They noted that we may want to prevent users from updating +Calendar structures based on role. It should be that they can create events but not collections. + +=== Vendor 2 testing + +Vendor 2 tested their brand new support for free busy in their client. Rather than work on the +test scenarios, since their product is brand new, they spent time fixing bugs involving +subscription to other servers in their client. What they did determine, though, is that the testing +they did do did work with all three servers for timed events of whatever status. All-day events +didn't work on Vendor1 with the way their server serializes them. Vendor 1 will work on fixing +that. It was noted while testing their version that sub collections are not supported by Vendor1 +and Vendor 3. Therefore, they had to do some work on read write capabilities. By the next +Interop they will do current user privilege sets. This is needed for Access Control. Generally +speaking, `freebusy` works. Vendor 2 suggests that next time we should test infinite depth, or +"rollup", `freebusy` reports, if anybody other than Vendor 2 supports them. + +== Summary + +As usual, the interoperability testing revealed problems with servers that no one knew about. +These were resolved quickly in many cases or will be resolved when the attendees get back to +their respective facilities. It is always better to test something before it goes production and that +is one of the things we can provide -- a safe, non-public forum and environment for testing +software interoperability. + +Since this was, again as stated above, early in the Free Busy on CALDAV cycle, it was not as +busy an interop as past events. However, it was a productive one, provided valuable feedback +and helped the developers improve their products. In summary, the Vendor 3 and Vendor 1 +servers can do free busy. The Vendor 2 client is a work in progress and is well on it's way. + +Vendor 3 spent part of time on Free busy query items and found their "usual bugs." +Vendor 1 spent most of the time on their Free Busy demo and their server. They also worked on +a known problem with embryonic ACLs. + +Vendor 2 found that their Free Busy broadly works. + +Vendor 4 said they came in with something brand new and fragile and wanted to bounce their +software off real world scenarios. This is an example of exactly what an Interoperability event +should be -- testing code that is not only complete but in development as well. It's better to know +that something is not working as expected before committing an extensive amount of time in +development. Vendor 4 found the event very valuable. + +The next CalConnect Interoperability Testing Event (CITE) will spend more time focusing on +Free Busy. + +== The Future + +Some time was spent discussing the mobile space so we are starting a dialog on testing mobile +devices and iCalendar, CALDAV, etc. This year is first year there are multiple phones with ical +parsers. We will need to look for definitions of test cases. We will look at announcing early that +we are embarking on this space to gather potential participants. + +One of our first items will be to look at basic ical data and determine whether it gets rendered +correctly on a certain number of devices. We will also need to look at transport mechanisms. +Pat will work with Symbian who volunteered to help come up with test scenarios. The aim is to +start the interop testing at the January meeting. + +By September MIT might have ical export function from event calendar and will be interested in +testing with clients. CMU might be interested in testing also. + +My thanks to everyone who furnished their notes and results. + +Respectfully submitted, + +Pat Egen. + +Interoperability Event Manager diff --git a/sources/cc-0608-pres-fb-demo/document.adoc b/sources/cc-0608-pres-fb-demo/document.adoc new file mode 100644 index 0000000..196d8f4 --- /dev/null +++ b/sources/cc-0608-pres-fb-demo/document.adoc @@ -0,0 +1,280 @@ += The Open Group Federated Freebusy Challenge Demo +:docnumber: 0608 +:copyright-year: 2006 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2006-07-17 +:published-date: 2006-07-17 +:technical-committee: FREEBUSY +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Wen Fang +:affiliation: Boeing +:fullname_2: Mike Douglass +:affiliation_2: RPI +:fullname_3: Gary Schwartz +:affiliation_3: RPI +:imagesdir: images + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks +and Disclaimer of Warranty for External (Public) Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +The Open Group Quarterly Meeting location: Coral Gables, Florida + +== Why We are here + +"Increasingly in business, there is a need to +schedule meetings with people (within or +outside of the company) using different +calendaring systems without multiple +interactions and iterations, which prove to +be time consuming and inefficient. What is +needed is a simple mechanism to see when +a group of people would be available for a +meeting." + +== Open Group Vendor Challenges + +A vendor challenge is a very practical way to address +the blockages that prevent deployment of a new +technology, and in the context of work within The +Open Group, this means the deployment of a new +standards-based technology. + +The whole project is completed within the context of +a very specific problem reported by one or more IT +user organizations. This is important because it +demonstrates to product vendors that there is a +ready market for a solution to the problem, and +encourages their active participation. + +== Who We Are + +=== The Open Group + +The Open Group is a vendor- and technology-neutral +consortium, whose vision of Boundaryless +Information Flow(TM) will enable access to integrated +information within and between enterprises based on +open standards and global interoperability. + +In accordance with its vision and mission, The Open +Group works towards enabling access to integrated +information within and between enterprises based on +open standards and global interoperability. + +=== CalConnect - The Calendaring and Scheduling Consortium + +The Consortium is focused on the interoperable +exchange of calendaring and scheduling information +between dissimilar programs, platforms, and +technologies. + +The Consortium's mission is to promote general +understanding of and provide mechanisms to allow +interoperable calendaring and scheduling +methodologies, tools and applications to enter the +mainstream of computing. + +=== The Presenters + +* Wen Fang + +Sr. System Analyst + +The Boeing Company + +* Mike Douglass + +Sr. Systems Programmer + +Lead architect of Bedework + +RPI + +* Gary Schwartz + +Director, Communications & Middleware Technologies + +RPI + +* Drew Garcia + +Director, Product Management + +Timebridge + +== Chronology + +* 2005/Q1 Brought to the Messaging Forum by The Boeing +Company and Noventum Consulting +* 2006/Q1 Messaging Forum issued Federated Free/Busy +Challenge +* 2006/Q1 Representatives of Open Group brought +FREEBUSY Challenge to CalConnect +* 2006/Q2 proof of concept solution sketched out at +Quarterly Meeting in Washington, D.C. to be promoted as a +joint project between The Open Group and the Calendaring +& Scheduling Consortium +* 2006/Q3 Demo of Proof of Concept Solution at Quarterly +Meeting in Miami +* 2006/Q4 The Challenge final report to be published + +== What We Will be Showing You + +* Requests to multiple calendar servers in +multiple locations from multiple vendors for +FREEBUSY information for multiple users +* Management of these requests and +aggregation of requested information from +web-based applications +* An interim solution which (adroitly) +sidesteps some issues that will be need to +addressed at some point. + +== Why this is Significant + +* Major groupware applications already do +this, but not in a heterogeneous calendaring +environment which spans administrative and +geographical domains. +* It is the first step towards solving a problem +which needs to be solved. + +== The Requirements + +* Uses open standard protocols +* Can be implemented today +* Crosses timezones, cultures, calendaring +systems, corporate and network boundaries + +== Relaxed Constraints + +* For a constrained list of named attendees +* For a constrained list of times. +* Restricted to organizations that have server +based calendaring systems +* No provision for confirmation that times are +acceptable or for updating calendars +* Can initially exclude provision for recurring +meetings + +== Architectural overview + +An organizer, aggregator, "avatar" program (or controller) +providing the user interface, having knowledge of attendee +lists and groups, perhaps embed local business logic, and +some useful level of functionality aggregating and +displaying results from the `FREEBUSY` queries. + +A CalDAV-compliant free/busy interface (CC-FBI) layer (or +"proxy" which would field CalDAV free/busy queries from, +and return results to, the organizer program. This interface +would only have to support enough CalDAV to support +free/busy queries. + +A number of "connector" servers or services, at the edge of +the network, to interface to systems which do not support +CalDAV. + +.Architectural Overview -- "From the Clouds" +image::img01.png[width=120%] + +.Architectural View -- "From the Clouds" +image::img02.png[] + +== How we did it + +* Coordinated in the CalConnect `FREEBUSY` +technical committee +* Modified code from the open source +Bedework calendar +* "Connector" code contributed by IBM, +Boeing, and TimeBridge +* Cooperative and collegial development and +testing among calendar developers + +== The Secret of Our Success - CalDAV + +CalDAV is designed for implementation by any +collaborative software, client or server that needs to +maintain, access, or share collections of events. It is being +developed as an open standard to foster interoperability. + +CalDAV builds upon extant standards (RFC 2445, WebDAV) +while anticipating and allowing changes in the future such +as XML representations of calendaring formats. + +Mozilla, Oracle, Open Software Applications Foundation, +Novell, Bedework have publicly announced plans to support +CalDAV. + +CalDAV provides enterprises the promise of +comprehensive, interoperable, global calendaring solution. + +== What We Learned + +* Enlightened self interest and open standards are a +powerful combination +* Even calendar developers who claim they use "open +calendar standards" may have non-conforming +implementations. +* Open APIs are good. Widely adopted open standards +are better. +* Open standards need to be unambiguous ensure +implementations will interpret those standards in +interoperable way. + +== What remains to be done? + +* Adroitly solve the problems we are presently +adroitly sidestepping: +** Discovery +** Authentication and access control +** Enfranchising additional calendaring systems +* Migrate this solution to use the richer +functionality of the still developing "Scheduling +Extensions to CalDAV" specifications. +* Encourage wider participation among calendar +developers and calendar users + +[appendix,obligation=informative] +== Open Group Demo -- July 18, 2006 + +Accessed `FREEBUSY` information from: + +* Bedework Calendar (native CalDAV) +* Oracle Collaboration Suite Calendar (native CalDAV) +* OSAF Cosmo (native CalDAV) +* Google Calendar (RPI-supplied connector) +* IBM Lotus Domino/Notes (IBM-supplied connector) +* Microsoft Outlook (TimeBridge-supplied connector) +* Microsoft Exchange (Boeing-supplied connector) + +.Aggregator Main Screen +image::img03.png[] + +.Aggregator `FREEBUSY` Display +image::img04.png[] + +.Chandler Calendar Screen Shot +image::img05.png[] + +.Bedework Calendar Screen Shot +image::img06.png[] + +.Boeing Exchange Calendar Screen Shot +image::img07.png[] + +[bibliography] +== Resources & References + +* [[[og,1]]], http://www.opengroup.org/ + +* [[[cc,2]]], http://www.calconnect.org/ + +* [[[bw,3]]], http://www.bedework.org/ + +* [[[tb,4]]], http://www.timebridge.org/ + +* [[[og-challenges,5]]], http://www.opengroup.org/messaging/challenges/ + +* [[[ietf,6]]], http://ietf.osafoundation.org/caldav/index.html diff --git a/sources/cc-0608-pres-fb-demo/images/img01.png b/sources/cc-0608-pres-fb-demo/images/img01.png new file mode 100644 index 0000000..0c56abc Binary files /dev/null and b/sources/cc-0608-pres-fb-demo/images/img01.png differ diff --git a/sources/cc-0608-pres-fb-demo/images/img02.png b/sources/cc-0608-pres-fb-demo/images/img02.png new file mode 100644 index 0000000..14f905c Binary files /dev/null and b/sources/cc-0608-pres-fb-demo/images/img02.png differ diff --git a/sources/cc-0608-pres-fb-demo/images/img03.png b/sources/cc-0608-pres-fb-demo/images/img03.png new file mode 100644 index 0000000..ae9d629 Binary files /dev/null and b/sources/cc-0608-pres-fb-demo/images/img03.png differ diff --git a/sources/cc-0608-pres-fb-demo/images/img04.png b/sources/cc-0608-pres-fb-demo/images/img04.png new file mode 100644 index 0000000..5cf7e3d Binary files /dev/null and b/sources/cc-0608-pres-fb-demo/images/img04.png differ diff --git a/sources/cc-0608-pres-fb-demo/images/img05.png b/sources/cc-0608-pres-fb-demo/images/img05.png new file mode 100644 index 0000000..86232cd Binary files /dev/null and b/sources/cc-0608-pres-fb-demo/images/img05.png differ diff --git a/sources/cc-0608-pres-fb-demo/images/img06.png b/sources/cc-0608-pres-fb-demo/images/img06.png new file mode 100644 index 0000000..9f7d284 Binary files /dev/null and b/sources/cc-0608-pres-fb-demo/images/img06.png differ diff --git a/sources/cc-0608-pres-fb-demo/images/img07.png b/sources/cc-0608-pres-fb-demo/images/img07.png new file mode 100644 index 0000000..1a5c29e Binary files /dev/null and b/sources/cc-0608-pres-fb-demo/images/img07.png differ diff --git a/sources/cc-0609-questionnaire-results-mobcal/document.adoc b/sources/cc-0609-questionnaire-results-mobcal/document.adoc new file mode 100644 index 0000000..df8e35d --- /dev/null +++ b/sources/cc-0609-questionnaire-results-mobcal/document.adoc @@ -0,0 +1,888 @@ += Report on Mobile Calendaring Questionnaire V2 Results +:docnumber: 0609 +:copyright-year: 2006 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2006-07-24 +:published-date: 2006-07-24 +:technical-committee: MOBILE +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Chris Dudding +:affiliation: Symbian Ltd +:role: editor +:imagesdir: images + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Introduction + +The Mobile Technical Committee of the Calendaring & Scheduling Consortium +(http://www.calconnect.org) developed a questionnaire about mobile devices currently being +used, their capabilities, and the extent of their support for calendaring applications. + +The goal of this questionnaire was to determine how and to what extent Calendaring is being +used on mobile devices, with a view to using those results to aid in the development of +recommendations on how to address any problem areas. + +A number of responses were received to the online questionnaire, and a summary and brief +conclusion of these results is presented, along with the raw results themselves. + +Respondents to the questionnaire answered based on the capabilities of their device. The results +show an aggregate of these results. + +== Questionnaire Background + +The questionnaire was answered by 60 respondents, which covered 14 different device +manufacturers and 40 different devices. Most of the devices were high-end mobile devices +released in the last few years. The respondents come from a spread of localities, with 40% of +respondents from America and 38% from the UK. + +The questionnaire consists of 53 questions. The bulk of the questions required a "yes", "no" or +"don't know" response. 15 of the questions were text based. Some questions allowed the user +to respond with more than one response (e.g. from a pick list). +The percentage totals for most questions were calculated from the number of answers compared +to the total of all possible answers (typically "yes", "no" or "don't know"). + +Where the answers are mutually exclusive the total answer percentages add up to 100% (with +/- +1% for rounding errors). For questions where multiple responses are possible the percentages +still show the answer compared to the total of all possible answers, but the total percentage will +not be 100%. + +== Summary of Results + +=== Section 1 -- General Information + +* There is a good spread of respondent's geographic location (though lacking input from +Japanese and South Korean users). +* Good spread of devices -- reasonably representative of (smart) phones for the sample +though generally Palm is much over-represented and Samsung especially is much underrepresented. +* 30% of respondents intend to replace their device soon. This is similar to the yearly +replacement average for US/Europe. +* Balance in usage business / personal use of devices is 50/50 +* A quarter of respondents do not travel. Northern hemisphere continents (Europe, Asia, N +America) are all travelled to by a large majority of respondents. +* 18% of respondents travelling to Asia (given only 3% are in Asia) is high +* Of the 28% who do not know if their devices would work out of their primary location, not +all are the 27% who do not travel with their device. 8% of these do travel with their +device +* A large range of primary desktop Calendar applications is used. Slightly surprising there +are not more respondents using Outlook (17%). + +=== Section 2 -- General Device Capabilities + +* High percentage of "high end" devices in survey, which is supported by a large +percentage of devices having QWERTY keyboards (37%). +* Large amount of perception involved in respondents ranking their devices as low, mid or +high range. The same device is often ranked differently by different respondents +* Large amount of perception involved in respondents describing the screen size. The +same device is often ranked differently by different respondents +* Only 12% of respondents thought their screen "small". +* 32% have run out of space or memory. This is obviously dependent on phone usage. +The results seem to show this is more prevalent on the lower spec phones. However, +this is encountered on the higher end devices too. + +=== Section 3 -- Access to Calendar Information + +* 95% of respondents normally use their device's Calendar application +* Large number (83%) of devices can run third party apps but 37% don't know if there are +third party calendar apps or not +* 10% use a third party application of their phone +* 43% don't know if they can use a web based calendar. 47% know they can on their +device +* But no respondents normally use web based calendaring on their device +* Respondent / questionnaire confusion over: How to respond to whether they use the +Calendar to View, Edit or View and Edit their data +* 87% of respondents use their device's Calendar application at least once a day +* Almost half of respondents say the experience of using the device's calendar application +is worse than their desktop application. There is some very negative feedback in this +area. +* However 20% said it was better than their desktop application + +=== Section 4 -- Calendar Application + +* The sophistication of repeat rules seems to be subjective, however some devices don't +support any repeat rules and some devices don't support "second Tuesday in month" +type repeats typically simple (MS Outlook type) functionality seems to be supported +* No-one said alarms can't be created on their entries +* 67% can't invite other people to events - only 18% can. Implies almost all phones don't +support Group Scheduling. Indeed, some of the devices that claim to support this only +support it in a limited way (e.g. Nokia 9500, 9300) +* ToDos widely supported (83%) +* 67% use Data Sync out of the 87% of phones that support Sync +* Numerous different suggestions for Sync improvement +* Most affecting current behaviour -- duplicating entries, slow, poor (or no) interoperability +with desktop apps, poor support for recurrence and no support for syncing multiple +calendars. +* Automatic sync also requested (e.g. over BT) +* Much comment on Data Sync being a limitation for the device: +* 30% saying it was the main thing they wanted to do that they currently couldn't do +* 93% of respondents only have one Calendar on their device +* 58% would like to overlay different calendars on top of the existing one +* Respondents wish to be notified of events with functionality (sounds, alerts, vibrate) that +are currently available on their devices. + +=== Section 5 -- Calendar Date and Timezone Support + +* Only 42% of respondents say their device knows what the timezone is automatically. +Though some of the replies (compared with the devices in question) are not correct +* Only 7% of respondents say their device allows timezones to be set on events other than +the current timezone +* Despite the fact that only 28% of respondents don't visit other timezones (*) 32% don't +know if their device adjusts the events for the local timezone. 47% of respondents say +their device does do this + +=== Section 6 -- Security + +* 53% of respondents are concerned about security +* 77% say their calendar content is confidential (business or personal) -- surprisingly high, +but the only other choice was "non-confidential public data" +* However, 55% did not respond on what security features they would like. +** 13% wanted SSL and/or encrypted data +** 12% wanted Password protection at phone or application level +** 7% wanted biometric security + +=== Section 7 -- What would you like to do with your mobile calendar? + +On aggregate, Free / Busy time viewing is rated as the most important use case (of five) + +On aggregate, Adding events downloaded from mobile browser second most important -- this is +more important to respondents than basic Group Scheduling. However, in a straight listing +respondents also ranked this the joint least most important use case + +=== Areas of ignorance for the respondents + +* The existence of third party calendars for the device (37% don't know) +* If web calendars can be used on the device (43% don't know) +* If timezones can be set on events other than the current timezone (47% don't know) +* How good the documentation/manual is (27% don't know) + +== Results + +=== Section 1 - General Information + +==== Q1.1. Who is your device manufacturer? + +Nokia:: 35% +Palm:: 23% +Sony Ericsson:: 13% +HTC:: 7% +Motorola:: 3% +Panasonic:: 3% +Siemens:: 3% +HP:: 2% +Kyocera:: 2% +Samsung:: 2% +RIM:: 2% +Apple:: 2% +Audiovox:: 2% +Dell:: 2% + +==== Q1.2. What model is your device? + +Results not summarised + +==== Q1.3. Who is your service provider? + +Vodafone:: 30% +Cingular:: 17% +T-Mobile:: 7% +Fido:: 7% +O2:: 7% +Verizon:: 5% +Sprint:: 5% +Orange:: 3% +Hutch:: 3% +AT&T:: 2% +Telus:: 2% +Virgin Mobile:: 2% +Elisa:: 2% +Other:: 10% + +==== Q1.4. How long have you had this device? (years) + +The average was 1.5 years. 25% of responses were under 1 year. + +==== Q1.5. Do you intend to replace it soon? + +Yes:: 30% +No:: 43% +Don't know:: 27% + +==== Q1.6. How would you rate the documentation/manual that came with the device? + +Good:: 22% +Average:: 47% +Poor:: 5% +Don't know:: 27% + +==== Q1.7. What is the primary use of this device? + +Business:: 51% +Personal:: 47% +Other:: 2% + +==== Q1.8. What is the primary desktop calendar application that you use? + +Lotus Notes:: 27% +Oracle Calendar:: 20% +Microsoft Outlook:: 17% +Mac iCal:: 12% +Meeting Maker:: 7% +Mozilla Sunbird:: 5% +Other:: 13% + +==== Q1.9. What type of organization do you work in? + +Business:: 30% +Mobile software vendor:: 30% +Education:: 28% +Other:: 7% +Government:: 3% +Mobile device manufacturer:: 2% + +==== Q1.10. What is your primary geographic location? + +USA:: 40% +UK:: 38% +Canada:: 10% +India:: 3% +Other:: 3% +UAE:: 2% +Finland:: 2% +Anguilla:: 2% + +==== Q1.11. Which other geographic locations do you travel to? + +Europe:: 43% +N America:: 28% +None:: 27% +Asia:: 18% +Australasia:: 5% +S America:: 2% + +==== Q1.12. Does your service provider provide support outside your primary geographic location? + +Yes:: 63% +No:: 8% +Don't know:: 28% + +=== Section 2 - General Device Capabilities + +==== Q2.1. How would you describe the capabilities of this device as a whole? + +High-end:: 60% +Mid-range:: 37% +Low-end:: 3% + +==== Q2.2. What size screen does it have? + +Large:: 28% +Medium:: 57% +Small:: 12% +Unspecified:: 3% + +==== Q2.3. What type of keypad does it have? + +Phone:: 48% +Qwerty:: 37% +Other:: 15% + +==== Q2.4. Have you found that you run out of storage space or memory for your data and applications? + +Yes:: 32% +No:: 68% + +==== Q2.5. Does it allow third-party applications to be used? + +Yes:: 83% +No:: 10% +Don't know:: 7% + +==== Q2.6. What are the standard set of applications on the device? + +Results not summarised + +==== Q2.7. What are its multimedia capabilities? + +Camera:: 87% +Audio Player:: 65% + +NOTE: Summary of main responses. + +==== Q2.8. Which multimedia capabilities do you actually use? + +Camera:: 67% +Play Audio:: 38% + +NOTE: Summary of main responses. + +==== Q2.9. Which multimedia capabilities would you like to have? + +Better Music Player:: 35% +Better Video:: 33% +Better Camera:: 33% +VOIP:: 5% + +=== Section 3 - Access to Calendar Information + +==== Q3.1. Does the device have a built-in calendar application? + +Yes:: 98% +No:: 0% +Don't know:: 2% + +==== Q3.2. Are there third-party calendar applications for the device? + +Yes:: 53% +No:: 10% +Don't know:: 37% + +==== Q3.3. Can you use a web-based calendar with this device? + +Yes:: 47% +No:: 10% +Don't know:: 43% + +==== Q3.4. Do you normally use any calendaring applications on this device? + +Yes:: 95% +No:: 3% +Don't know:: 2% + +==== Q3.5. Do you normally use a web-based calendar on this device? + +Yes:: 0% +No:: 93% +Don't know:: 7% + +==== Q3.6. Do you use the calendar feature to just view a calendar or to also edit it (e.g. create new events)? + +View & Edit:: 43% +Edit:: 33% +View:: 23% + +==== Q3.7. How often do you use the calendar feature on this device? + +Several times a day:: 62% +Once a day:: 25% +Once a week:: 5% +Not very often:: 5% +Only when travelling:: 3% + +==== Q3.8. Do you use the built-in or a third-party application? + +Built-in:: 90% +Third party:: 10% + +==== Q3.9. How would you compare the experience of using the calendar application on this device with using one on a desktop computer? + +Worse:: 48% +Similar:: 13% +Better:: 20% +Other:: 19% + +=== Section 4 - Calendar Application + +==== Q4.1. Does it support creation of recurring events? + +Yes:: 68% +No:: 18% +Don't know:: 13% + +==== Q4.2. How sophisticated is the recurrence capability? + +Result not summarised + +==== Q4.3. Does it support creation of alarms on events? + +Yes:: 92% +No:: 0% +Don't know:: 8% + +==== Q4.4. Would you like to receive notification of your desktop calendar alarms on your mobile device? + +Yes:: 75% +No:: 22% +Don't know:: 3% + +==== Q4.5. How would you like your mobile device to notify you about events? + +Sound:: 70% +Vibrate:: 32% +Pop-up:: 21% +SMS/Email:: 8% + +==== Q4.6. Can you invite other people to events? + +Yes:: 18% +No:: 67% +Don't know:: 15% + +==== Q4.7. Does it support tasks/to-dos? + +Yes:: 83% +No:: 8% +Don't know:: 8% + +==== Q4.8. Does the device support synchronization of your phone and desktop calendar? + +Yes:: 87% +No:: 5% +Don't know:: 8% + +==== Q4.9. Do you use the synchronization support? + +Yes:: 67% +No:: 32% +Don't know:: 2% + +==== Q4.10. How would you improve the synchronization support with your desktop calendar? + +Interop with desktop apps:: 12% +Recurrence issues:: 10% +Automatic Sync (BT):: 8% +Speed:: 5% +Multiple Calendars:: 5% +Duplicates:: 5% +No Response:: 30% + +==== Q4.11. How many different calendars do you have on your mobile device? + +1 calendar:: 93% +2 calendars:: 3% +3 calendars:: 2% + +==== Q4.12. Would you like the ability to overlay other calendars on top of your existing events? + +Yes:: 58% +No:: 22% +Don't know:: 20% + +=== Section 5 - Calendar Date and Timezone Support + +==== Q5.1. Does the device itself know what the correct time is automatically? + +Result not available + +==== Q5.2. Does the device itself know what timezone it is in automatically? + +Yes:: 42% +No:: 48% +Don't know:: 10% + +==== Q5.3. Can you configure the device timezone manually? + +Yes:: 77% +No:: 10% +Don't know:: 12% + +==== Q5.4 Does the calendar application adjust the displayed time of events based on the local time and timezone information + +Yes:: 47% +No:: 22% +Don't know:: 32% + +==== Q5.5. Does the calendar application allow timezones on event times to be set different from the devices own timezone? + +Yes:: 7% +No:: 47% +Don't know:: 47% + +=== Section 6 - Security + +==== Q6.1. Are you concerned about the security of the calendar data stored on the device? + +Yes:: 53% +No:: 47% + +==== Q6.2. How sensitive is the calendar data stored on the device? + +Confidential - personal:: 45% +Non-confidential:: 33% +Confidential - business:: 22% + +==== Q6.3. Are there any security features you would like to have on your mobile device? + +No Response:: 55% +SSL/Encryption:: 13% +Password control:: 12% +No:: 8% +Biometric lock:: 7% + +=== Section 7 - What would you like to do with your mobile calendar? + +==== Q7.1 What would you like to be able to do with your device that you cannot do right now? + +Improve Sync:: 30% (of which use Web Sync) 12% +Group Scheduling:: 12% +GUI issues:: 10% +Timezone support:: 7% +View Others Calendars:: 7% +No Response:: 37% + +==== Q7.2 Please rank these mobile calendaring use cases in order of importance to you + +Overall result - most to least important: + +* Sharing a calendar with colleague or spouse to identify free and busy time +* Adding calendar events to your calendar that have been downloaded from a mobile web +browser +* Book appointments with other people using your mobile device +* Automatically arranging a meeting at a time convenient for meeting participants after they +have agreed they want to meet +* Accessing a public transport timetable on your mobile device that is relevant to your +current location + +=== Section 8 - About this Questionnaire + +==== Q8. What do you think of this questionnaire? + +Ok to Good:: 38% +No Response:: 33% +Too Long/Detailed:: 8% +Unclear:: 5% +Other:: 15% + +=== Selected Answers to Text Questions + +==== Q3.9. How would you compare the experience of using the calendar application on this device with using one on a desktop computer? + +[quote] +____ +Substantially less useful. Due to synchronization problems with my calendar server, the inability +to edit/schedule events is a major issue. Also, the web-based calendar provided by our calendar +server uses frames, which makes browsing from the ##### device very cumbersome. +____ + +Lots of comments on data entry and screen size + +[quote] +____ +awkward to view some information, poor summary of information on phone, data input difficult, +no group scheduling +____ + +==== Q4.10. How would you improve the synchronization support with your desktop calendar? + +[quote] +____ +iCal supports multiple calendars (eg one for work, one for personal events etc..) - I wish the +phone would support this too +____ + +[quote] +____ +Make it faster and more reliable - syncing sometimes create multiple enteries of the same +entries +____ + +[quote] +____ +I would add support to subscribe to iCal URL's & update at hotsync time +____ + +[quote] +____ +Works great! +____ + +[quote] +____ +Support undo, show user the data being synced - I don't trust sync. +____ + +==== Q7.1 What would you like to be able to do with your device that you cannot do right now? + +[quote] +____ +time zones on events. per-event alarm preferences (volume, etc). Share calendars (other +people's). Filter by category. link an event to contacts. want more than 30 chars in Location field +(or link to metadata). show more than just calendar events (todos, for example, or TV listings). +transparent negotiation of meeting times +____ + +[quote] +____ +Sync properly to Oracle Calendar and other calendars. View other people's calendars (not via +web). +____ + +[quote] +____ +push email and cal events. overlay calendars. access event calendars. better scheduling with +corporate cal solution +____ + +[quote] +____ +It would be nice to have multiple calendars to categorise different events, each with there own +sync source. For example work calendar events and personal calendar events, one syncing from +my a work syncML server, the other from my home pc.As mentioned earlier, the ability to apply a +pass code for a calendar with sensitive data (i.e. work related events) would be essential. +____ + +[appendix] +== CalConnect TC-MOBILE Questionnaire V2 + +This questionnaire is designed to give the Calendaring & Scheduling +Consortium's TC-MOBILE technical committee information about mobile devices +currently being used, including specifics about the device capability as well as +support for calendaring applications. The information provided in this form will be +used to help guide the technical committees report on mobile calendaring. A +summary of the results will be published by the Consortium through its usual +process. + +Please fill out this form with as much information as possible. If you are not sure +of any answers, just leave that field empty or select the "Don't Know"option. + +=== Personal Details (will not be included in published report) + +What is your name? \______\______\_________ + +What is your email address? \______\______\_________ + +What is your organization? \______\______\_________ + +=== Section 1 General Information + +Q1.1. Who is your device manufacturer? \______\______\_________ + +Q1.2. What model is your device? \______\______\_________ + +Q1.3. Who is your service provider? \______\______\_________ + +Q1.4. How long have you had this device? \______ years + +Q1.5. Do you intend to replace it soon? + +○ Yes ○ No ○ Don't know + +Q1.6. How would you rate the documentation/manual that came with the device? + +○ Good ○ Average ○ Poor ○ Don't know + +Q1.7. What is the primary use of this device? + +○ Personal ○ Business ○ Other + +Q1.8. What is the primary desktop calendar application that you use? \______\______\_________ + +Q1.9. What type of organization do you work in? image:dropdown.png[] + +Q1.10. What is your primary geographic location? image:dropdown.png[] + +Q1.11. Which other geographic locations do you travel to? image:dropdown.png[] + +Q1.12. Does your service provider provide support outside your primary geographic location? + +○ Yes ○ No ○ Don't know + +=== Section 2 General Device Capabilities + +Q2.1. How would you describe the capabilities of this device as a whole? + +○ Low-end ○ Mid-range ○ High-end ○ Don't know + +Q2.2. What size screen does it have? + +○ Small ○ Medium ○ Large + +Q2.3. What type of keypad does it have? + +○ Phone keys (0-9 etc) ○ Full qwerty ○ Other + +Q2.4. Have you found that you run out of storage space or memory for your data and applications? + +○ Yes ○ No ○ Don't know + +Q2.5. Does it allow third-party applications to be used? + +○ Yes ○ No ○ Don't know + +Q2.6. What are the standard set of applications on the device? + +\______\______\_________ + +(e.g. Contacts, calendar, email, alarm, games) + +Q2.7. What are its multimedia capabilities? + +\______\______\_________ + +(e.g. takes pictures, video playback) + +Q2.8. Which multimedia capabilities do you actually use? + +\______\______\_________ + +(e.g. audio recording) + +Q2.9. Which multimedia capabilities would you like to have? + +\______\______\_________ + +(e.g. digital music playback) + +=== Section 3 Access to Calendar Information + +Q3.1. Does the device have a built-in calendar application? + +○ Yes ○ No ○ Don't know + +Q3.2. Are there third-party calendar applications for the device? + +○ Yes ○ No ○ Don't know + +Q3.3. Can you use a web-based calendar with this device? + +○ Yes ○ No ○ Don't know + +Q3.4. Do you normally use any calendaring applications on this device? + +○ Yes ○ No ○ Don't know + +Q3.5. Do you normally use a web-based calendar on this device? + +○ Yes ○ No ○ Don't know + +Q3.6. Do you use the calendar feature to just view a calendar or to also edit it (e.g. create new events)? + +○ View ○ Edit + +Q3.7. How often do you use the calendar feature on this device? image:dropdown.png[] + +Q3.8. Do you use the built-in or a third-party application? + +○ Built-in ○ Third-party + +Q3.9. How would you compare the experience of using the calendar application on this device with using one on a desktop computer? + +\______\______\_________ + +=== Section 4 Calendar Application + +Q4.1. Does it support creation of recurring events? + +○ Yes ○ No ○ Don't know + +Q4.2. How sophisticated is the recurrence capability? + +\______\______\_________ + +(e.g. repeat daily, weekly, every n days etc.) + +Q4.3. Does it support creation of alarms on events? + +○ Yes ○ No ○ Don't know + +Q4.4. Would you like to receive notification of your desktop calendar alarms on your mobile device? + +○ Yes ○ No ○ Don't know + +Q4.5. How would you like your mobile device to notify you about events? + +\______\______\_________ + +(e.g. play a sound, set-up a phone call etc.) + +Q4.6. Can you invite other people to events? + +○ Yes ○ No ○ Don't know + +Q4.7. Does it support tasks/to-dos? + +○ Yes ○ No ○ Don't know + +Q4.8. Does the device support synchronization of your phone and desktop calendar? + +○ Yes ○ No ○ Don't know + +Q4.9. Do you use the synchronization support? + +○ Yes ○ No ○ Don't know + +Q4.10. How would you improve the synchronization support with your desktop calendar? + +\______\______\_________ + +Q4.11. How many different calendars do you have on your mobile device? image:dropdown.png[] + +Q4.12. Would you like the ability to overlay other calendars on top of your existing events? + +○ Yes ○ No ○ Don't know + +=== Section 5 Calendar Date and Timezone Support + +Q5.1. Does the device itself know what the correct time is automatically? + +○ Yes ○ No ○ Don't know + +Q5.2. Does the device itself know what timezone it is in automatically? + +○ Yes ○ No ○ Don't know + +Q5.3. Can you configure the device timezone manually? + +○ Yes ○ No ○ Don't know + +Q5.4 Does the calendar application adjust the displayed time of events based on the local time and timezone information + +○ Yes ○ No ○ Don't know + +Q5.5. Does the calendar application allow timezones on event times to be set different from the devices own timezone? + +○ Yes ○ No ○ Don't know + +=== Section 6 Security + +Q6.1. Are you concerned about the security of the calendar data stored on the device? + +○ Yes ○ No ○ Don't know + +Q6.2. How sensitive is the calendar data stored on the device? image:dropdown.png[] + +Q6.3. Are there any security features you would like to have on your mobile device? + +\______\______\_________ + +=== Section 7 What would you like to do with your mobile calendar? + +Q7.1 What would you like to be able to do with your device that you cannot do right now? + +[%unnumbered] +image::textblock.png[] + +Q7.2 Please rank these mobile calendaring use cases in order of importance to you + +(mark the most important use case as 1, second most important as 2,.... least important as 5) + +. Sharing a calendar with colleague or spouse to identify free and busy time. image:short-dropdown.png[] +. Book appointments with other people using your mobile device (e.g. scheduling a +follow-up meeting at the end of a meeting or making an appointment at the physican +and the event automatically being added to your mobile calendar). image:short-dropdown.png[] +. Adding calendar events to your calendar that have been downloaded from a mobile web +browser (e.g. adding your favourite team's football matches or a list of public +holidays to your calendar). image:short-dropdown.png[] +. Accessing a public transport timetable on your mobile device that is relevant to your +current location (e.g. automatically downloading a timetable at bus stop or ticket +office). image:short-dropdown.png[] +. Automatically arranging a meeting at a time convenient for meeting participants +after they have agreed they want to meet. image:short-dropdown.png[] + +=== Section 8 About this Questionnaire + +Q8. What do you think of this questionnaire? (e.g. how long did it take to fill out, did you understand all the questions) + +[%unnumbered] +image::textblock.png[] + +[%unnumbered,align=center] +image::buttons.png[] + +NOTE: If you press "Submit Questionnaire " and *nothing happens*, +please shorten your free-form answers. Some browsers enforce +an arbitrary limit on the amount of data that can be submitted via +this form. diff --git a/sources/cc-0609-questionnaire-results-mobcal/images/buttons.png b/sources/cc-0609-questionnaire-results-mobcal/images/buttons.png new file mode 100644 index 0000000..f2b7c0f Binary files /dev/null and b/sources/cc-0609-questionnaire-results-mobcal/images/buttons.png differ diff --git a/sources/cc-0609-questionnaire-results-mobcal/images/dropdown.png b/sources/cc-0609-questionnaire-results-mobcal/images/dropdown.png new file mode 100644 index 0000000..63f8041 Binary files /dev/null and b/sources/cc-0609-questionnaire-results-mobcal/images/dropdown.png differ diff --git a/sources/cc-0609-questionnaire-results-mobcal/images/short-dropdown.png b/sources/cc-0609-questionnaire-results-mobcal/images/short-dropdown.png new file mode 100644 index 0000000..5a6323e Binary files /dev/null and b/sources/cc-0609-questionnaire-results-mobcal/images/short-dropdown.png differ diff --git a/sources/cc-0609-questionnaire-results-mobcal/images/textblock.png b/sources/cc-0609-questionnaire-results-mobcal/images/textblock.png new file mode 100644 index 0000000..5e949d2 Binary files /dev/null and b/sources/cc-0609-questionnaire-results-mobcal/images/textblock.png differ diff --git a/sources/cc-0610-cs-glossary-v1/document.adoc b/sources/cc-0610-cs-glossary-v1/document.adoc new file mode 100644 index 0000000..4d8105b --- /dev/null +++ b/sources/cc-0610-cs-glossary-v1/document.adoc @@ -0,0 +1,294 @@ += Calendaring and Scheduling Glossary of Terms +:docnumber: 0610 +:copyright-year: 2006 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2006-10-12 +:published-date: 2006-10-12 +:technical-committee: USECASE +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Jeff McCullough +:affiliation: University of California at Berkeley +:role: editor + +== Introduction + +This is Version 1.0 of the Glossary of Calendaring and Scheduling terms. It is a "living" document that will +change over time as we add new terminology and enhance or improve upon existing terms. + +The document came about in an effort to compile, in one location, a common set of terminology with +respect to calendaring and scheduling applications and standards. The document incorporates +terminology already existing in calendaring standards such as RFC2445, RFC2446 and RFC2447as well +as input from members of the Calendaring and Scheduling Consortium (CalConnect). + +Some glossary terms may not appear in published standards today. These are common calendaring +terms that are included so that everyone refers to components in the same manner. +As new standards evolve, the glossary will serve as a resource for those creating documents so that all +the standards share a common set of terms. + +Calendaring and scheduling implementers will be able to utilize the glossary to assist them as they read +and decipher calendaring standards. Calendaring and scheduling users will be able to use the glossary +to help them better understand the terminology deployed by applications written using calendaring +standards. + +Kindly forward any terms that should be added to the glossary to the Calendaring and Scheduling +Consortium (calconnect.org) for approval and inclusion in the document. + +[heading=terms and definitions,keeptitle=true] +== Glossary of Calendaring and Scheduling Terms + +=== Access control +A mechanism to grant or deny privileges (Create, Read, Update, Delete) on calendars, +events, tasks or journal entries to other calendar users. + +=== Access Control List +A set or list of privileges, granted or denied to other calendar users, that define +access control to a particular calendar, event, task or journal entry. + +=== Alarm +A reminder notification for an event or a task. An example, alarms, may be used to define a +reminder for a pending event or an overdue task. Times may be relative or predetermined. + +=== Attendee +Participant of a calendar event or task. A participant can be the chair of a calendar event or +task. That person's participation may be required or optional. + +=== CalDAV +A standard protocol to allow calendaring and scheduling via extensions to the WebDAV +protocol. Defined by two specifications, the first specifies a calendar access +protocol that allows Calendar +User Agents to access and manage calendar data in a calendar store accessible via a +calendar service. +The second specification defines how Calendar User Agents perform scheduling operations via a +calendar service. The two drafts for these protocols can be found at http://ietf.osafoundation.org/caldav/. + +=== Calendar +A collection of events, tasks, journal entries, etc. Examples include a person's or group's +schedule, resource availability, and event listings. + +=== Calendar Access Rights +A set of rules defining who may perform what operations, such as reading or +writing information, on a given calendar. +See also {{Access Control List}}. + +[.source] +<> + +=== Calendar Object +A collection of components containing calendaring and scheduling information. + +=== Calendar Service +A server application that provides calendar user agents access to calendar stores. + +=== Calendar Store (CS) +A data repository that may contain several calendars as well as properties and +components of those calendars. + +=== Calendar User (CU) +A person that accesses their 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. +. Software that gathers calendar data on the Calendar User's behalf. + +=== CalConnect +The Calendaring and Scheduling Consortium consisting of vendors and user groups +interested in promoting and improving calendaring and scheduling standards and +interoperability. + +=== Component +A piece of calendar data such as an event, a task or an alarm. Information about +components is stored as properties of those components. + +[.source] +<> + +=== Counter +A counter-proposal sent by a participant to an event or task organizer to suggest a change to +the event or task such as the scheduled date/time, list of participants, etc. + +=== Daylight Saving Time (DST) +The period of the year in which the local time is adjusted forward, most +commonly by one hour. + +=== Delegate +A calendar user who has been assigned to participate in an event or task in place of one of the +attendees in that event or task. An example of a delegate is a team member sent to a +particular meeting as a substitute for one of his or her colleagues. + +=== Delegator +A calendar user who has assigned his or her participation in an event or task to another +calendar user. An example of a delegator is a busy executive who sends an employee to a meeting in his +or her place. + +=== Designate +A calendar user authorized to act on behalf of another calendar user. An example of a +designate is an assistant who schedules meetings for his or her superior. + +=== Event +A calendar object that is commonly used to represent things that mark time or use time. +Examples include meetings, appointments, anniversaries, start times, arrival times, closing times. + +=== Freebusy +A list of free and busy periods for a particular calendar user or resource. Primarily used for +scheduling resources or meetings with other people. Time periods may be marked as +busy, free, busy-unavailable +(sometimes referred to as out of office) and busy-tentative. + +=== iCal + +The name of Apple Computer, Inc's calendar client. Often used as the abbreviation of +the iCalendar standard. + +=== iCalendar +The Internet Calendaring and Scheduling Core Object Specification. An IETF standard (RFC +2445) for a text representation of calendar data. Scheduling operations are specified in RFC 2446. + +=== IETF (The Internet Engineering Task Force) +An International community organization that develops and +maintains the architecture of the worldwide Internet. The IETF issues standards known as RFCs (Request +For Comments), several of which pertain to calendaring and scheduling. + +=== Instance +A single occurrence in a recurring event. + +=== iMIP (iCalendar Message-Based Interoperability Protocol) +An IETF standard (RFC 2447) for +encapsulating iCalendar data in email messages. + +=== Invite +A request to attend a calendar event sent as structured iCalendar data. Invitations can be used to +schedule both calendar users and resources. + +=== Journal entry +A note associated with a date stored with other iCalendar data, e.g. a call log. + +=== Local Calendar Store +A calendar store (CS) that is on the same device as the calendar user agent +(CUA). + +[.source] +<> + +=== MIME +An acronym for Multipurpose Internet Mail Extensions, a specification for formatting non-ASCII +messages, including iCalendar data, graphics, audio and video, so that they can be sent over the +Internet. MIME is supported by email clients and web browsers. + +=== Negotiation + +Dee {{Scheduling}} + +=== Notification +An alert sent to a calendar user. Examples include alerts for new calendar items, changes to +existing items, or reminders about existing items. Notification methods include: sound from the computer, +visual feedback on the computer, email, paging, voicemail and telephone call. + +=== Organizer +A calendar user who creates a calendar item. + +=== Priority +A level of importance and/or urgency calendar users can apply to Tasks and Events. + +=== Property +A description of some element of a component, such as a start time, title or location. Properties +can have parameters associated with them to modify or add to their meaning. + +=== Publish +To make calendar information, such as `freebusy` time, available to a select group or +to the public. + +=== Recurring +An event or task that happens more than once either with a regular interval (ex. daily, weekly, +monthly) that can be expressed by a rule or with an explicit series of dates/times. + +=== Reminder + +See {{Notification}}. + +=== Remote Store +A calendar store that is not on the same machine/device as the calendar user agent + +=== Repeating +See {{Recurring}}. + +=== Resource +Shared equipment, materials, or facilities that can scheduled for use by calendar users. +Examples include: conference rooms, computers, audio visual equipment, and vehicles. + +=== RFC (Request for comments) +IETF and other standards bodies use RFCs to define Internet standards. +They document most of the protocols, mechanisms, procedures and best practices in use +on the Internet. + +=== RSVP +A request for status updates sent by the organizer for event invitations or tasks. + +=== Schedule +See {{Calendar}}. + +=== Scheduling +The exchange of request/invitations and responses between organizers and attendees of +scheduled events, tasks or journal entries. + +=== Standard Time +Originally developed as a consistent time system for the railroads using Greenwich +Mean Time (GMT) (see {{UTC}} below). {{Time zone,Time zones}} (see below) and DST shifts are based upon standard +time. + +=== Task +A calendar object that is commonly used to represent work items. + +=== Text/calendar +The MIME content type for encoding iCalendar objects. Example usage includes: email, +web pages. + +=== Time zone +Areas of the Earth that have adopted the same local time. Time zones are generally centered +on meridians of a longitude, that is a multiple of stem:[15 "unitsml(deg)"], thus +making neighboring time zones one hour apart. +However, the one hour separation is not universal and the shapes of time zones can be quite irregular +because they usually follow the boundaries of states, countries or other administrative areas. Time zones +are calendar components that define the time of an event relative to {{UTC}} (see below). + +=== To-do +See {{Task}}. + +=== Transparency +A property of an event that defines whether it will appear free or busy in free/busy time +searches. + +=== UTC +Coordinated Universal Time, abbreviated UTC. Also Zulu Time (alphabetized listing of time zones). +UTC is designated to be at zero longitude, also Greenwich mean time (GMT). Is the basis for all local time +offsets. Offsets are either positive or negative. An example is UTC-8 (Pacific Standard Time). + +Some iCalendar examples: + +* `DTSTART:19970714T133000 ;Local time` +* `DTSTART:19970714T173000Z ;UTC time` +* `DTSTART;TZID=US-Eastern:19970714T133000 ;Local time and time zone reference` + +=== vCalendar +A text representation of calendar and scheduling data created by the Versit consortium. The +iCalendar specification is based on the work of vCalendar. + +=== xCal +Representing calendar data in XML which corresponds closely to the iCalendar +standard. There is no current standard. + +[bibliography] +== References + +* [[[caldav,1]]], CalDAV -- http://ietf.osafoundation.org/caldav/ + +* [[[ietf,2]]], IETF -- http://www.ietf.org + +* [[[rfc,3]]], RFCs - http://www.ietf.org/rfc.html + +* [[[rfc3283,RFC 3283]]] diff --git a/sources/cc-0611-ical-benefits/document.adoc b/sources/cc-0611-ical-benefits/document.adoc new file mode 100644 index 0000000..a6d6b1b --- /dev/null +++ b/sources/cc-0611-ical-benefits/document.adoc @@ -0,0 +1,443 @@ += The Benefits of iCalendar for the Mobile Industry +:docnumber: 0611 +:copyright-year: 2006 +:language: en +:doctype: advisory +:edition: 1 +:status: published +:revdate: 2006-11-27 +:published-date: 2006-11-27 +:technical-committee: MOBILE +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Chris Dudding +:affiliation: Symbian Ltd +:role: editor +:fullname_2: Cyrus Daboo +:affiliation_2: Apple +:role_2: author +:fullname_3: Chris Dudding +:affiliation_3: Symbian +:role_3: author +:fullname_4: Mark Paterson +:affiliation_4: Oracle +:role_4: author + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +Chair(s):: Chris Dudding + +== Executive Summary + +The ability to share calendar information among different applications and +across network boundaries has become an important business need, as a +growing number of organizations look for ways to leverage their investments +in collaborative applications. + +Since the 1990s, when email standards were developed to allow for access to +messages on any server, from any device or browser, the same challenge +has remained for calendar and scheduling applications: How can we ensure +that meeting and task information can be accessed and managed from any +application, anytime, anywhere? + +The goal is simple enough at a high level: Develop a standard data object for +sharing calendar information over the Internet. iCalendar (RFC 2445) is a +widely accepted format for calendar data representation, and is supported by +several applications. However, vendors diverge in their interpretation of the +standard's format, leading to incomplete or unusable data being exchanged. +Further complicating the issue is that iCalendar has not been widely adopted +within certain application spaces. Although adopted by all major time +management solution vendors, there has been reluctance within the mobile +industry to migrate from vCalendar (iCalendar's predecessor) based solutions +and to fully embrace iCalendar. + +The Mobile Technical Committee (TC-MOBILE) of the Calendaring & +Scheduling Consortium recently published the results of a mobile calendaring +questionnaire. Of concern were answers related to calendar synchronization. +Synchronization was one of the main things users did, but it was also singled +out as one of the main things that did not work well yet. This can be attributed, +in large part, to issues related to data object interoperability. + +Efforts to clarify and simplify aspects of iCalendar and investment in +producing effective interoperability test suites hopefully can foster more +reliable solutions, but this can only be achieved through the widespread +adoption of iCalendar (RFC 2445) within all application spaces. + +== Introduction + +The vCalendar 1.0 specification defines a format for exchanging electronic +calendaring and scheduling information between different applications and +systems. It was developed by the Versit Consortium in September 1996. + +Ten years after publication, vCalendar has been adopted by a wide variety of +consumer electronics and mobile devices, from mobile phones to digital music +players. However, many products in this category have not adopted RFC2445 +(iCalendar) despite a high level of implementation by desktop applications and +services. + +The iCalendar specification, introduced in 1998, was intended to improve the +level of interoperability between dissimilar calendaring and scheduling +applications and systems. iCalendar builds on the previous work of vCalendar +1.0 and defines a MIME content type for exchanging calendar and scheduling +information with support for operations such as requesting and replying to +meeting events, to-dos or journal entries. + +Interoperability among devices and platforms is very important for mobile +users. The Mobile Technical Committee of the Calendaring & Scheduling +Consortium conducted a questionnaire of 60 mobile users about calendaring +on mobile devices in April 2006. One of the key findings from the +questionnaire was that user experience of synchronization was not good +enough due to problems with reliability and interoperability with desktop +applications. iCalendar provides a solution to these interoperability issues. + +In this paper: + +* We explain the differences between the vCalendar and iCalendar +standards +* We identify the advantages of wider usage of iCalendar +* We describe on-going activities to improve calendar interoperability +based on iCalendar + +== What is iCalendar? + +iCalendar provides a more precise specification of the calendar components +defined in the vCalendar 1.0 specification (`VEVENT`, `VTODO`) and defines +new calendar components for a journal entry (`VJOURNAL`), free and busy +time information (`VFREEBUSY`), time zone specification (`VTIMEZONE`), and +alarm definition (`VALARM`). + +The `VJOURNAL` component allows descriptive notes to be recorded for a +particular calendar date. Only a few products implement this component +currently. + +The grouping of properties in the `VFREEBUSY` component "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" (from RFC2445). + +The timezone specification provided by the `VTIMEZONE` component provides +a more comprehensive replacement for the `DAYLIGHT` and `TZ` properties in +vCalendar 1.0. It enables date and time information to be communicated in an +unambiguous format. + +The definition of alarms is provided by the `VALARM` component. This +component provides equivalent functionality to the `AALARM`, `DALARM`, +`MALARM`, and `PALARM` vCalendar 1.0 properties. + +== What are the differences between vCalendar and iCalendar? + +The default character set for iCalendar is UTF-8 rather than ASCII. It is no +longer possible to define a character set for an individual property; the same +character set applies to the whole iCalendar object. + +iCalendar has a default encoding of 8-bit; compared to vCalendar's default of +7-bit. It is no longer necessary to indicate 8-bit content using property +parameters. iCalendar data that needs to be transferred using protocols +restricted to 7 bits should use a content transfer encoding such as Base64 or +quoted-printable at the transport layer. + +There are new file type extensions of ICS and IFB for iCalendar core +components and free/busy information components. vCalendar's file type +extension of VCS is not used for identification of iCalendar data. + +Property value data types such as date-time are specified in a more rigorous +manner than in vCalendar; iCalendar also defines new property value data +types such as 'Calendar User Address' to improve interoperability. iCalendar +supports a more comprehensive set of property parameters to enable +delegation of requests, alternative representations of data, and participant +status. A full list of new property value data types and property value +parameters is provided in <>. + +iCalendar defines eighteen new properties to support specification of time +zones, calendaring and scheduling operations such as a canceling a meeting, +non-Gregorian calendar scales, and other calendar attributes. A full list is +provided in <>. + +iCalendar provides support for meeting requests/group scheduling with the +new `METHOD` property. The scheduling protocol is a logical extension of +iCalendar and is defined by RFC 2446 the iCalendar Transport-independent +Interoperability Protocol (iTIP). There is no equivalent for vCalendar data. + +The new `RECURRENCE-ID` property allows individual calendar instances to +be linked together and enables powerful recurrence/exception handling. + +iCalendar has proper support for time zones and can accurately represent +entries in local time, UTC time and local time with a time zone specified. This +is particularly important for repeating entries, which may span a daylight +saving change. vCalendar alone cannot represent the same data correctly. + +iCalendar supports repeat rules with a frequency of seconds, minutes and +hours. These kinds of repeat rules cannot be represented in vCalendar. + +In summary, the iCalendar specification is more detailed and more powerful; +the iCalendar specification is 148 pages compared to vCalendar's 47 pages. +This means that there is less opportunity for implementers to misinterpret the +specification's calendar components and it is easier to develop conformance +tests to verify a correct implementation of the standard. + +== What are the benefits of iCalendar? + +For consumers, adoption of iCalendar will result in improved interoperability +among devices and platforms that will allow them to synchronize data easily +among multiple devices and servers and see the same set of information +wherever they look. + +The widespread adoption of iCalendar in all application spaces will result in a +larger range of Calendar content available to consumers over the Internet. +Further extensions to iCalendar will enable exchange of an even richer set of +data. The consortium's Event Publication Technical Committee (TCEVENTPUB) +has developed the `VVENUE` proposal for representing venue +related information (e.g. concert listings, museum admission prices, and +driving directions). iCalendar-based solutions combined with ITIP (RFC 2446) +will enable full fledged scheduling for consumers. + +Third party software and OMA Data Synchronization server vendors can +increase customer satisfaction and reduce defects by using iCalendar due to +the combination of needing to support only a single data object format and the +more reliable representation of calendar data. The ongoing active +development of the iCalendar standard provides implementers with a vehicle +for promoting change. + +Mobile operating system vendors and device manufacturers will benefit from +wider adoption of iCalendar. The improved interoperability with third party +software and server implementations that can be achieved with iCalendar will +result in less reported user defects. This in turn should result in reduced +support costs. With an industry-wide push towards iCalendar, server vendors +will be encouraged to support devices also claiming such support. + +For mobile operators, solutions that are more reliable will result in increased +usage of calendar access and synchronization, which should show in +increased data revenues. Using iCalendar and taking advantage of iCalendar +content that is available on the Internet, a richer set of applications and value +added premium services can result. + +The benefits of iCalendar continue to improve as ongoing work to clarify and +simplify the standard continues in the IETF Calsify working group. While +vCalendar can no longer evolve, iCalendar as a data object format continues +to takes steps towards being the needed standard data object format. + +== Efforts underway to improve interoperability + +It is well understood that even if iCalendar were widely adopted throughout +the industry, this alone would not solve the issue of interoperability that users +experience today. Fortunately, there are ongoing efforts to help address +issues of interoperability. + +The Calsify effort in the IETF is chartered to revise the core iCalendar +specifications to fix any problems discovered over the years during +interoperability testing. This effort involves not only fixing issues in the +specifications, but also an analysis of areas where simplification may be +required. The core documents RFC2445, RFC2246 and RFC2447 have new +draft revisions available, and these are actively being worked on as of +November 2006. It is expected that this work will complete in early 2007. + +The Calendaring & Scheduling Consortium is committed to helping bring +about appropriate updates to the iCalendar specifications. As part of this +effort, it has organized technical committees to study some of the more +problematic areas such as recurrences and time zones. + +The consortium's technical committees have published the following papers: + +* Time zone Registry & Service Recommendations +* Time zone Problems & Recommendations +* Recurrence Problems & Recommendations + +Fixing issues within the iCalendar specifications will certainly help, but many +issues could be solved now through increased interoperability testing by +vendors. Recognizing this fact, the MOBILE Technical Committee (TCMOBILE) +of the Calendaring & Scheduling Consortium has begun working on +a Mobile Calendaring Synchronization Test Suite that it hopes to publish by +January 2007. This test suite will focus on the actual iCalendar payload and +issues related to interpreting calendar data. + +Working with the Interoperability Testing Technical Committee (TCIOPTEST), +also from the Calendaring & Scheduling Consortium, work is +underway to host Calendaring Interoperability Tests Events (CITEs) where +vendors will be able test their implementations using this new test suite. + +All of these efforts are directed at improving the iCalendar specifications and +the usage of these specifications. Only through the widespread adoption of +iCalendar can these efforts truly help address issues of interoperability. + +== Conclusion + +Mobile calendaring is something users want but it has to be something they +can rely on. The mobile industry must overcome the current issues related to +interoperability. The starting point for this is the widespread adoption of +iCalendar. + +For more information on the efforts of the Calendaring & Scheduling +Consortium, please visit http://www.calconnect.org/. + +[[appendix-A]] +[appendix] +== {blank} + +[options=header] +.New properties defined in iCalendar +|=== +| Property Name | Section in RFC 2445 +| `ACTION` | 4.8.6.1 +| `CALSCALE` | 4.7.1 +| `COMMENT` | 4.8.1.4 +| `CONTACT` | 4.8.4.2 +| `DTSTAMP` | 4.8.7.2 +| `DURATION` | 4.8.2.5 +| `FREEBUSY` | 4.8.2.6 +| `METHOD` | 4.7.2 +| `ORGANISER` | 4.8.4.3 +| `PERCENT-COMPLETE` | 4.8.1.8 +| `RECURRENCE-ID` | 4.8.4.4 +| `REPEAT` | 4.8.6.2 +| `REQUEST-STATUS` | 4.8.8.2 +| `TRIGGER` | 4.8.6.3 +| `TZID` | 4.8.3.1 +| `TZNAME` | 4.8.3.2 +| `TZOFFSETFROM` | 4.8.3.3 +| `TZOFFSETTO` | 4.8.3.4 +| `TZURL` | 4.8.3.5 +|=== + +[options=header] +.New property value data types defined in iCalendar +|=== +| Property Value Data Type | Section in RFC 2445 +| Boolean | 4.3.2 +| Calendar User Address | 4.3.3 +| Date | 4.3.4 +| Float | 4.3.7 +| Integer | 4.3.8 +| Period of Time | 4.3.9 +| Recurrence Rule | 4.3.10 +| Text | 4.3.11 +| Time | 4.3.11 +| UTC Offset | 4.3.14 +|=== + +[options=header] +.New property parameters defined in iCalendar +|=== +| Property Parameter Name | Section in RFC 2445 +| `ALTREP` | 4.2.1 +| `CN` | 4.2.2 +| `CUTYPE` | 4.2.3 +| `DELEGATED-FROM` | 4.2.4 +| `DELEGATED-TO` | 4.2.5 +| `DIR` | 4.2.6 +| `FMTTYPE` | 4.2.8 +| `FBTYPE` | 4.2.9 +| `MEMBER` | 4.2.11 +| `PARTSTAT` | 4.2.12 +| `RANGE` | 4.2.13 +| `RELATED` | 4.2.14 +| `RELTYPE` | 4.2.15 +| `RSVP` | 4.2.17 +| `SENT-BY` | 4.2.18 +| `TZID` | 4.2.19 +|=== + +[options=header] +.Mapping between vCalendar and iCalendar properties +|=== +| vCalendar property name | iCalendar property name | Section in RFC2445 +| `DAYLIGHT` | Replaced by `VTIMEZONE` component | 4.6.5 +| `GEO` | `GEO` | 4.8.1.6 +| `PRODID` | `PRODID` | 4.7.3 +| `TZ` | Replaced by `VTIMEZONE` component | 4.6.5 +| `VERSION` | `VERSION` | 4.7.4 +| `ATTACH` | `ATTACH` | 4.8.1.1 +| `ATTENDEE` | `ATTENDEE` | 4.8.4.1 +| `AALARM` | Replaced by `VALARM` component | 4.6.6 +| `CATEGORIES` | `CATEGORIES` | 4.8.1.2 +| `CLASS` | `CLASS` | 4.8.1.3 +| `DCREATED` | `CREATED` | 4.8.7.1 +| `COMPLETED` | `COMPLETED` | 4.8.2.1 +| `DESCRIPTION` | `DESCRIPTION` | 4.8.1.5 +| `DALARM` | Replaced by `VALARM` component | 4.6.6 +| `DUE` | `DUE` | 4.8.2.3 +| `DTEND` | `DTEND` | 4.8.2.2 +| `EXDATE` | `EXDATE` | 4.8.5.1 +| `EXRULE` | `EXRULE` | 4.8.5.2 +| `LAST-MODIFIED` | `LAST-MODIFIED` | 4.8.7.3 +| `LOCATION` | `LOCATION` | 4.8.1.7 +| `MALARM` | Replaced by `VALARM` component | 4.6.6 +| `RNUM` | No equivalent property, iCalendar `RECUR` property value type allows the number of occurrences to be specified | +| `PRIORITY` | `PRIORITY` | 4.8.1.9 +| `PALARM` | Replaced by `VALARM` component | 4.6.6 +| `RELATED-TO` | `RELATED-TO` | 4.8.4.5 +| `RDATE` | `RDATE` | 4.8.5.3 +| `RRULE` | `RRULE` | 4.8.5.4 +| `RESOURCES` | `RESOURCES` | 4.8.1.10 +| `SEQUENCE` | `SEQUENCE` | 4.8.7.4 +| `DTSTART` | `DTSTART` | 4.8.2.4 +| `STATUS` | `STATUS` | 4.8.1.11 +| `SUMMARY` | `SUMMARY` | 4.8.1.12 +| `TRANSP` | `TRANSP` | 4.8.2.7 +| `URL` | `URL` | 4.8.4.6 +| `UID` | `UID` | 4.8.4.7 +| `X-` | `X-` | 4.8.8.1 +|=== + +[heading=bibliography] +== Resources + +[bibliography,normative=false] +=== iCalendar Specifications + +* [[[rfc2445,IETF RFC 2445]]] + +* [[[rfc2446,IETF RFC 2446]]] + +* [[[rfc2447,IETF RFC 2447]]] + +* [[[rfc3283,IETF RFC 3283]]] + +[bibliography,normative=false] +=== CalDAV Specifications + +* [[[cd-access,CALDAV-ACCESS]]], Calendaring Extensions to WebDAV. +http://www.ietf.org/internet-drafts/draft-dusseault-caldav-14.txt. +// EDITOR: Non-existing link, auto-fetching `IETF I-D draft-dusseault-caldav-14` fails. This should now be RFC 4791. + +* [[[cd-sched,CALDAV-SCHED]]], Scheduling Extensions to CalDAV +http://www.ietf.org/internet-drafts/draft-desruisseaux-caldav-sched-02.txt. +// EDITOR: Non-existing link, auto-fetching `IETF I-D draft-desruisseaux-caldav-sched-02` fails. This should now be RFC 6638. + +[bibliography,normative=false] +=== Implementations + +* [[[libical,LIBICAL]]], libical C library. http://freshmeat.net/projects/libical. + +* [[[ical4j,ICAL4J]]], iCal4j Java library. http://ical4j.sourceforge.net. + +* [[[vobject,VOBJECT]]], VObject Python library. http://vobject.skyhouseconsulting.com. + +[bibliography,normative=false] +=== iCalendar on the Web + +* [[[icalshare,ICALSHARE]]], Shared, searchable calendars. http://www.icalshare.com + +* [[[eventful,EVENTFUL]]], Local events. http://eventful.com + +[bibliography,normative=false] +=== Efforts to improve Interoperability + +* [[[calsify,IETF CALSIFY]]], Charter for IETF iCalendar Simplification Working Group. +http://www.ietf.org/html.charters/calsify-charter.html. + +* [[[cc-tz-registry,CC 0606]]] + +* [[[cc-tz-problems,CC/R 0602]]] + +* [[[cc-recurrence,CC/R 0604]]] + +[bibliography,normative=false] +=== CalConnect Mobile Calendaring Questionnaire + +* [[[cc-mob-calendaring,CC/R 0609]]] diff --git a/sources/cc-0612-report-ioptest/document.adoc b/sources/cc-0612-report-ioptest/document.adoc new file mode 100644 index 0000000..a7d848d --- /dev/null +++ b/sources/cc-0612-report-ioptest/document.adoc @@ -0,0 +1,347 @@ += Calendar Interoperability Test Report, September 26-27, 2006 +:docnumber: 0612 +:copyright-year: 2006 +:language: en +:doctype: administrative +:edition: 1.2 +:status: published +:revdate: 2006-12-06 +:published-date: 2006-12-06 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Patricia Egen +:role: author +:fullname_2: Michael Douglass +:role_2: author +:fullname_3: Grant Bailie +:role_3: author +:fullname_4: Cyrus Daboo +:role_4: author +:fullname_5: Scott Adler +:role_5: author +:fullname_6: Matt Willis +:role_6: author +:fullname_7: Pat Egen +:affiliation_7: CalConnect +:role_7: editor + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +Chair(s):: Pat Egen + +== Introduction + +This document contains notes and results from the September 2006 calendar interoperability event held +at the Apple complex in Cupertino, CA. The basic purpose of the event was to start testing Free Busy +and Scheduling in CALDAV. In addition, there was continued testing of iCalendar events by the Eventful +organization. + +The chart below shows the attendees, their organization and the products they were testing. + +=== Attendees + +[%unnumbered,options=header] +|=== +| Attendees | Organization | Products +| Chuck Norris | EVDB | Eventful server +| Jeffrey Harris | OSAF | Chandler client +| Grant Baile | OSAF | Chandler client +| Mikael Rogers | OSAF | Chandler client +| Brian Mosely | OSAF | Cosmos server +| Mike Douglass | RPI | Bedework server +| Cyrus Daboo | Apple | Apple server +| Wilfredo Sanchez | Apple | Apple server +| Red Dutta | Apple | Apple client -- ical Version 3.0 (1118) +| Scott Adler | Apple | Apple client +| Haley Allen | Apple | Apple client +| Dan Mosedale | Mozilla | Sunbird / Lightening 0.3 Release Candidate +| Matt Willis | Mozilla | Sunbird / Lightening 0.3 Release Candidate +|=== + +== General Comments + +The following applications and products were tested: + +* Four CALDAV servers - RPI, Oracle, Apple and OSAF (Cosmo) +* Three CALDAV clients - OSAF (Chandler), Mozilla, and Apple +* Absorbing Recurrence rules (RFC 2445 and RFC 2447) by Eventful. + +Free Busy and Scheduling are recent additions to CALDAV. However, we had three clients testing +CALDAV against four CALDAV servers this event. This is a three-fold increase over the last interop +testing. Since scheduling is the most recent addition to CALDAV there was limited testing of that part of +the specification. + +The following paragraphs discuss items tested during the interop. The actual matrix showing the specific +test cases is provided at the end of this document. + +The first part of the testing covered Event creation and modification. Two of the vendors were able to +pass and test all items against two servers. The other vendors were able to pass several, but not all of +the items in the testing suite. + +The second part of the testing covered Event Modification. Again, two vendors supported and passed +testing of the nine items against two servers. One vendor did not participate in this test. + +The third part of the testing covered Event Retrieval via CalDAV reports, which, at present no one +supports and therefore was not tested. + +The fourth part covered Event Deletion. There were five items to test and two vendors supported and +passed testing against two servers. + +The fifth part covered Access Control and no one either supports or tested any of the four test items. + +The sixth part covered Calendar Management. Two vendors do not have support for this and another +vendor only supports two of the six test items. + +The seventh part of the test was Free Busy Reports. Only one vendor supported and tested this section. +They tested and passed eleven items against one of the testing servers. + +The eighth and final section tested Scheduling. There were 7 test cases and one vendor supported and +passed four of the items against one server only. No other clients tested this section. + +Following now are comments submitted by the test participants. + +=== First set of comments + +We found the interoperability lab to be a very valuable exercise, and during the course of the two days +were able to make changes in our current application. At then end of the two days we were +communicating with all four servers, reading data, making changes with three of them. Most of the +changes were based on incorrect assumptions, caused by developing with only one server. Moving +forward, having access to multiple implementations will let us build a much more robust client. + +As for the event itself, having face to face contact, and immediate bug fixing on both sides was extremely +valuable to a quick development process. Doing this remotely might work, but the fact that we can bring +laptops right to the people writing the server, or ask the other clients to modify data made the whole event +go smoothly. + +Some issues we encountered with specifically: + +* Their application depends on valid principals with calendar- home-set properties; not all the +servers had this set up. +* Calendar User Addresses are an issue, the fact that they can be anything, even email addresses +that they are using elsewhere in their application was causing them problems with scheduling. +* They were using relative paths in some cases where servers were expecting full paths +* Also a couple of other minor issues, not really worth getting into here. + +We realize this interoperability meeting was focused on client/server compatibility. One thing we would +like to see in the future is more multi-client read write access to the same data on the same server and +then making sure that everything still works. For example, have one vendor create a lot of calendar data +on their server with their client, then let our application read and modify the data, then see that it shows +up correctly the receiving application. + +"Overall this was a great event, and we look forward to the next one." + +=== Second set of comments + +Our server team was pleased to participate in this CalConnect IOP. We had the absolute latest version of +our CalDAV server available for testing on two machines. + +All clients were tested against the server during the course of the event. No major problems were found in +our server implementation. On the whole other clients do not yet support some of the more 'advanced' +features such as access control and scheduling, so significant portions of the code were not exercised, +but those portions that were performed as expected. We are not aware of any significant problems clients +had with working with our server as compared to others. + +Overall we found this to be a valuable experience and look forward to participating again in the future. + +=== Third set of comments + +. One vendor requires a principal resource with the CALDAV:calendar-home-set property so that it can +locate a user's calendar collections. The developer added support to their application for WEBDAV +principals (section 4 of the ACL spec). ++ +-- +One application had problems renaming calendars. This operation uses WEBDAV `MOVE` underneath. It +turns out that the application was sending a relative URI in the Destination header which RFC 2518 +specifies must contain an absolute URI. The developer beefed up the code to handle both forms and I +believe the folks changed to absolute, so all was well after that. +-- +. One vendor did some amount of testing with their application, but the developer wasn't directly involved +and they never communicated any issues to him. +. Another vendor ran the CALDAV test suite from their calendar server and found an issue when +``DELETE``ing a null resource. +. An unknown party exposed a bug wherein a vendor application errored when receiving any CALDAV +`REPORT` against a regular (non-calendar) collection. + +The developer fixed all of these issues yesterday and then waited to hear about anything else that came +up the next day. Nothing was reported. + +=== Fourth Set of Comments + +One vendors application converts individual to UTC time. They also move floating recurr to UTC. Syncing +unlimited recurrence fails. It also adds Alarms to every event. We found that this application rewrites +exceptions as RDates and Exdates. Another vendor's handling of modifications loses non-time pieces of +these exceptions. All-day event creation fails on another vendors application. We also noted that +another vendor does not send durations. + +With regards to the specific items tested, they noted the following: + +. While verifying two free busy periods, they actually got three free-busy periods noted. So far as they +could tell, both forms are valid (i.e. servers & clients are free to coalesce free-busy as they see fit). +. While testing against one vendor application they noted the following: +.. The server deleted ``VALARM``s stored with events +.. Modifications to recurring events caused an internal server error (500 HTTP response) +.. The server never changes ETags, so a second client isn't able to sync properly, since it +thinks events haven't changed since previous sync. +.. The HTTP `DELETE` request succeeded, but the collection stayed on the server. +.. The server returned an empty (HTTP 204) response to a valid free-busy-request `REPORT`. + +=== Fifth Set of Comments + +They were very happy to exchange iCalendar objects to send to their server. Several attendees sent +objects to help them test their iCalendar support, in particular recurring events. They found issues when +absorbing iCalendar recurrence events. These will be useful in helping them streamline their software. + +=== Sixth Set of Comments + +They tested their products against both servers. They also tested against another application. Not +having stop time or no DTStart on timed event did cause some problems. They may need to put some +kind of Note on events with no stop time or something like a ragged edge Icon on items with no end +times. However, this may break scheduling with no end time. They also noted that the +organizer object in one vendor's application is an issue. Another vendor doesn't allow the creator to +update the principle. + +=== Seventh set of Comments + +We assume testers will have found some problems in the area of recurrences when working with our +product. They are currently working on rewriting that support. + +One vendor ran across a problem with a recurrent event that proved to be an ical4j bug. This is now +fixed. + +Another vendor's application etags were broken and are now fixed. + +We partially fixed a problem deleting calendars. + +== Summary + +As usual, the interoperability testing revealed problems with servers that no one knew about. These were +resolved quickly in many cases or will be resolved when the attendees get back to their respective +facilities. It is always better to test something before it goes production and that is one of the things we +can provide -- a safe, non-public forum and environment for testing software interoperability. + +Issues that came out of the testing included principle support, attachments and calendar discovery. +There needs to be something defined to better identify and discover calendar servers. In addition, there +needs to be a better mechanism for handling attachments, including what kind of controls should be put in +place. It was also noted that it would be good to have more report examples to help with development +and testing. + +Following this document is a matrix of the CALDAV test matrix showing what items passed, failed or were +not tested or supported. + +Respectfully submitted, Pat Egen. Interoperability Event Manager + +[appendix] +== CalDAV Testing Matrix + +[options=header,headerrows=2,cols="^,<,^,^,^,^,^,^,^,^,^,^,^,^"] +.6^th^ CalDAV Interop Testing Event -- September 2006 +|=== +| .2+| 3+| Server 1 3+| Server 2 3+| Server 3 3+| Server 4 +| | A | B | C | A | B | C | A | B | C | A | B | C + +| 1. h| Event creation. | | | | | | | | | | | | +| 1.1. a| Create new single-instance meeting titled "Meeting 1.1" with the location "Durham". | P | P | P | P | P | | | P | P | | N | P +h| 1.2. a| Create new meeting titled "Meeting 1.2" recurring every Monday from 10:00 AM to 11:00 AM for 4 weeks | P | P | P | P | P | | | P | P | | N | P +| 1.3. a| Create new single-instance meeting titled "Meeting 1.3" with 2 other attendees. | P | P | N | P | P | | | P | N | | N | N +| 1.4. a| Create new single-instance meeting titled "Meeting 1.4" with an alarm set to trigger 15 minutes prior to the schedule time of the meeting | P | P | P | P | P | | | P | F | | N | P +| 2. h| Event modification | | | | | | | | | | | | +| 2.1. | Modify the title of meeting "Meeting 1.1" to "Meeting 1.1bis". | P | P | P | P | P | | | | P | | N | P +| 2.2. | Modify the location of the meeting "Meeting 1.1bis" to "Seattle bis". | P | P | P | P | P | | | | P | | N | P +| 2.3. | Reschedule meeting "Meeting 1.1bis" to the next day. | P | P | P | P | P | | | | P | | N | P +| 2.4. | Add an attendee to "Meeting 1.1bis". | P | P | N | P | P | | | | N | | N | N +| 2.5. | Add an alarm to "Meeting 1.1bis". | P | P | P | P | P | | | | F | | N | P +| 2.6. | Modify the title of the 1st instance of the recurring meeting created in 1.2. | P | P | P | P | P | | | | F | | N | F +h| 2.7. | Modify the participation status of the 1st attendee in meeting 1.3 to `DECLINED`. | P | P | N | P | N | | | | P | | N | N +| 2.8. | Cancel the 4th instance of the recurring meeting created in 1.2. | P | P | P | P | P | | | | V | | N | N +| 2.9. | One client changes "Meeting 1.1bis" to a different time, second client 'refreshes' its display to see the modification. | P | P | P | P | P | | | | F | | N | P +| 3. h| Event retrieval | | | | | | | | | | | | +| 3.1. | calendar-query `REPORT` | | N | N | | N | | | | N 2+| N | +| 3.1.1. | No filtering (match everything) | | N | N | | N | | | | N 2+| N | +| 3.1.1.1. | Query all components and return all data. (tests `` and ``) | | N | N | | N | | | | N 2+| N | +| 3.1.1.2. | Query all components and return ETag WebDAV property and all data. (tests `+` and ``) | | N | N | | N | | | | N 2+| N | +| 3.1.1.3. | Query all components and return just entire `VEVENT` components. (tests ``, `+`) | | N | N | | N | | | | N 2+| N | +| 3.1.1.4. | Query all components and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `+`, `++`) | | N | N | | N | | | | N 2+| N | +| 3.1.2. | time-range filtering | | N | N | | N | | | | N 2+| N | +| 3.1.2.1. | Query all components within a one day time-range and return all data. Make sure that there is a recurring event that starts prior to the chosen time-range but has one non-overridden instance within the time-range. (tests ``, `+`) | | N | N | | N | | | | N 2+| N | +| 3.1.2.2. | Query all components within a one week time-range and return just entire `VEVENT` components. Make sure that there is a recurring event that starts prior to the chosen time-range but has one overridden instance within the time-range. (tests ``, `+`) | | N | N | | N | | | | N | | N | +| 3.1.3. | component based filtering | | N | N | | N | | | | N 2+| N | +| 3.1.3.1. | Query all components that contain an embedded `VALARM` component. (tests ``, `+`) | | N | N | | N | | | | N 2+| N | +| 3.1.3.2. | Query all components that contain an embedded `VALARM` component whose trigger falls within a specific time-range. (tests ``, `+++`) | | N | N | | N | | | | N 2+| N | +| 3.1.4. | property based filtering | | N | N | | N | | | | N 2+| N | +| 3.1.4.1. | Query all components that contain any `ORGANIZER` property. (tests ``, `++`) | | N | N | | N | | | | N 2+| N | +| 3.1.4.2. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-insensitively. (tests ``, `+++`) | | N | N | | N | | | | N 2+| N | +| 3.1.4.3. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-sensitively. (tests ``, `+++`) | | N | N | | N | | | | N 2+| N | +| 3.1.5. | parameter based filtering | | N | N | | N | | | | N 2+| N | +| 3.1.5.1. | Query all components that contain a `DTSTART` property with a `TZID` parameter. (tests ``, `++++`) | | N | N | | N | | | | N 2+| N | +| 3.1.5.2. | Query all components that contain an `ATTENDEE` property with `PARTSTAT=NEEDS-ACTION` parameter. (tests ``, `++++`) | | N | N | | N | | | | N 2+| N | +| 3.2. | calendar-multiget `REPORT` | | N | N | | N | | | | N 2+| N | +| 3.2.1. | Query a specific `href` and return all data. (tests ``) | | N | N | | N | | | | N 2+| N | +| 3.2.2. | Query multiple ``href``s (some of which do not exist) and return all data. (tests ``) | | N | N | | N | | | | N 2+| N | +| 3.2.3. | Query a specific `href` and return ETag WebDAV property and all data. (tests `+`) | | N | N | | N | | | | N 2+| N | +h| 3.2.4. | Query multiple ``href``s (some of which do not exist) and return ETag WebDAV property and all data. (tests `+`) | | N | N | | N | | | | N 2+| N | +| 3.2.5. | Query a specific `href` and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) | | N | N | | N | | | | N 2+| N | +| 3.2.6. | Query multiple ``href``s (some of which do not exist) and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) | | N | N | | N | | | | N 2+| N | +| 4. h| Event deletion | | | | | | | | | | | | +| 4.1. | Delete a single non-recurring meeting. | P | | P | | P | | | | P | | N | P +| 4.2. | Delete a single recurring meeting with no overridden instances. | P | | P | | P | | | | P | | N | P +h| 4.3. | Delete a single recurring meeting with overridden instances. | P | | P | | P | | | | P | | N | P +| 4.4. | Delete a non-overridden instance of a recurring meeting. | P | | P | | P | | | | P | | N | P +| 4.5. | Delete an overridden instance of a recurring meeting. | P | | P | | P | | | | P | | N | P +| 5. h| Access Control | | | | | | | | | | | | +| 5.1. | View access control details on current user's main calendar. | N | | N | N | N | | | | N | | N | +h| 5.2. | Change access control details on current user's main calendar to add another user with read-only access. Verify that other user can view the calendar but not change it. | N | | N | N | N | | | | N | | N | +| 5.3. | Change access control details on current user's main calendar to add another user with read-write access. Verify that other user can view the calendar and change it. Verify that changes done by one user are seen by the other. | N | | N | N | N | | | | N | | N | +| 5.4. | Remove another user's access to the current user's main calendar and verify they can no longer access the calendar. | N | | N | N | N | | | | N | | N | +| 6 h| Calendar Management | | | | | | | | | | | | +| 6.1 | Browse the list of calendars on the server, including the current user's personal calendars. | N | N | P | N | N | | | | P | | N | +| 6.2 | Create a new calendar in the current user's personal calendar space. | N | P | P | N | P | | | | P | | N | +| 6.3 | Create a regular collection in the current user's personal calendar space. | N | N | N | N | N | | | | N | | N | +h| 6.4 | Create a new calendar inside the collection created in 6.3. | N | N | N | N | N | | | | N | | N | +| 6.5 | Delete the calendar created in 6.2. | N | P | P | N | P | | | | F | | N | +| 6.6 | Delete the collection created in 6.3. | N | N | N | N | N | | | | N | | N | +| 7 h| Free Busy Reports | | | | | | | | | | | | +| Setup a| Create a new calendar and populate it with the following for one week: + +Event on Monday, 9 am - 11 am, recurs every day for five times + +Event on Monday, 12 pm - 1 pm, status tentative + +Event on Monday, 2 pm - 3 pm, status cancelled + +Event on Tuesday, 11 am - 12 pm + +Event on Tuesday, 2 pm - 4 pm, recurs every day for four times + +Event on Tuesday, 3 pm - 5 pm + +Event on Wednesday, 11 am - 12 pm, status tentative + +Event on Wednesday, 3 pm - 5 pm, status tentative + +Event on Thursday, 11 am - 12 pm, status cancelled + +Event on Thursday, 3 pm - 5 pm, status cancelled | N | N | | N | N | | | | | | N | P +| 7.1 | Run a free-busy report for the entire week. | N | N | P | N | N | | | | F | | N | P +| 7.1.1 | Verify two `FREEBUSY` periods for Monday, the second is `BUSY-TENTATIVE`. | N | N | P | N | N | | | | F | | N | P +| 7.1.2 | Verify two `FREEBUSY` periods for Tuesday. | N | N | P | N | N | | | | F | | N | P +| 7.1.3 | Verify four `FREEBUSY` periods for Wednesday, second and fourth are `BUSY-TENTATIVE` and one hour long. | N | N | P | N | N | | | | F | | N | P +| 7.1.4 | Verify two `FREEBUSY` periods for Thursday. | N | N | P | N | N | | | | | | N | P +| 7.1.5 | | N | N | P | N | N | | | | F | | N | P +| | | N | N | | N | N | | | | | | N | P +| | | N | N | | N | N | | | | | | N | P +| | | N | N | | N | N | | | | | | N | P +| 7.1.5 | Verify two `FREEBUSY` periods for Friday. | N | N | P | N | N | | | | | | N | P +| 8 h| Scheduling | | | | | | | | | | | | +| Setup | Three user accounts user1 (role Organizer), user2 (role Attendee), user3 (role Attendee) provisioned with suitable principal properties for calendar home, inbox, outbox and user addresses. | N | P | N | N | N | | | | | | N | +| 8.1 | Organizer (user1) sends non-recurring message invite for Monday at 9am (1 hour) to each attendee. Verify that each attendee Inbox receives a copy of the invite. | N | P | N | N | N | | | | | | N | +| 8.2 | Attendee (user2) accepts invite and sends back reply. Verify that reply is placed in Organizer Inbox. | N | P | N | N | N | | | | | | N | +| 8.3 | Organizer (user1) updates invite with user2 accept state and resends invite. Verify that each attendee Inbox receives a copy of the new invite. | N | N | N | N | N | | | | | | N | +| 8.4 | Attendee (user3) accepts updated invite and sends back reply. Verify that reply is placed in Organizer Inbox. | N | N | N | N | N | | | | | | N | +| 8.5 | Organizer (user1) updates invite with user3 accept state and resends invite. Verify that each attendee Inbox receives a copy of the new invite. | N | N | N | N | N | | | | | | N | +| 8.6 | Organizer (user1) cancels the invite. Verify that each attendee Inbox receives the cancellation. | N | P | N | N | N | | | | | | N | +|=== + +[%key] +A, B, C:: Client implementations +P:: Pass +F:: Fail +N:: Not supported diff --git a/sources/cc-0613-report-roundtable-5/document.adoc b/sources/cc-0613-report-roundtable-5/document.adoc new file mode 100644 index 0000000..21eb8b9 --- /dev/null +++ b/sources/cc-0613-report-roundtable-5/document.adoc @@ -0,0 +1,105 @@ += Report on Roundtable V, 09-12 January 2006 +:docnumber: 0613 +:copyright-year: 2006 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2006-01-12 +:published-date: 2006-01-12 +:technical-committee: CALCONNECT +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Introduction + +Roundtable V took place on January 9-12, 2006, hosted by Novell in Provo, Utah. Monday +January 9th and Tuesday morning the 10th were a dedicated CalConnect Interoperability Event +where seven organizations performed interoperability testing on their calendaring and scheduling +implementations. The Roundtable itself convened midday on Tuesday the 10th and closed midday +on Thursday the 12th. As usual, most of the time was dedicated to technical committee sessions, +with an all-hands Plenary meeting at the end. The Technical Committee sessions were organized +sequentially, to allow all attendees who wished to be involved in the discussions of a Technical +Committee the opportunity to do so. Delegates were also present from The Open Group +Messaging Forum to discuss a possible joint endeavor with respect to a Federated Freebusy +Challenge which the TOG/MF has issued. + +== Update on Technical Committees and Initiatives + +*Work Products*: _The iCalendar Timezone Problems and Recommendations_ document and an +update to the _Min-IOP Use Cases_ document were approved for publication and have been +published on the Consortium web site. The _Timezone Registry/Resource Recommendations_ +document, _Calendaring Glossary_, and _Recurrence Problems and Recommendations_ document, +among others, are in progress; the Recurrence document is intended to be published in time to be +delivered to the CALSIFY Working Group of the IETF in March. + +*TC-AUTHENTICATE* is undertaking a study of authentication schemes used by existing +calendaring and scheduling implementations (many proprietary) in preparation for +recommendations for short-term and longer-term authentication methods for calendaring. The +study will be published when complete. + +*TC-CALDAV* is beginning work on use cases and requirements for CalDAV Scheduling as input +to the development of the scheduling draft for CalDAV. The TC is also considering requirements +for a specialized Freebusy Service component for CalDAV which might address the TOG/MF +requirement mentioned above. + +*TC-EVENTPUB* has conducted a survey on existing event publication systems, and is working +on requirements for expanded location information in iCalendar to support the needs for event +publication. + +*TC-MOBILE* is conducting a survey of calendaring with mobile devices and has begun the +development of a problem statement to define the requirements for open, interoperable +calendaring with mobile devices. The TC hopes to liaise with the OMA in April and invite their +participation in the May Roundtable to assist in developing the requirements for calendaring and +scheduling standards to support mobile devices. + +*TC-REALTIME* is beginning the refinement of use cases associated with "real time" server-toserver +communcation. + +*TC-RECURR* is in the process of refining its Problems and Recommendations document to be +delivered to the IETF Calsify Working Group in time for their March meeting. + +*TC-TIMEZONE* has completed its Problems and Recommendations document for publication +and is working on a Timezone Registry and Service recommendations document. + +*TC-USECASE* has completed its Min-IOP Use Cases document for publication and is working on +the Calendaring Glossary document. + +*CalConnect Interoperability Event*: Participants in the interoperability testing event included +EVDB, Mozilla, Novell, Oracle, OSAF, RPI (Rensselaer Polytechnic Institute) and Trumba. +Results from the event will be posted at Past IOP Reports. + +== Future Meetings + +The next meeting (Roundtable VI) will take place 22-25 May 2006, hosted by IBM/Lotus in +Cambridge, Massachusetts. Based on the successful model for Roundtable V, where the +CalConnect Interoperability Event was conducted the first 1.5 days, followed by the Roundtable, +this model will be continued at Roundtable VI. diff --git a/sources/cc-0614-report-roundtable-6/document.adoc b/sources/cc-0614-report-roundtable-6/document.adoc new file mode 100644 index 0000000..6a8aff0 --- /dev/null +++ b/sources/cc-0614-report-roundtable-6/document.adoc @@ -0,0 +1,109 @@ += Report on Roundtable VI, 22-25 May 2006 +:docnumber: 0614 +:copyright-year: 2006 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2006-05-23 +:published-date: 2006-05-23 +:technical-committee: CALCONNECT +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Introduction + +Roundtable VI took place on May 22-25, 2006, hosted by IBM/Lotus in Cambridge, +Massachusetts. Monday May 22nd and Tuesday morning the 23rd were a dedicated CalConnect +Interoperability Event where participating organizations performed interoperability testing on their +calendaring and scheduling implementations. + +Tuesday morning a pair of Practicums on iCalendar standards and on CalDAV were offered. The +Roundtable itself convened midday on Tuesday the 23rd and closed midday on Thursday the 25th. + +Tuesday afternoon was dedicated to a Mobile Calendaring Workshop, sponsored by TC-MOBILE +(and replacing TC MOBILE's regular working session). + +Wednesday, and part of Thursday morning, were dedicated to the other technical committee +sessions, with an all-hands Plenary meeting at the end. The Technical Committee sessions were +organized sequentially, to allow all attendees who wished to be involved in the discussions of a +Technical Committee the opportunity to do so. + +== Update on Technical Committees and Initiatives + +*Work Products*: Since Roundtable V, _Recurrence Problems and Recommendations_ document and +the _Timezone Registry and Service Recommendations_ have been published. The _Calendaring +Glossary_ should proceed to last call shortly, as should the _Mobile Calendaring Questionnaire +Results_ Document. + +*TC-AUTHENTICATE* is monitoring discussion on the issues of http authentication leading up to +the IETF meeting in July. + +*TC-CALDAV* is working on requirements for CalDAV Scheduling as input to the development of +the scheduling draft for CalDAV. + +*TC-EVENTPUB* has developed a proposal for a `VVENUE` extension to iCalendar to support +event publication with expanded information, and plans to submit it as an individual draft to the +IETF. + +*TC-FREEBUSY* was formed at this Roundtable to coordinate CalConnect efforts associated with +The Open Group Federated Free/Busy Challenge, leading to a proof of concept demonstration in +Mid-July. + +*TC-MOBILE* conducted its Mobile Calendaring Workshop at this Roundtable and will publish +the results of its mobile calendaring questionnaire shortly. The TC is beginning work on a white +paper delineating the reasons for (especially) mobile device and software manufacturers and +operators to migrate to iCalendar from vCalendar. + +*TC-REALTIME* is actively working on the issues associated with server to server +communication. + +*TC-RECURR* was disbanded, having completed its charter. + +*TC-TIMEZONE* was disbanded, having completed its charter. + +*TC-USECASE* has completed work on the Calendaring Glossary document, which will go to Last +Call in the Consortium shortly, and has begun work on the minimum interoperable subset for tasks +(``VTODO``s). + +*CalATOM Ad Hoc Group*: A discussion mailing list on CalATOM and associated issues such as +RSS was formed at this Roundtable. The discussion list is open to interested individuals whether +or not they represent CalConnect members. + +*CalConnect Interoperability Event*: Participants in the interoperability testing event included +EVDB, Oracle, OSAF and RPI (Rensselaer Polytechnic Institute). Results from the event will be +posted at Past IOP Reports. + +== Future Meetings + +The next meeting (Roundtable VII) will take place 26-29 September 2006 in the San Francisco +Bay Area. The following meeting (Roundtable VIII) will take place in mid-January, probably on +the East Coast. diff --git a/sources/cc-0615-report-roundtable-7/document.adoc b/sources/cc-0615-report-roundtable-7/document.adoc new file mode 100644 index 0000000..67bedc7 --- /dev/null +++ b/sources/cc-0615-report-roundtable-7/document.adoc @@ -0,0 +1,126 @@ += Report on Roundtable VII, 26-29 September 2006 +:docnumber: 0615 +:copyright-year: 2006 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2006-09-29 +:published-date: 2006-09-29 +:technical-committee: CALCONNECT +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Introduction + +Roundtable VII took place on September 26-29, 2006, hosted by Apple Computer in Cupertino, +California. The event was attended by sixty representatives to the IOP testing and/or the +Roundtable, including representatives from nine observers (organizations attending a Roundtable +to see if they wish to join). + +Tuesday September 26th and Wednesday morning the 27th were a dedicated CalConnect +Interoperability Test Event where participating organizations performed interoperability testing on +their calendaring and scheduling implementations. Wednesday morning a reprise of the Federated +Free/Busy demo originally done at The Open Group meeting in Miami in July, 2006 was arranged. +Wednesday afternoon, all day Thursday, and Friday morning comprised the Roundtable. The +majority of this time was dedicated to technical committee sessions, with an all-hands Plenary +meeting as the last item on Friday morning. The Technical Committee sessions were organized +sequentially, to allow all attendees who wished to be involved in the discussions of a Technical +Committee the opportunity to do so. + +== Update on Technical Committees and Initiatives + +*Work Products*: Since Roundtable VI, the _Mobile Calendaring Questionnaire Results_ Document +has been published. The _Calendaring and Scheduling Glossary of Terms_ will be published shortly +after Roundtable VII, as will the _CalDAV Scheduling Use Cases and Requirements_ document. + +*TC-AUTHENTICATE* has been shutdown. Currently work is ongoing in the IETF to specify +new HTTP authentication protocols that can be utilized by CalDAV as well as other HTTP +applications. As a result the Consortium's technical committee chairs felt that TC-AUTHENTICATE +was unnecessary right now, as there was no specific input from the Consortium +that was needed. + +*TC-CALDAV* continues to work on requirements for CalDAV Scheduling as input to the +development of the scheduling draft for CalDAV, and will be focusing after this Roundtable on the +areas of availability, scheduled event updates, and external attachments. + +*TC-EVENTPUB* has developed use cases and requirements for the `VVENUE` iCalendar +extension, which will be submitted to the IETF shortly after Roundtable VII as an individual +submission by its authors, and will focus on event sharing and event server synchronization after +this Roundtable. + +*TC-FREEBUSY* conducted the proof of concept Federated Free/Busy Demo in July and reprised +it with additional participants, and will look at ways to extend the Freebusy aggregator and +enhance the Free/Busy tool as a basis for further development. + +*TC-IOPTEST* conducted the IOP test event and is starting to consider the development of mobile +calendaring tests in conjunction with TC MOBILE. + +*TC-MOBILE* discussed three major areas _The Benefits of iCalendar for the mobile industry_, a +white paper under development; recurrence simplification for mobile devices as input to the IETF +CALSIFY effort; and the development of a mobile calendaring IOP test suite and IOP test events +for mobile devices; work on all of these will proceed after the Roundtable. The session was +attended by a delegation of ten people from the OMA Data Sync working group, with which +CalConnect has a liaison. + +*TC-REALTIME* is focusing on three major discussion areas: addressing, discovery, and +authentication/authorization/access control, and will continue work in those areas after the +Roundtable. + +*TC-USECASE* has completed the Calendaring Glossary document which will be published +shortly after the Roundtable, has begun work on the minimum interoperable subset for tasks +(``VTODO``s), and will undertake a study of recurrence features in mobile device support for TC +MOBILE. + +*vCard Ad Hoc Group*: One of the OMA/DS delegates presented a paper on vCard and on contact +information in genera as part of a discussion on whether or not the Consortium should undertake +any action in this area. + +*CalConnect Interoperability Test Event*: Participants in the IOP test event included Apple +Computer, Eventful (formerly EVDB), Mozilla, OSAF and RPI (Rensselaer Polytechnic Institute). +Results from the event will be posted at Past IOP Reports shortly. + +*NEW INITIATIVES*: The Consortium is studying the possibility of undertaking work in several +new areas, in particular vCard/contact information, resources, and a general assessment of +Calendaring tools and specifications such as CalDAV/RSS-SSE/microformats and so forth. +Possible work will be undertaken depending on whether or not the Consortium has resources +interested in the work, and the development of charters and proposed work products appropriate +for the Consortium. + +== Future Meetings + +The next meeting (Roundtable VIII) will take place January 29 through February 2 in Provo, Utah, +hosted by Novell. Due to the increasing size of the IOP test event, the format of the January +meeting will be changed to span the week. The IOP test event will run from noon Monday (Jan +29) through noon Wednesday (Jan 31). The Roundtable will run from noon Wednesday (Jan 31) +through noon Friday (Feb 2). + +Roundtable IX will take place the week of May 7-11, location TBD. diff --git a/sources/cc-0701-miniop-usecases-tasks/document.adoc b/sources/cc-0701-miniop-usecases-tasks/document.adoc new file mode 100644 index 0000000..8fcf92a --- /dev/null +++ b/sources/cc-0701-miniop-usecases-tasks/document.adoc @@ -0,0 +1,466 @@ += Min-IOP (Minimum Interoperable Subset) Use Cases for Tasks (VTODO) +:docnumber: 0701 +:copyright-year: 2007 +:language: en +:doctype: specification +:edition: 1 +:status: published +:revdate: 2007-04-19 +:published-date: 2007-04-19 +:technical-committee: USECASE +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Jeff McCullouch +:affiliation: UC Berkeley +:role: editor +:fullname: Guy Stalnaker +:affiliation: University of Wisconsin +:role: editor +:fullname: Mimi Mugler +:affiliation: UC Berkeley +:role: editor + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +This document was created by the Use Case Technical +Committee of the Calendaring and Scheduling Consortium and +defines the use cases for minimum interoperablity for tasks +support (VTODO) for calendaring and scheduling. Minimum +interoperability is the basic level of functionality our collective +experience tells us is necessary to have a useful system. We +realize that in some cases it may be more than is currently +offered by "basic" calendaring and scheduling applications. + +== Introduction + +This document was created by the USECASE Technical Committee of the Calendaring and +Scheduling Consortium. The document defines the use cases for minimum interoperability of +tasks within the calendaring and scheduling application domain. Minimum interoperability is the +basic level of functionality our collective experience tells us is necessary to have a useful +system. We realize that in some cases it may be more than is currently offered by "basic" +calendaring and scheduling applications. + +A word about the use of 'task' versus 'todo'. In discussion it was determined that while RFC +2445 uses only 'todo' and RFC 3283 uses task (once), and in fact RFC 2445 defines the +`VTODO` component of an iCalendar object, common usage by vendors and users turns more to +the term 'task' than 'todo' (cp. for example the entry in Wikipedia, in which the entry for todo +refers to the entry for Time Management, which uses the term 'task'). This document defers to +that common usage in the interest of clarity and, hopefully, usability. + +[.preface] +== Methodology + +The set of properties determined to be the minimum set for interoperability was chosen via +discussion at CalConnect's Roundtables VI and VII and in conference calls of the USECASE +Technical Committee. Additional contributions were provided in an informal survey of properties +that are built into existing software products that have Task management features, which +formed a starting point for further winnowing of properties. The software products were not +selected by any formal process, but were those available to which committee participants had +access. However, we believe these to be a fair representation of the types of calendaring +products currently in use. Eventually the USECASE Technical Committee decided that it was +advisable to proceed by accepting those properties which were implemented by more than fifty +percent (>50%) of the software surveyed as representing a minimum set for interoperability. + +The software applications are: + +* Palm OS +* Oracle Calendar +* Yahoo +* Evolution +* KDE Kontact +* Mozilla Sunbird +* Apple iCal +* Microsoft Entourage +* Microsoft Outlook +* Lotus Notes + +[heading=terms and definitions] +== Definitions + +The definitions below are taken from the "Calendaring and Scheduling Glossary of Terms," +version 1.0, October, 2006, from CalConnect. In accordance with previous comments, the term +'task' has replaced 'todo' whereever 'todo' was found. + +=== Alarm + +A reminder for an event or a task. Alarms may be used to define a reminder for a +pending event or an overdue task. + +=== Calendar + +A collection of events, tasks, 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. + +[.source] +<> + +=== Calendar User (CU) + +An entity (often a human) that accesses calendar information. + +[.source] +<> + +=== Calendaring + +An application domain that covers systems that allow the interchange, access +and management of calendar data. + +=== CalConnect + +The Calendaring and Scheduling Consortium consisting of vendors and user +groups interested in promoting and improving calendaring and scheduling standards and +interoperability. + +=== Component + +A piece of calendar data such as an event, a task, or an alarm. Information about +components is stored as properties of those components. + +[.source] +<> + +=== Coordinated Universal Time (UTC) + +An atomic realization of Universal Time (UT) or Greenwich +Mean Time, the astronomical basis for civil time. Time zones around the world are expressed as +positive and negative offsets from UT. UTC differs by an integral number of seconds from +International Atomic Time (TAI), as measured by atomic clocks and a fractional number of +seconds from UT. + +[.source] +<> + +=== Counter + +A counter-proposal request a participant may send to an event or task organizer to +suggest a change to the event or task such as the scheduled date/time, list of participants, etc. + +=== Daylight Saving Time (DST) + +The period of the year in which the local time of a particular time +zone is adjusted forward, most commonly by one hour, to account for the additional hours of +daylight during summer months. + +=== Event + +A calendar object that usually takes up time on an individual calendar. Events are +commonly used to represent meetings, appointments, anniversaries, and day events. + +=== Free time search + +(Bounded) Common free time. This is typically a search generated by an +application to show time on a calendar that is available or open. + +=== Freebusy + +A database and/or listing of times when a potential attendee or resource is free or +busy. Used when scheduling calendar events. + +=== iCalendar + +The Internet Calendaring and Scheduling Core Object Specification. An IETF +standard (RFC 2445) for a text representation of calendar data (`VEVENT`, `VTODO`, `VALARM`, +etc.). + +=== Instance + +When used with recurrences, an instance refers to an item in the set of recurring +items. + +=== Invite + +To request the attendance of someone to a calendar event. + +=== Negotiation + +Resource conflict resolution. Negotiation is the process of resolving conflicts either +programmatically or via direct communication with the participants and invitees of meetings and +events. + +=== Notification + +. The action of making known, an intimation, a notice. +. Reminder or alarm sent +when any resource or parties interested in the resource need an indicator that some attention is +required. Possible notification methods include email, paging, audible signal at the computer, +visual indicator at the computer, voice mail, telephone. + +=== Organizer + +The originator of a calendar event typically involving more than one attendee. + +=== Property + +A description of some element of an component, such as a start time, title, or +location. Properties can have parameters associated with them to modify or add to their +meaning. + +=== Publish + +Make known publicly calendar information such as `freebusy` times. + +=== Recurring + +Happening more than once over a specified interval, such as weekly, monthly, daily, +etc. See {{Repeating}}. + +=== Repeating + +An event that happens more than once. You might want an event to occur on a +regular basis. To do this you schedule a repeating event. Any changes you make to the event +can automatically be made to all occurrences of the event. If necessary, changes can be made +to individual events without affecting the others. For example, if you need to attend a weekly +meeting, you can schedule a repeating event on your calendar. Using another example, if you +want to schedule a five day vacation, schedule an all-day event that repeats daily for a total of +five times. If you have to cancel one of the days, delete the one day without deleting the whole +event. + +=== Reminders + +See {{Notification}}. + +=== Task + +A calendar object that is commonly used to represent work items. + +=== Text/calendar + +The MIME content type for encoding iCalendar objects. Example usage +includes: email, web pages. + +=== Time zone + +Areas of the Earth that have adopted the same local time. Time zones are +generally centered on meridians of a longitude, that is a multiple of stem:[15 "unitsml(deg)"], thus making +neighboring time zones one hour apart. However, the one hour separation is not universal and +the shapes of time zones can be quite irregular because they usually follow the boundaries of +states, countries or other administrative areas. Time zones are calendar components that define +the time of an event relative to UTC (see below). + +=== To-do + +See {{Task}}. + +== Properties Used + +We're using the following properties of a Task in this draft (iCalendar `VTODO` specification +property name is in square brackets []): + +. Title [`SUMMARY`] +. Priority [`PRIORITY`: iCalendar supports values 1-9] +. Due/End Date [`DTEND`] +. Access/Privacy [`CLASS`] +. Notes/Details/Desc [`DESCRIPTION`] +. Category [`CATEGORIES`] +. Start Date [`DTSTART`] +. Percent Completed [`COMPLETED`: iCalendar support values 0-100%] +. Alarm/Reminder [`VALARM`] + +In the examples below, the Task property (as listed above) are indicated in square brackets []: + +. Explanatory text [property numbers]: + +[example] +==== +. A calendar user wants to create a task that must be done by a particular date (but could be +done sooner) [1,3]: +==== + +== Use Cases + +=== General Tasks + +==== Task can be done any time [1] + +[example] +File reports. + +[example] +Clean desk off. + +==== Task requires more description [1,5] + +[example] +Pick up roast from Jacobsens [`DESC` - Brennans not the Jacobsens on Raymond +Road]. + +[example] +Pick up mail from post office box [`DESC` - combination is AB - F - IJ]. + +==== Task indicates that it was completed, (percentage 0-100%), NOTE: this is not a date string) [1,8] + +[example] +Buy sister flowers for birthday [100%]. + +=== Tasks have Due/End or Start Dates + +==== Task must be done by a particular date (but perhaps could be done sooner) [1,3] + +[example] +File income taxes by April 15. + +[example] +Deliver project scope to customer by March 1. + +[example] +Give dog heartworm medicine on the 9th of the month. + +[example] +Certificate for web server expires on the October 20, get new one to install by that +date. + +==== Task cannot begin before a prior task concludes [1,2,3,7] + +[example] +==== +Task 1 - Rewrite course schedule import code due to DST changes by January 22nd when +classes start - priority 1. + +Task 2 - Begin work on event data update on January 23rd after course schedule rewrite is +done. +==== + +[example] +==== +Task 1 - Install Solaris patch updates on test machines by September 15th. + +Task 2 - After Solaris patched, patch Oracle OCAS system (which requires the Solaris patches), +begin September 16th. +==== + +=== Tasks have limited/private or public/group access + +==== Task that can only be viewed by creator [1,3,4] + +[example] +Take son to physical therapist for bum knee (private/personal). + +[example] +Buy train ticket for trip to Portland (personal/private). + +[example] +Vacation -- Out of Town (Public) + +==== Task that can be viewed by a selected group of others [1,4] + +[example] +Get figures together on revenue for 1st quarter for audit (Group). + +[example] +Practice 1st 32 bars of dance program (Group). + +=== Prioritized Tasks + +==== Task is more important than other tasks [1,2,3] + +[example] +Prepare performance review documents for manager before March 1st - priority 1. + +[example] +Research resource usage for CalConnect presentation before January 31st - priority +2. + +=== Task categorization + +==== Task categories indicate that multiple tasks are grouped, narrowly defined + +[example] +==== +All tasks have category of 'Set up web application' [1,6]: + +Task 1 - Install apache 2 on test host ithilien. + +Task 2 - Install php5 on test host ithilien. + +Task 3 - Install perl5 on test host ithilien. + +Task 4 - Install tomcat on test host ithilien. + +Task 5 - Install ant on test host ithilien. + +Task 6 - Install latest Java5 SDK on test host ithilien. + +Task 7 - Install Oracle Java/SDK on test host ithilien. + +Task 8 - Configure cvs. + +Task 9 - Checkout web app code from cvs. + +Task 10 - Use ant and deploy code. + +Task 11 - Confirm application is functioning correctly. +==== + +[example] +==== +All tasks have category of 'Party Preparation': + +Task 1 - Hire house cleaner for day before party. + +Task 2 - Order flowers one week before party. + +Task 3 - Order appetizers from deli one week before party. + +Task 4 - Contact caterers about dinner options and make decision. + +Task 5 - Send out invitations. + +Task 6 - Contact rental store about chairs and tables. + +Task 7 - Arrange babysitting for pets and kids (grandparents). +==== + +==== Task categories of a more general nature (broadly defined) + +[example] +==== +Personal/Family tasks are differentiated by category from work-related tasks. + +Task 1 - Personal: Make appt. with counselor + +Task 2 - Work: Make sales calls. +==== + +[example] +==== +Tasks belong to long-term or permanent categories related to job areas (e.g., +Calendaring, system administration, consulting) + +Task 1 - Calendaring: Attend calendaring conference + +Task 2 - System administration: patch OS + +Task 3 - Consulting: respond to client's question +==== + +=== Tasks use alarms + +NOTE: Alarms are tied to the Due/End Date/Start Date attributes as one would expect. + +[example] +Take the garbage to the curb on Mondays, start time of 8am, with alarm (`VALARM`: +Audio prompt, with a trigger of one hour before the start time) [1,3,7,9]. + +[example] +Give dog heartworm medicine on the 9th of the month, with alarm (`VALARM`: Email +prompt, with a trigger of one day before due date) [1,3,7,9]. + +[bibliography] +== References + +* [[[rfc2445,IETF RFC 2445]]] + +* [[[rfc3283,IETF RFC 3283]]] + +* [[[cc-glossary, CC/R 0610]]] + +* [[[wiki,Wikipedia]]], https://www.wikipedia.org/ diff --git a/sources/cc-0702-report-ioptest/document.adoc b/sources/cc-0702-report-ioptest/document.adoc new file mode 100644 index 0000000..c93f3a0 --- /dev/null +++ b/sources/cc-0702-report-ioptest/document.adoc @@ -0,0 +1,314 @@ += January 2007 CalConnect Interoperability Test Report +:docnumber: 0702 +:copyright-year: 2007 +:language: en +:doctype: administrative +:edition: 2 +:status: published +:revdate: 2007-04-24 +:published-date: 2007-04-24 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Patricia Egen +:role: author +:fullname_2: Tony Becker +:role_2: author +:fullname_3: Cyrus Daboo +:role_3: author +:fullname_4: Mike Douglass +:role_4: author +:fullname_5: Tomas Hnetila +:role_5: author +:fullname_6: Dave Nutall +:role_6: author +:fullname_7: Simon Vaillancourt +:role_7: author + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Introduction + +This document contains notes and results from the January 2007 calendar interoperability event held at +the Novell complex in Provo, Utah. The basic purpose of the event was to test CALDAV Free Busy and +Scheduling and iCalendar iMIP and iTIP events. + +The chart below shows the attendees, their organization and the products they were testing. + +=== Attendees + +[%unnumbered,options=header] +|=== +| Attendees | Organization | Products +| Chuck Norris | EVDB | Eventful server +| Mikael Rogers | OSAF | Chandler client +| Mike Douglass | RPI | Bedework server +| Cyrus Daboo | Apple | Apple server and client +| Wilfredo Sanchez | Apple | Apple server +| Simon Vaillancourt | Oracle | Oracle CALDAV +| Tomas Hnetila | Kerio | CALDAV server, iCalendar +| Stepan Potys | Kerio | CALDAV server, iCalendar +| Tony Becker | Marware | Project X CALDAV client, iCalendar +| Dave Nutall | Novell | Groupwise +| Rand Babcock | Novell | Groupwise, CALDAV server +|=== + +== General Comments + +=== What was tested + +The following applications and products were tested: + +* Four CALDAV servers - RPI, Oracle, Apple, and OSAF +* Four CALDAV clients -- OSAF, Kerio, Marware and Apple +* iCalendar interoperability -- Kerio, Novell, Oracle, Eventful and Marware + +=== CALDAV Testing Matrix + +The following chart shows the specific items validated during CALDAV testing: + +[%unnumbered] +|=== +h| 1. h| Event creation. +| 1.1. | Create new single-instance meeting titled "Meeting 1.1" with the location "Durham". +| 1.2. | Create new meeting titled "Meeting 1.2" recurring every Monday from 10:00 AM to 11:00 AM for 4 weeks. +| 1.3. | Create new single-instance meeting titled "Meeting 1.3" with 2 other attendees. +| 1.4. | Create new single-instance meeting titled "Meeting 1.4" with an alarm set to trigger 15 minutes prior to the schedule time of the meeting. +h| 2. h| Event modification +| 2.1. | Modify the title of meeting "Meeting 1.1" to "Meeting 1.1bis". +| 2.2. | Modify the location of the meeting "Meeting 1.1bis" to "Seattle bis". +| 2.3. | Reschedule meeting "Meeting 1.1bis" to the next day. +| 2.4. | Add an attendee to "Meeting 1.1bis". +| 2.5. | Add an alarm to "Meeting 1.1bis". +| 2.6. | Modify the title of the 1st instance of the recurring meeting created in 1.2. +| 2.7. | Modify the participation status of the 1st attendee in meeting 1.3 to `DECLINED`. +| 2.8. | Cancel the 4th instance of the recurring meeting created in 1.2. +| 2.9. | One client changes "Meeting 1.1bis" to a different time, second client 'refreshes' its display to see the modification. +h| 3. h| Event retrieval +| 3.1. | calendar-query `REPORT` +| 3.1.1. | No filtering (match everything) +| 3.1.1.1. | Query all components and return all data. (tests `` and ``) +| 3.1.1.2. | Query all components and return ETag WebDAV property and all data. (tests `+` and ``) +| 3.1.1.3. | Query all components and return just entire `VEVENT` components. (tests ``, `+`) +| 3.1.1.4. | Query all components and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `+`, `++`) +| 3.1.2. | time-range filtering +| 3.1.2.1. | Query all components within a one day time-range and return all data. Make sure that there is a recurring event that starts prior to the chosen time-range but has one non-overridden instance within the time-range. (tests ``, `+`) +| 3.1.2.2. | Query all components within a one week time-range and return just entire `VEVENT` components. Make sure that there is a recurring event that starts prior to the chosen time-range but has one overridden instance within the time-range. (tests ``, `+`) +| 3.1.3. | component based filtering +| 3.1.3.1. | Query all components that contain an embedded `VALARM` component. (tests ``, `+`) +| 3.1.3.2. | Query all components that contain an embedded `VALARM` component whose trigger falls within a specific time-range. (tests ``, `+++`) +| 3.1.4. | property based filtering +| 3.1.4.1. | Query all components that contain any `ORGANIZER` property. (tests ``, `++`) +| 3.1.4.2. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-insensitively. (tests ``, `+++`) +| 3.1.4.3. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-sensitively. (tests ``, `+++`) +| 3.1.5. | parameter based filtering +| 3.1.5.1. | Query all components that contain a `DTSTART` property with a `TZID` parameter. (tests ``, `++++`) +| 3.1.5.2. | Query all components that contain an `ATTENDEE` property with `PARTSTAT=NEEDS-ACTION` parameter. (tests ``, `++++`) +| 3.2. | calendar-multiget `REPORT` +| 3.2.1. | Query a specific href and return all data. (tests ``) +| 3.2.2. | Query multiple hrefs (some of which do not exist) and return all data. (tests ``) +| 3.2.3. | Query a specific href and return ETag WebDAV property and all data. (tests `+`) +| 3.2.4. | Query multiple hrefs (some of which do not exist) and return ETag WebDAV property and all data. (tests `+`) +| 3.2.5. | Query a specific href and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) +| 3.2.6. | Query multiple hrefs (some of which do not exist) and return `VEVENT` components with only `DTSTART`, `DTEND`/`DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) +h| 4. h| Event deletion +| 4.1. | Delete a single non-recurring meeting. +| 4.2. | Delete a single recurring meeting with no overridden instances. +| 4.3. | Delete a single recurring meeting with overridden instances. +| 4.4. | Delete a non-overridden instance of a recurring meeting. +| 4.5. | Delete an overridden instance of a recurring meeting. +h| 5. h| Access Control +| 5.1. | View access control details on current user's main calendar. +| 5.2. | Change access control details on current user's main calendar to add another user with read-only access. Verify that other user can view the calendar but not change it. +| 5.3. | Change access control details on current user's main calendar to add another user with read-write access. Verify that other user can view the calendar and change it. Verify that changes done by one user are seen by the other. +| 5.4. | Remove another user's access to the current user's main calendar and verify they can no longer access the calendar. +h| 6 h| Calendar Management +| 6.1 | Browse the list of calendars on the server, including the current user's personal calendars. +| 6.2 | Create a new calendar in the current user's personal calendar space. +| 6.3 | Create a regular collection in the current user's personal calendar space. +| 6.4 | Create a new calendar inside the collection created in 6.3. +| 6.5 | Delete the calendar created in 6.2. +| 6.6 | Delete the collection created in 6.3. +h| 7 h| Free Busy Reports +| Setup a| Create a new calendar and populate it with the following for one week: + +Event on Monday, 9 am - 11 am, recurs every day for five times + +Event on Monday, 12 pm - 1 pm, status tentative + +Event on Monday, 2 pm - 3 pm, status cancelled + +Event on Tuesday, 11 am - 12 pm + +Event on Tuesday, 2 pm - 4 pm, recurs every day for four times + +Event on Tuesday, 3 pm - 5 pm + +Event on Wednesday, 11 am - 12 pm, status tentative + +Event on Wednesday, 3 pm - 5 pm, status tentative + +Event on Thursday, 11 am - 12 pm, status cancelled + +Event on Thursday, 3 pm - 5 pm, status cancelled +| 7.1 | Run a free-busy report for the entire week. +| 7.1.1 | Verify two `FREEBUSY` periods for Monday, the second is `BUSY-TENTATIVE`. +| 7.1.2 | Verify two `FREEBUSY` periods for Tuesday. +| 7.1.3 | Verify four `FREEBUSY` periods for Wednesday, second and fourth are `BUSY-TENTATIVE` and one hour long. +| 7.1.4 | Verify two `FREEBUSY` periods for Thursday. +| 7.1.5 | Verify two `FREEBUSY` periods for Friday. +h| 8 h| Scheduling +| Setup | Three user accounts user1 (role Organizer), user2 (role Attendee), user3 (role Attendee) provisioned with suitable principal properties for calendar home, inbox, outbox and user addresses. +| 8.1 | Organizer (user1) sends non-recurring message invite for Monday at 9am (1 hour) to each attendee. Verify that each attendee Inbox receives a copy of the invite. +| 8.2 | Attendee (user2) accepts invite and sends back reply. Verify that reply is placed in Organizer Inbox. +| 8.3 | Organizer (user1) updates invite with user2 accept state and resends invite. Verify that each attendee Inbox receives a copy of the new invite. +| 8.4 | Attendee (user3) accepts updated invite and sends back reply. Verify that reply is placed in Organizer Inbox. +| 8.5 | Organizer (user1) updates invite with user3 accept state and resends invite. Verify that each attendee Inbox receives a copy of the new invite. +| 8.6 | Organizer (user1) cancels the invite. Verify that each attendee Inbox receives the cancellation. +|=== + +=== iCalendar testing + +A iTIP test matrix and iCalendar test streams were validated against various products. + +The following are generic notes that describe some of the results of the interop testing. + +=== CALDAV testing + +Several servers and clients were able to test much of the CALDAV matrix. On the server front, some +minor issues were found during testing, but for the most part the servers are holding up well. Again, due +to bugs found during testing, not much of the Free Busy or Scheduling was able to be tested. + +On the client side, a number of issues with CALDAV interoperability with other servers were found with +problems occurring on all sides. Some server problems were fixed and re-tested as working. + +==== Examples of items found were + +* Calendar-query report not matching any event occurrences in some cases +* COPY to the same location should not be allowed +* HTTP Error 409 Conflict returned when overwrite HTTP header is false, should be 401 or 403 +* `VFREEBUSY` component should always contain GMT times +* Publishing only a project calendar using CALDAV. +* Not deleting events from CALDAV server during next publishing. +* Needing to publish more information about tasks in event Descriptions +* Not properly handling all-day meeting invitation generated by another vendor's product. +* Using incorrect `Content-Class:urn:content-classes:calendar-message` instead of `Content-Class:urn:content-classes:task` when sending tasks. +* client expecting an ETag on collections +* One vendor adds an Organizer to the events they created. +* bugs were associated with setting of calendar properties. +* problems with user principals +* products sending many simultaneous requests. + +==== Example of things tested + +* Ability to connect and publish ``VEVENT``'s and ``VTODO``'s to a CALDAV server +* Adding a configuration pane to the Application to support changing server connections. +* Summaries and descriptions to each task. +* Subprojects as all day events. +* `TODO` support and MKCalendar support +* absorb and completely ignore a vvenue component. + +Cyrus Daboo of Apple created a test tool which was run against several servers at the event. A brief +report on results was posted and made available to other vendors. This showed that there is still much +work to do to have servers with full compliance to all details of the CALDAV spec, but progress is being +made. A number of issues were reported back to vendors. Note -- the report created by the CALDAV tool +mentioned above can be found later in this document. + +All vendors felt that the Interop Testing event was an effective way to test compatibility. Several vendors +mentioned the need for more test cases for exceptions, particularly with recurring events with multiple +exceptions. + +=== iCalendar Testing + +Examples of things found during iCalendar testing + +* Task interoperability issues that stem from a simple IMIP component tag missing. +* Not handling `TENTATIVE` status and broken Cancel. +* All day appointment expectations where there is no time (unlike Microsoft). +* And of course, the odds and ends little bugs that are always found. +* A lot is working today with most of the attendees. + +=== Summary + +As usual there were several bugs found during testing. Quite a bit more of CALDAV was able to be +tested this event and several iCalendar iMIP and iTIP objects were passed among the vendors for testing. +The CALDAV testing matrix is the same one used in the September 2006 testing. At that time, not +everyone was supporting scheduling. We continue to test as much as we can on the new scheduling +sections. + +As suggested by several participants, we will be looking at some virtual interop testing between onsite +events. The virtual interops are not meant to take the place of on-site testing. Too much value is deriving +from the one-on-one, in person interactions. However, continued testing between events will help find +discrepancies that can be resolved prior to the next onsite event. + +Respectfully submitted, Pat Egen. Interoperability Event Manager + +NOTE: The CALDAV Tester Tool Report follows. + +== CALDAV Tester Results -- tool created by Cyrus Daboo of Apple + +The following chart shows the results of the CALDAVTester tool run by Cyrus at the Interop event. The +products tested and their results are shown in the following chart: + +[%unnumbered,cols="a,a,a,a,a",options=header] +|=== +| CALDAVTester Test Script | Vendor1 | Vendor2 | Vendor3 | Vendor4 + +| `acl` | Not supported by server | Does not support prevent ACLs. | `VTODO PUT` fails; | Not supported by server. + +| `acldisabled` | Not supported by server | Not supported by server. | Not supported by server. | Not supported by server. + +| `aclreports` | Not supported by server | Not supported by server. | Gave back 400 response in some cases where a 403 or multi-status should have been returned; supported-report-set does not list all ACL reports; | Not supported by server. + +| `attachments` | Failed all - server reports error with last line of `ATTACHMENT` property | Passed all. | `ATTACHMENT` property not returned after being `PUT` | + +| `availability` | Not supported by server | Not supported by server. | Not supported by server. | Not supported by server. + +| `CALDAVIOP` | Pased all | Passed all. | | Passed all. + +| `calendaruserproxy` | Not supported by server | Not supported by server. | Not supported by server. | Not supported by server. + +| `copymove` | `COPY`/`MOVE` not supported by server | Failed: allowed copy of event back to same calendar; return 409 instead of 412 for Overwrite:F | `MKCALENDAR` fails during start up | 500 errors for nearly all. + +| `delete` | Passed all. | Passed all. | `VTODO PUT` failed, `VEVENT` OK. | Failed during startup: Cannot put `VTODO`. + +| `depthreports` | | Whole bunch of multiget problems; no results coming back for `calendar-query`; `fb` property value periods not in iCalendar format -0500 offset in period values | Failed during startup: could not create calendar within new regular collection. | Failed during startup: cannot put `VFREEBUSY` (looks like same error as `VTODO`). + +| `depthreportsacl` | Not supported by server | Not supported by server. | Not supported by server. | Not supported by server. + +| `dropbox` | Not supported by server | Not supported by server. | Not supported by server. | Not supported by server. + +| `encodedURIs` | `MKCALENDAR` with calendar%202 fails with 400 | Location header was present in a `PUT` response. | Creates a calendar instead of a collection. | ``COPY``s fail. + +| `errors` | | Won't allow resource in calendar home. | Failed during startup: initial `PUT` fails. | No ``DAV:error``'s returned. + +| `floating` | `MKCALENDAR` failed in startup | All fail. | Failed during startup: cannot create subcalendar. | Failure that causes calendar to no longer open or be deleted. + +| `get` | Duplicate `DTSTAMP` in `VEVENT` response; could not write resource in calendar home | Failed but that was due to normal server restrictions. | 500 for store of .ics in calendar home; does directory listing rather than returning whole calendar | Failures - but OK due to some event rewriting and directory listing. + +| `mkcalendar` | `MKCALENDAR` without body fails; with body does not generate proper `DAV:error` response | Bad request properties were returned as 403 response, but should have been 403 propstatus codes in a 207. | 400 when no body; no `DAV:error` for precondition failures | No ``DAV:error``'s returned. + +| `notifications` | Not supported by server | Not supported by server. | Not supported by server. | Not supported by server. + +| `propfind` | `DAV:getcontentlength` not returned on a calendar collection; did not reject invalid XML; unknown XML element generated a 500 | Passed all. | Accepted invalid XML. | Invalid XML accepted. + +| `proppatch` | Does not recognise non-standard DAV elements. | Unknown `DAV:` properties were ignored. | Got a `<#test>` XML element in output, plus other failures. | 500 errors; `xml:lang` on property is lost. + +| `proxyauthz` | Not supported by server | Not supported by server. | Not supported by server. | Not supported by server. + +| `put` | ``VTODO``'s failed - duplicate `DTSTAMP` | Some failures - probably due to server re-writing data content. | ``VTODO``s fail; unbounded daily events hang the server | 500 errors for ``VTODO``s. + +| `quota` | Not supported by server | Not supported by server. | Not supported by server. | Not supported by server. + +| `recurrenceput` | `java.lang.NullPointerException` on some recurring ``VTODO``s; ``VEVENT``s were OK | Passed all. | ``VTODO``s all fail; ``VEVENT``s OK. | ``VTODO``s all fail; ``VEVENT``s OK. + +| `reports` | Failed during startup whilst trying to put an alarm | Various failures as per `depthreports`. | | Failed during startup: cannot put `VFREEBUSY` (looks like same error as `VTODO`). + +| `schedulepost` | | Not supported by server. | Not supported by server. | Not supported by server. + +| `schedulepostacl` | Not supported by server | Not supported by server. | Not supported by server. | Not supported by server. + +| `schedulepostauto` | Not supported by server | Not supported by server. | Not supported by server. | Not supported by server. + +| `schedulepostnormal` | | Not supported by server. | Not supported by server. | Not supported by server. + +| `scheduleprops` | Passed - but actually wrong: returned ``href``s had "null" for user name | Not supported by server. | Not supported by server. | Not supported by server. +|=== diff --git a/sources/cc-0703-caldav-scheduling-reqs/document.adoc b/sources/cc-0703-caldav-scheduling-reqs/document.adoc new file mode 100644 index 0000000..8c32457 --- /dev/null +++ b/sources/cc-0703-caldav-scheduling-reqs/document.adoc @@ -0,0 +1,753 @@ += CalDav Scheduling Requirements +:docnumber: 0703 +:copyright-year: 2007 +:language: en +:doctype: standard +:edition: 1.1 +:status: published +:revdate: 2007-07-11 +:published-date: 2007-07-11 +:technical-committee: CALDAV +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Tony Becker +:affiliation: Marware +:role: editor +:fullname_2: Cyrus Daboo +:affiliation_2: Apple +:role_2: editor +:fullname_3: Bernard Desruisseaux +:affiliation_3: Oracle +:role_3: editor +:imagesdir: images + +.Foreword + +This document was created by the CalDAV Technical +Committee of the Calendaring and Scheduling Consortium. It +presents a list of features in the form of requirements for the +scheduling extensions to CalDAV <>, that is, the +extensions to the Web Distributed Authoring and Versioning +(WebDAV) <> protocol to specify a standard way of +exchanging and processing scheduling messages based on the +iCalendar Transport-Independent Interoperability Protocol +(iTIP) <>. + +== Introduction + +This document presents a list of features in the form of requirements for +the scheduling extensions to CalDAV <>, that is, the extensions to +the Web Distributed Authoring and Versioning (WebDAV) <> +protocol to specify a standard way of exchanging and processing +scheduling messages based on the iCalendar Transport-Independent +Interoperability Protocol (iTIP) <>. + +== Terminology + +This document makes use of the following terms: + +=== Free Busy request + +A `VFREEBUSY` object included in an HTTP +`POST` request, targeting one or more calendar users for their +Free/Busy information, given a time range. + +=== Scheduling message + +An iCalendar object that represents one of +the following: + +* an event publication, such as a meeting or class +* an event invitation, to a meeting +* an event modification, such as a meeting time change +* an event cancellation +* a to-do assignment, such as a task to perform or deadline to +meet +* a to-do modification, such as a deadline update +* a to-do cancellation +* a journal publication, such as a document addition to the +meeting +* a journal cancellation. +* or any other iTIP related scheduling action. + +=== Local user + +A user who's calendar (inbox) resides on the same (local) +server as the client is connected to. + +=== Remote user + +A user who's calendar (inbox) resides on a remote server, but +still within the calendar domain for addresses and principals. +This server would most likely be clustered or federated, so the +user is equivalent to a "local" user. + +=== Internal user + +Either a local or remote user. + +=== External user + +A user who's calendar (inbox) resides on a truly remote server, +outside the calendar domain. + +=== Calendar domain + +The domain in which calendar addresses and principals are +consistently defined and can be used in the protocol without +external lookups or mechanisms -- i.e.: the domain of the +Internal (local and remote) users. + +=== Authentication domain + +Rhe domain that an authentication principal identifier is valid +(server, department, corporate, etc) + +=== Authentication principal + +An identifier, returned from the authentication server, that is +used as an authentication token in the protocol requests for +authorization/permission validation(s). + +=== Calendar addresses + +Calendar user addresses are typically specified as mailto URI, +but other types of URI are allowed. + +=== Group addresses + +A collection of user addresses (internal and/or external). A +group address may itself be internal or external. Note that +there is weak definition/support for "groups" in existing Internet +standards (members and access rights) and so, we may not +be able to require/deliver the level of "group" support we would +like. + +== Scope + +The scope of this document is the state-less protocol between a CalDAV +client and server. We will address boundary protocol exchanges, where +appropriate for clarity. CalDAV server to server protocol is out of scope. + +This document assumes the following: + +* That all client to server protocol users are within a single +authentication domain, either on a single server, or part of a +calendar domain, well known and/or under local control. i.e.: +user and server "lookups" are configured correctly and will +resolve, in all cases, and that resolution to a principal +identifier, as used by the CalDAV protocol is also correctly +configured and working. By "remote" user or server, we mean +not the one that your client is connected to, but still within the +authentication domain and/or accessible by a known URI, +using the same principal identifier. Scheduling with external +users and servers, i.e.: ones outside of your authentication +domain and control, is not covered in this document. This will +be addressed by separate requirements defined by the +Realtime Technical Committee. + +[%unnumbered] +image::img01.png[width=80%] + +== Free Busy Requirements + +=== Free Busy Access + +[[cls-4.1.1]] +.Calendar user addresses must be used to identify the users for which free busy information is being requested. +[requirement] +==== +[specification] +-- +Free busy queries should be targeted at calendar users addresses, not at +specific calendars owned by those users. It should not be required to use +specific calendar names to obtain free busy information. For security +concerns, the calendar name(s) should NOT be returned in the response. +-- +==== + +[[cls-4.1.2]] +.It must be possible for a user to query the free busy information of any (internal or external) user with a single request targeted at their CalDAV server. +[requirement] +==== +[specification] +-- +A free busy query should allow a user to specify any calendar user address +(URI). The server should differentiate an error response where the +calendar user is internal but access is denied (privilege error), and where +the calendar user is external and the server doesn't know how to get that +user's calendar (unknown user error) -- so that the client may try +alternative methods to get the external user's calendar if it is able. The +protocol should support error codes for the following cases: + +* For unknown external users for which access to free busy +information is not available -> User unknown error +* For unknown internal users for which free busy information is not +available -> User Not Found error +* For users for which access to free busy information is not granted +to the requester -> Privilege error +-- +==== + +[[cls-4.1.3]] +.It must be possible for a user to query the free busy information of one or more users with a single request targeted at their CalDAV server. +[requirement] +==== +[specification] +-- +A user should be able to get the free busy information of multiple users in +a single request to the server. +-- +==== + +[[cls-4.1.4]] +.The response to a free busy query must contain free busy information separated per queried calendar user. +[requirement] +==== +[specification] +-- +Often times the organizer of an event is unable to schedule the event at a +time where all the attendees are free. The organizer should have access to +the individual free busy information to know which users his event will +create a conflict with (e.g., a manager may decide to double book one of +the attendees under his direct control, but may want to avoid double +booking his own manager). The server must not aggregate free-busy +information for different users, so that the client software will be able to +present the free-busy information or error status on a per-user basis. +-- +==== + +[[cls-4.1.5]] +.It must be possible to specify the calendar user address of a group in a free busy query. The group may be internal or external to the calendaring domain. Group members can be internal or external to the calendaring domain. +[requirement] +==== +[specification] +-- +This may require additional human interaction to know what an external +group is, and to be able to specify it in the request -- or an understanding +that external groups have an email address too. A separate `VFREEBUSY` +component should be returned per group member. The protocol should +support group names as an element for the request AND error codes for +the following cases: + +* members for which free busy information is not available -> User +Not Found error +* members for which access to free busy information is not granted +to the requester -> Privilege error +* groups for which the membership info is only available to group +members -> Privilege error + +The protocol should support group names as an element for the request but +suppress some error codes for privacy, to insure clients can't infer group +members. See <> for more response information. +-- +==== + +.It must be possible for a user to specify that only free busy periods that overlap a specified time range should be returned in a response to a free busy query. +[requirement] +==== +[specification] +-- +Typically, users are only interested in the free busy information of other +users for a limited period of time (e.g., this week only). +-- +==== + +[[cls-4.1.7]] +.It must be possible for a user to perform a free busy query on behalf of another user. +[requirement] +==== +[specification] +-- +The administrative assistant of a manager must be able to query the free +busy information of users that have granted the manager the right to query +their free busy information. See <> +-- +==== + +.The response to a free busy query must be returned synchronously to the client with the free busy information of the calendar users for which information was available. +[requirement] +==== +[specification] +-- +Users want to get an immediate response to a free busy query to be able to +schedule an event immediately with the same people whose free busy +information was queried. Note: Given that the response to a free busy +query must be synchronous, there is no purpose in keeping a copy of a free +busy query on the CalDAV server. +-- +==== + +.The client should be able to specify a time-out value and the server should honor this value in any fan-outs to other servers. +[requirement] +==== +[specification] +-- +Timeouts must be considered for the following cases: + +* Network errors/timeouts client to server. +* Client to server timeout due to server busy (possible partial +response). +* Client to server timeout due to server to server fanout, with fanout +timeout (possible partial response) +-- +==== + +.For each calendar user for which free busy information was requested, a specific request status code must be returned (good and/or bad). +[requirement] +==== +[specification] +-- +Different status codes could be used for the following conditions: (1) the +information was correctly returned, (2) the calendar user address is +invalid, (3) the calendar user address doesn't exist, (4) free busy +information is not available synchronously for this calendar user - timeout, +or (5) permission has been denied to access the free busy information of +this calendar user, etc. iTIP status codes should be used. +-- +==== + +=== Free Busy Management + +.It must be possible for a user to specify which calendars impact their free busy information. This calendar set can contain calendars that are owned or not owned by the user, and they could be internal or external to their Calendaring domain. +[requirement] +==== +[specification] +-- +A user may own calendars that don't impact their availability and their +availability may be impacted by calendars that they do not own. As such, a +user should be able to specify any calendar on any server(s) which may +impact their availability. +-- +==== + +.It must be possible for a user to locate and maintain the resource that specifies which calendar collections contribute to the free busy information of a specific user given their calendar user address. +[requirement] +==== +[specification] +-- +Most users only need to locate the resource that specifies the calendar +collections that contributes to their own free busy information, but +administrative assistants may need to locate/edit/manage the resource that +specifies the calendar collections that contributes to the free busy +information of their managers. The protocol should support granting +permissions to and allowing others to manage these resources on behalf of +oneself. +-- +==== + +== Free Busy Access Control + +These may be "system" or "solution" requirements, and not necessarily +"protocol" requirements. Authentication is handled at the HTTP level and is +outside the scope of the protocol. The protocol deals with an authorization +"principal" which is then compared to various properties to determine +privileges. The client will have to present the user with various options to +support this, as described below. + +.It must be possible for a user to specify who is granted the right to query their free busy information. +[requirement] +==== +[specification] +-- +Users should be able to specify which users are granted the right to query +their free busy information. Users that are allowed to query free busy +information will then be subject to the privilege granted to them at the +calendar object resource level (i.e., CALDAV:read-free-busy privilege). +-- +==== + +[[cls-4.3.2]] +.It must be possible for a user to specify who is granted the right to perform a free busy query on their behalf. +[requirement] +==== +[specification] +-- +A manager should be able to grant their administrative assistant the right +to query free busy information of other users on their behalf. When the +administrative assistant is performing a free busy query on behalf of the +manager, authorization verification should be done against the manager's +identity (principal). i.e.: a request delegate. The system/solution should +support property storage of grants/rights to other ACLs (as a delegate). +See <>. +-- +==== + +.It must be possible for a user to specify who is granted the right to grant other users the right to query his free busy information and/or perform a free busy query on their behalf. +[requirement] +==== +[specification] +-- +A manager may want to grant their administrative assistant the right to +manage their free busy access control. i.e.: an account management +delegate. The system/solution should support storage of grants/rights to +other ACLs (as an admin delegate). +-- +==== + +== Free Busy Requirements Left Out + +This section describes issues that were considered by the Technical Committee +as it was working on this document, but were not considered to be free busy +scheduling requirements, or they were otherwise out of scope. However, the +Technical Committee felt it was useful to include these here with an explanation +of why they were left out. + +.It must be possible to specify a sub-address in a calendar user address (e.g., mailto:john+work@acme.com) to specify a specific calendar for which free busy information is being queried. +[requirement] +==== +[specification] +-- +This requirement has been left out since it is already addressed by the +`CALDAV:free-busy-query` report defined in CalDAV calendar-access. +-- +==== + +.It must be possible for a user to restrict the number of free time periods returned in a response to a free busy query. +[requirement] +==== +[specification] +-- +This requirement was left out because iTIP doesn't provide a way to +specify such a limit/restriction in a `VFREEBUSY` request. + +While a server could take advantage of this limit to reduce its load when +free busy information is requested for a single user, the same isn't true +when free busy information is requested for multiple users. +-- +==== + +.It must be possible to get a separate `VFREEBUSY` component per queried calendar user or an aggregated `VFREEBUSY` for all the queried calendar users, or both in a response to a free busy request. +[requirement] +==== +[specification] +-- +This requirement was left out because iTIP doesn't provide a way to +specify such a limit/restriction in a `VFREEBUSY` request. + +Aggregated `VFREEBUSY` could only be returned if all the individual +`VFREEBUSY` had successfully been retrieved. +-- +==== + +.It must be possible for a user to specify that only free time periods (i.e., `FBTYPE=FREE`) should be returned in a response to a free busy query. +[requirement] +==== +[specification] +-- +This requirement was left out because iTIP doesn't provide a way to +specify such a limit/restriction in a `VFREEBUSY` request. +-- +==== + +.It must be possible for a user to specify that only free time periods (i.e., `FBTYPE=FREE`) with a minimum duration should be returned in a response to a free busy query. +[requirement] +==== +[specification] +-- +This requirement was left out because iTIP doesn't provide a way to +specify such a limit/restriction in a `VFREEBUSY` request. +-- +==== + +.It must be possible for a user to specify a list of recurrence instances (i.e., `UID` and `RECURRENCE-ID`) that should be ignored during the computation of free busy information. +[requirement] +==== +[specification] +-- +This requirement was left out because iTIP doesn't provide a way to +specify such a limit/restriction in a `VFREEBUSY` request. + +In the process of rescheduling a specific recurrence instance, it would be +useful to obtain the free busy information, of the attendees, that doesn't +take into account this specific recurrence instance. +-- +==== + +.It should be possible to access free busy information easily from a simple HTTP client, i.e.: a browser. +[requirement] +==== +[specification] +-- +Testers/Users may want to publish an HTTP URL to which their free busy +information would be easily available to users with a simple HTTP +browser client (e.g., +`http://cal.example.com/freebusy/bernard.ifb`). Free busy +information retrieved this way could be restricted to a limited time range +(e.g., previous week to next two months). The protocol should not be so +complex as to prevent simple, single requests from working. i.e.: no +session state across multiple requests. + +* May require HTTP Auth - username/password, as opposed to the +"principal" +-- +==== + +== Scheduling Requirements + +=== Generic + +.Calendar user addresses must be used to identify the users to whom the scheduling messages are being sent. +[requirement] +==== +[specification] +-- +See <>. +-- +==== + +=== Organizer + +.It must be possible for an organizer to send a scheduling message to one or more users that may or may not be listed as an attendee in the scheduling message with a single request. +[requirement] +==== +[specification] +-- +The user will receive the scheduling message, but the user IS NOT listed +as an attendee. This means that the message is FYI only, and the user is not +expected to respond to the scheduling request. The recipient information must not +be exposed to any other recipient or attendee for security/privacy issues. + +If it is desired to communicate that this user was informed of the schedule +request, they may be listed as a non-required attendee in the iCalendar data, which +means everyone will know that user may have received the message. +-- +==== + +.It must be possible for an organizer to send a scheduling message to internal and external users with a single request targeted at their CalDAV server. +[requirement] +==== +[specification] +-- +The implication here is that the local CalDAV server must be the directory +lookup service and the forwarder of the request -- not the requesting client. + +* Server to server timeouts should produce service unavailable +error, will retry, like SMTP. +* Server to server security (proxy), since the organizer could be +remote. + +NOTE: server to server protocol for external users is out of scope for this +document +-- +==== + +.It must be possible for an organizer to send a scheduling message to multiple users without letting those users know about the other users that were also sent this message. The recipient list must be purged. +[requirement] +==== +[specification] +-- +The organizer of an event may want to send a copy of a meeting invitation +to the manager of one of the attendee to inform him. The organizer doesn't +necessarily want the attendee to know that a copy of the meeting invitation +was sent to his manager. This "manager" recipient is not an attendee, and +thus, cannot respond to the message. + +NOTE: Every recipient of a scheduling message will get the list of +attendees (required/not-required to attend), and thus, will know about all +the attendees. They will not know about any of the recipients. +-- +==== + +.It must be possible to specify the calendar user address of a group when sending a scheduling message. The group may be internal or external to the calendar domain. Group members can be internal or external. +[requirement] +==== +[specification] +-- +Noting that Internet group support is weak, at best, the protocol +must not prevent a group request, where all member permissions/grants +are correct, from allowing a scheduling message to be posted. The +minimum functionality of a "group" being a convenient way of +maintaining a collection of existing users must be supported. + +Group permissions/grants do not override individual member +permissions/grants. You need both to successfully receive information. + +Groups may be inclusive (all members participate) or exclusive +(only one help desk person must respond). + +See <>/<> for response status/errors. +-- +==== + +.It must be possible for the organizer to properly handle, on a per recurrence instance basis, attendee scheduling replies received out of order or received more than once (duplicate scheduling replies). +[requirement] +==== +[specification] +-- +The organizer may receive attendee replies to a scheduling request out of +order. The organizer should have a way to know whether they should +ignore a reply from an attendee given that a more recent reply was already +received from that attendee. +-- +==== + +.It must be possible for an organizer to determine, on a per recurrence instance basis, if a scheduling reply from a given attendee is making reference to the last scheduling request sent to that given attendee. +[requirement] +==== +[specification] +-- +The organizer may receive a reply, from an attendee, that makes reference +to a scheduling request that preceded the last scheduling request sent to +that attendee. +-- +==== + +=== Attendee/Recipient + +.It must be possible for an attendee to receive a scheduling message sent by an internal or external organizer. +[requirement] +==== +[specification] +-- +This is currently an issue due to the existing requirement of explicitly +granting access to each submitter. +-- +==== + +.It must be possible for the attendee to properly handle, on a per recurrence instance basis, organizer scheduling messages received out of order or received more than once (duplicate scheduling messages). +[requirement] +==== +[specification] +-- +Attendees may receive requests from an organizer out of order or multiple +times. The attendee should have a way to detect out of order or duplicate +requests and ignore them. This requires maintaining enough state +information on the server and/or client to detect any problems. +-- +==== + +.It must be possible for an attendee to send a scheduling reply in response to a scheduling message received from a internal or external organizer. +[requirement] +==== +[specification] +-- +If an attendee receives a scheduling request, they should be able to +respond to it, if a response is required. +-- +==== + +.It must be possible for an attendee to respond more than once to a scheduling message received from a internal or external organizer, with a different response (accept/decline). +[requirement] +==== +[specification] +-- +Attendees need to be allowed to "change their minds" about a reply they +have previously sent to an organizer. So they must be able to send +additional replies to the same scheduling request, each indicating a change +in status. These replies need to be appropriately tracked by the organizer +to ensure proper sequencing. +-- +==== + +.It must be possible for an attendee/recipient to know the originator of a scheduling message. +[requirement] +==== +[specification] +-- +The originator might be a different user than the organizer (e.g., a calendar +user forwarding a scheduling message, a calendar user sending a +scheduling message on behalf of the organizer). +-- +==== + +.It must be possible for an attendee to receive and respond to scheduling messages where the original organizer has been replaced by a new one. +[requirement] +==== +[specification] +-- +Security issue: We must notify the client and/or log on the server that the +organizer has changed, to insure no one is masquerading. +-- +==== + +=== Scheduling Access Control + +See the previous section for delegation requirements. + +.It must be possible for a user to specify who he will accept a schedule request from. +[requirement] +==== +[specification] +-- +Users should be able to specify which users are granted the right to +schedule their time -- i.e.: their managers and/or administrative assistant. +-- +==== + +.It must be possible for a user to specify who is granted the right to accept schedule requests on their behalf. +[requirement] +==== +[specification] +-- +A manager should be able to grant their administrative assistant the right +to submit/accept schedule requests. +-- +==== + +.It must be possible for a user to specify who he will accept schedule replies from. +[requirement] +==== +[specification] +-- +The protocol is stateless -- the original invite should/may not be +stored on the server. New attendees may have been added +and the organizer may have changed from the original +message. The user must specify who he/she will receive +schedule replies from. +-- +==== + +=== Left out requirements + +This section describes issues that were considered by the Technical Committee +as it was working on this document, but were not considered to be protocol +scheduling requirements, or they were otherwise out of scope. However, the +Technical Committee felt it was useful to include these here with an explanation +of why they were left out. + +.Ability to ask the server to strip the `ATTENDEE` and/or BCC list... +[requirement] +==== +[specification] +-- +Handled by the requirement to BCC (blind copy) a recipient. +-- +==== + +.It must be possible for an attendee to forward a scheduling message to internal or external uninvited calendar user. +[requirement] +==== +[specification] +-- +A user may wish to forward the request to their boss for permission, or +their admin/delegate to manage. Security issue: A lot of potentially +sensitive information is contained in the message. Difficult to +differentiate (Re:/FYI:/or real scheduling message) -- recommend to use +email. + +NOTE: It's not a scheduling request (client to server) so out of band, +so out of scope. +-- +==== + +.It must be possible for an attendee to "mark" on a per instance basis, whether the scheduling message has been (1) read/unread, (2) processed/unprocessed, and (3) responded (accept/decline)/non-responded (yet). +[requirement] +==== +[specification] +-- +The client application needs to be able to display these states, and the +server needs to be able to store these statuses-- via message sequencing, +etc. This requirement is out of scope for the scheduling protocol. +-- +==== + +[bibliography] +== Bibliography + +* [[[rfc2446,IETF RFC 2446]]] + +* [[[rfc2518,IETF RFC 2518]]] + +* [[[rfc4791,IETF RFC 4791]]] diff --git a/sources/cc-0703-caldav-scheduling-reqs/images/img01.png b/sources/cc-0703-caldav-scheduling-reqs/images/img01.png new file mode 100644 index 0000000..7f9553b Binary files /dev/null and b/sources/cc-0703-caldav-scheduling-reqs/images/img01.png differ diff --git a/sources/cc-0704-report-ioptest/document.adoc b/sources/cc-0704-report-ioptest/document.adoc new file mode 100644 index 0000000..977c444 --- /dev/null +++ b/sources/cc-0704-report-ioptest/document.adoc @@ -0,0 +1,102 @@ += May 2007 CalConnect Interoperability Test Report +:docnumber: 0704 +:copyright-year: 2007 +:language: en +:doctype: administrative +:edition: 1.2 +:status: published +:revdate: 2007-08-10 +:published-date: 2007-08-10 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Patricia Egen +:role: author +:fullname_2: Mike Douglass +:role_2: author +:fullname_3: Cyrus Daboo +:role_3: author +:fullname_4: Daniel Boelzle +:role_4: author +:fullname_5: Tony Becker +:role_5: author + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Introduction + +This document contains notes and results from the May 2007 calendar interoperability event, sponsored +by Boeing, held in Seattle Washington. The basic purpose of the event was to test CALDAV Free Busy +and Scheduling and iCalendar iMIP and iTIP events. + +The chart below shows the attendees, their organization and the products they were testing. + +=== Attendees + +[%unnumbered,options=header] +|=== +| Attendees | Organization | Products +| Cyrus Daboo | Apple | Apple Client and CALDAV server +| Michael Douglass | RPI | Bedework CALDAV Server +| Daniel Boelzle | Mozilla | Lightning and Thunderbird Calendar clients +| Tony Becker | Marware | Marware Calendar +| Mikeal Rogers | OSAF | Cosmo CALDAV server and Chandler Client +| Daniel Rauschenbach | Synchronica | CALDAV Server +|=== + +NOTE: Oracle was not present but provided external access to their CALDAV server for testing purposes. + +== General Comments + +The following applications and products were tested: + +* Four CALDAV servers - RPI, Oracle, Apple and OSAF (Cosmo) +* Four CALDAV clients - OSAF (Chandler), Mozilla, Marware and Apple +* iCalendar interoperability -- Mozilla and Apple + +The focus of this event was Free Busy and Scheduling testing in CALDAV. As more and more clients are +adding in the features, we are able to test more of the spec. During testing, bugs in code were found and +noted. One of the benefits of interoperability testing is to stress test implementations in a controlled +environment. Each product found situations where they need to go back and adjust their implementations +in order to improve interoperability. + +Examples of what is tested: + +* Connection to all CALDAV servers from all clients. +* Successfully publishing events +* Publishing separate calendars +* Handling of errors and authentication + +Examples of issues found are: + +* Serialization of all requests +* Handling of Mkcalendar +* Products not showing first instances +* Not handling `EXDATE=a,b,c` +* Fetching ETags on non-existing resources when adding items +* Error reporting +* Weekly recurring event 4 times - Queries "in between" weeks return no results +* Deleting recurring event with multiple overridden instances +* UI handling of switching between recurring event with count (1.2) that do not update the recurrence field +* Deleting some instances, then changing the whole event into an all-day daily recurring one failed (err +500) +* A server that seems to filter out a `VALARM` and doesn't write it. + +== Summary + +We continue to have good results testing CALDAV clients and servers. General comments again are that +it is always good to have interops in person. The ability to stress test in a controlled, "safe" environment is +a plus. + +The aim of the next interop is to test more CALDAV Scheduling features. + +Respectfully submitted, + +Pat Egen, + +Interoperability Event Manager diff --git a/sources/cc-0705-pres-overview/document.adoc b/sources/cc-0705-pres-overview/document.adoc new file mode 100644 index 0000000..771b58c --- /dev/null +++ b/sources/cc-0705-pres-overview/document.adoc @@ -0,0 +1,880 @@ += CalConnect, Calendaring Interoperability and Calendaring Standards +:docnumber: 0705 +:copyright-year: 2007 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2007-11-11 +:published-date: 2007-11-11 +:technical-committee: FREEBUSY +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Dave Thewlis +:affiliation: The Calendaring and Scheduling Consortium +:contributor-position: Executive Director +:imagesdir: images + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks +and Disclaimer of Warranty for External (Public) Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +[heading=terms and definitions] +== Definitions + +=== Calendar +A collection of events, tasks, journal entries, etc. +Examples include a person's or group's schedule, +resource availability, and event listings. + +=== Scheduling +The exchange of request/invitations and +responses between organizers and attendees of +scheduled events, tasks or journal entries. + +=== CalConnect +The Calendaring and Scheduling Consortium, +consisting of vendors and user groups interested +in promoting and improving calendaring and +scheduling [underline]#standards and interoperability#. + +== Why CalConnect was established + +=== 1995-1999 + +* 1996 Versit Consortium issued vCalendar +specification +* 199x IETF CALSCH working group started +on iCalendar specification +* 1998 iCalendar (RFC 2445), iTIP (RFC 2446) +and iMIP (RFC 2447) became a proposed +standard +* 199x Work began on draft for Calendaring +Access Protocol (CAP) +* 1998 -- 2000 Some interoperability testing + +=== 2000-2004 + +* Work on CAP -- stopped +* Interoperability testing -- stopped +* Work on iCalendar, iTIP and iMIP -- stopped +* IETF CALSCH working group -- stopped +* *The draft RFCs were not ready* +** Too ambiguous +** Too complex +** Untested +* Calendaring and Scheduling Vendors +continued to use the RFCs as they could +* Where the RFCs were inadequate vendors +were forced to develop workarounds or +unique extensions +* Work on follow-on or related specifications +was hampered by being "built on sand" +* Vendors -- and users -- became more and +more frustrated by the lack of movement in +calendaring standards and interoperability +* Interoperability between calendaring +systems was mostly still a dream +* Somewhere around 2004 things started to +move again +* Some vendors began moving towards +alternatives to the base RFCs +* Interoperability seemed less important than +progressing products +* Work was begun on CalDAV as a +prospective standard for a calendar access +protocol, recognizing that CAP was a dead +end + +=== Establishment of CalConnect + +CalConnect was founded in January of +2004 to promote interoperable +Calendaring and Scheduling. + +[quote] +The driving premise behind the Consortium is that +interoperability between calendaring programs and +systems is essential to achieving the promise and +future growth of calendaring. + +[quote] +We believe that our work towards interoperability is a +major factor driving the future of internet +calendaring, and are actively working to involve +significant players (vendors and customers) in the +calendaring arena. + +=== Why a Consortium? + +A focused environment to: + +* Re-energize Calendaring and Scheduling +* Provide a forum to discuss the direction for +standards and implementations +* Validate the existing standards +* Provide interoperability testing between +implementations and against standards +* Drive requirements for changes to existing +standards, new and complementary standards +back into IETF, other bodies +* Where necessary develop initial specifications and +submit them to SDOs for progression to standards +* Promote standards and technologies to the vendor +and user communities + +== Overview of CalConnect + +=== What is CalConnect? + +A Partnership between Calendaring & +Scheduling Vendors and Customers + +* To provide a general understanding of, promote, +and provide mechanisms so that Calendaring and +Scheduling methodologies, tools and applications +can enter the mainstream of computing + +Not a standards development organization +(SDO) + +* Develop use cases, requirements, papers, specs +* Promote development and adoption of standards +* Introduce specifications into SDOs for progression +* Influence SDOs and vendors + +=== The Vision + +[quote,"Dave Thewlis, CalConnect Executive Director"] +Our vision of the future is not only +interoperable calendaring, but ubiquitous +interoperable calendaring. Calendaring +should--and can--be as ubiquitous as +electronic mail. + +[quote,"Pamela Taylor, CalConnect Board Member"] +Being able to schedule meetings with my +work group is important. But being able to +schedule an appointment with my +hairdresser could change the world. + +=== CalConnect Members + +==== Institutional Members + +* Apple Inc. +* Boeing +* California State University, Fresno +* Carnegie Mellon +* Dartmouth +* Duke University{blank}footnote:fm[Founding member] +* Eventful{blank}footnote:fm[] +* Google +* IBM +* Kerio Technology +* MailSite Software +* Marware +* M.I.T.{blank}footnote:fm[] +* Microsoft +* Mirapoint +* Mozilla Foundation{blank}footnote:fm[] +* New York University +* Open Connector Groupware +* Oracle Corporation{blank}footnote:fm[] +* Open Source Applications Foundation{blank}footnote:fm[] +* PeopleCube{blank}footnote:fm[] +* Princeton University OIT +* Rensselaer Polytechnic Institute (RPI) +* Scalix +* Sony Ericsson +* Stanford University{blank}footnote:fm[] +* Sun Microsystems +* Symbian{blank}footnote:fm[] +* Synchronica +* Timebridge +* Trumba Corp +* University of California, Berkeley{blank}footnote:fm[] +* University of Chicago +* University of Michigan +* University of Pennsylvania +* University of Washington{blank}footnote:fm[] +* University of Wisconsin, Madison{blank}footnote:fm[] +* Yahoo!{blank}footnote:fm[] +* Zimbra + +==== Individual Members + +* Patricia R. Egen + +=== CalConnect + +What we do: + +* Promote Calendaring & Scheduling (C&S) +* Help drive the evolution of open standards for +Calendaring & Scheduling +* Conduct interoperability testing +* Develop a shared vision for C&S community + +How we do it: + +* All members have same rights & privileges +* Collegial, consensus environment +* Completed work products are published +* Non-member organizations may attend one +Roundtable as Observers +* Member may have unlimited participants +* Any member may propose new TC, provide Chair + +=== How CalConnect Works + +* All members have same rights & privileges +* Collegial, consensus environment +* Completed work products are published +* Non-member organizations may attend one +Roundtable as Observers +* Member may have as many representatives +involved as it wishes + +=== Technical Committees + +==== Membership + +* TC participants from member organizations + +==== Operations + +* Determined by TC Chair and TC membership +* TC Chair provides regular status to Steering Committee + +==== Governance + +* Any Consortium member may propose new work +* Charter, scope and deliverables identified in the proposal +* Chair confirmed by SC +* Committee terminates when chartered work is complete + +==== Operational policies + +* In-progress work confidential to Consortium members only +* Completed work published and freely available on +Consortium web site +* No proprietary information discussed + +=== TC CHAIRS + +* Management committee for TCs +** Composed of Chairs of all TCs +* Weekly conference calls +* Ongoing TC coordination on behalf of +Steering Committee +* Approves document publication following +last call process +* Chair of TC CHAIRS participates in Steering +Committee + +=== Steering Committee + +==== Membership + +* Founding Members plus first member from each +membership category + +==== Operations + +* Monthly teleconference +* Meetings at Roundtables or other activities if needed + +==== Governance + +* Chair chosen by Steering Committee members +* Chair participates in Board of Directors meetings + +==== Activities + +* Overall technical direction +* Management of Technical Committees via TC CHAIRS +committee +* Consortium program elements +* Advice to the Board of Directors + +=== Why Get Involved in CalConnect + +* Help shape the evolution of calendaring and +scheduling specifications, standards and +products +* Develop real-world use cases and +requirements +* Make sure needs are considered +* Work directly with developers/major +customers +* Help drive the calendaring community +towards interoperability +* Member may have as many representatives +as desired in Consortium Activities + +=== Membership + +==== Eligibility + +Any company, institution or individual who: + +* supports the goals of the Consortium +* agrees to abide by its rules +* submits the proper membership application +* pays the appropriate membership fee + +==== Fees + +* Published on the Consortium web site +* Based on membership category +* Due annually upon anniversary of joining the +Consortium + +==== Categories + +* Commercial Vendor +** >$100 million annual revenue +** $10-100 million annual revenue +** >$10 million annual revenue +* Customer Organizations/Companies +* Non-Profit Organizations +* Open Source Organizations +* Academic Institutions +* Standards Setting Organizations +* Individuals + +=== Organizational Structure + +.Organizational structure +image::img01.png[] + +=== Events + +. Interops (Interoperability Testing) +** Open to members and non-members +** Two day event usually co-located with Roundtable +** Results published to relevant standards development +organizations +** Public reports are "sanitized" + +. Roundtables +** "All hands" plenary meeting of membership +** Three per year, midway between IETF meetings +** Held in conjunction with Interops +** Technical committee working meetings +** Steering Committee meeting +** Review and status of technical committees + +. Workshops +** Open or invitational depending on goal & topic +** May involve non-Consortium members and liaisons +** Co-hosted with Roundtable or independent event + +. Calendaring & Scheduling Public Conference +** *Under evaluation* +** Would offer technology and product overviews, +tutorials and classes, demonstrations and vendor +offerings + +=== Current Technical Committees + +==== CALDAV + +Define problems +CalConnect wishes to +solve with extensions to +WebDAV; assist IETF +with development of +CalDAV Specification + +==== EVENTPUB + +Define event publishing +& establish differences +from regular +calendaring and +scheduling + +==== FREEBUSY + +Develop and conduct +Federated Free/Busy +Challenge Response; +review Free/Busy +related proposals + +==== IOPTEST + +Support interoperability +testing for all technical +committees, develop +test suites & reference +implementation, publish +Interop results + +==== MOBILE + +Define issues for mobile +support of standards-based +Calendaring and +recommend extensions +to standards for mobile +support + +==== REALTIME + +Clarify issues involved +with realtime server-to-server +calendaring and +scheduling issues & +provide +recommendations + +==== TIMEZONE + +Develop proposals for a +formal, authoritative +Timezone Registry and +a Timezone Service +Protocol + +==== USECASE + +Develop sets of real +world use cases that +can be used to validate +identified functionality & +testing scenarios for +existing & future C&S +implementations + +== The Current State of Calendaring Standards + +=== Calendaring Standards Today + +==== [strike]#IETF CALSCH Working Group# + +* [strike]#Developed RFCs 2445/6/7# +* [strike]#Shut down in 2004 at same time as CAP removed from table# + +==== [strike]#Original CAP (Calendar Access Protocol)# + +* [strike]#Assigned "experimental draft" status by IETF in 2004 (effectively removed from program of work in IETF)# + +==== [strike]#vCalendar# + +* [strike]#Still in use especially in mobile calendaring, travel industry websites# +* [strike]#Not fully compatible with iCalendar (e.g. recurrence); encourage move to iCalendar# +* https://www.calconnect.org/publications/iCalendarforthemobileindustryv1.0.pdf[The Benefits of iCalendar for the Mobile Industry] + +==== vCard + +* Not precisely "calendaring" -- but contacts/address +book central to calendaring +* Current version 3.0 needs work +* Mobile calendaring mostly obsolete vCard 2.1 +* https://www.calconnect.org/vcardworkshopreport.shtml[CalConnect vCard workshop] + +==== IETF "CALSIFY" Working Group + +* Simplify (rationalize) RFCs 2445/6/7 + +==== RFCs 2445/6/7 (iCalendar, iTIP, iMIP) + +* Target of initial CalConnect work products +* All have revised drafts underway +* Expect publication of revised RFCs in 2008 +* Still require interoperability demonstration to +progress to Draft Standards (i.e. CalConnect) + +==== CalDAV + +* "Calendaring Extensions to WebDAV" published as +Proposed Standard, RFC 4791 +* "Scheduling Extensions to CalDAV" is under +review for submission +* Several CalDAV implementations today +** Apple iCal Server (Darwin Calendar Server) +** Bedework +** Evolution +** Kerio Technologies (Kerio MailServer) +** Marware (Project X Client) +** Mozilla Lightning & Sunbird (CalDAV client) +** Mulberry (Client) +** Oracle Calendar +** OSAF Cosmo (Chandler Project) +** Etc. + +==== iCalendar Extensions + +* Proposed extensions (additions) to the revised +iCalendar when it is complete +* `VAVAILABILITY` +** New iCalendar component allowing publication of available +and unavailable time periods associated with calendar user +* `VVENUE` +** New iCalendar component allowing the specification of +structured location data for publishing event information + +==== EVENTMAP protocol + +* Identifies location on website of structured event +information for use by event publication +aggregators + +== CalConnect Activities and Accomplishments + +=== TC CALDAV + +==== Charter + +* Begin: October 2004 +* Define problems CalConnect wishes to resolve with _CalDAV Extensions to WebDAV_ +* Assist IETF with CalDAV Specifications + +==== Projects, Topics + +* Act as "real world" input to CalDAV Specification authors +(two of three are members of TC CALDAV) +* Develop CalDAV testing matrices for TC IOPTEST +* Develop `VAVAILABILITY` with TC FREEBUSY +* Develop use cases and requirements for CalDAV +Scheduling +* *CalDAV scheduling extensions (discovery, auth/auth, etc.)* + +==== Products + +* CalDAV testing matrices for Interoperability testing +* CalDAV Use Cases and Requirements +* CalDAV Scheduling Requirements +* *`VAVAILABILITY` extension to iCalendar* + +=== TC EVENTPUB + +==== Charter + +* Begin: March 2005 +* Define Event Publication and distinguish from regular +calendaring +* Determine requirements for event publication not met by +existing specifications and propose remedies + +==== Projects, Topics + +* Review of possible extensions to iCalendar to support +event publication and venue information +* *Develop mechanism for event "crawlers" to find and +consume event information on websites, analogous to +"sitemap"* + +==== Products + +* `VVENUE` extension to iCalendar +* *`EVENTMAP` proposal under development* + +=== TC FREEBUSY + +==== Charter + +* Begin: May 2006 +* Act as CalConnect Liaison with The Open Group for the Federated +Freebusy Challenge in 2006 +* Inform the work of CALDAV, REALTIME, and other TCs +* Participate in drafting the final report for The Open Group + +==== Projects, topics + +* Demo-ed a Federated Freebusy Aggregator at The Open Group +meeting in July 2006 +* Assist Boeing to "productize" components used in the demo as well +as those being further developed by Boeing +* *Addressing "office hours"/"availability" -- joint `VAVAILABILITY` +project with TC CALDAV* +* *Standardize and simplify FREEBUSY URL* + +==== References + +* http://tools.ietf.org/html/draft-daboo-calendar-availability-00 +* http://calconnect.org/publicity/060724freebusydemorelease.pdf +* http://calconnect.org/presentations/freebusydemo.pdf + +=== TC IOPTEST + +==== Charter + +* Begin: October 2004 +* Conduct CalConnect Interoperability Test Events and +publish results + +==== Projects, topics + +* CalConnect Interoperability Test Events scheduled with +each Consortium event week (i.e. together with +Roundtables) + +==== Products + +* Public and CalConnect-internal IOP test event reports + +=== TC MOBILE + +==== Charter + +* Begin: September 2005 +* Identify issues related to mobile calendaring and +scheduling and develop recommendations to address + +==== Projects, topics + +* Determine mobile calendaring issues and problems +* Survey mobile users about calendaring +* Evaluate continued reliance on vCalendar and develop +ways to move vendors forward +* Develop Mobile Calendaring Interoperability Test Suite +* *Implement Mobile IOP Test Events (with TC IOPTEST)* +* *Define Mobile Calendaring issues for CalDAV* + +==== Products + +* Report on Mobile Calendaring Questionnaires +* Mobile Calendaring Interoperability Test Suite +* Benefits of iCalendar for the Mobile Industry + +=== TC REALTIME + +==== Charter + +* Begin: June 2007 +* Identify issues related realtime server-server scheduling +and make recommendations to address + +==== Projects, topics + +* Discovery, Authentication and Authorization +* iTIP evaluation and extensions +* Work with TC CALDAV, TC FREEBUSY + +==== Products + +=== TC RECURR + +==== Charter + +* Begin: October 2004 (completed February 2006) +* Identify problems with Recurrences in iCalendar +* Make recommendations to IETF CALSIFY effort (revision of +RFC 2445 iCalendar) + +==== Projects, topics + +* Questionnaires to determine problems with recurrence in +implementations of iCalendar +* Develop problem statement and recommendations + +==== Products + +* Results from Recurrence Questionnaire +* iCalendar Recurrence Problems and Recommendations + +=== TC TIMEZONE (Phase 1) + +==== Charter + +* Begin: October 2004 (completed February 2006) +* Identify problems with timezone usage in iCalendar and +timezone support in genera + +==== Projects, topics + +* Conduct survey on problems with timezone management +* Develop problem statements and recommendations for +IETF CALSIFY effort for iCalendar + +==== Products + +* Timezone Questionnaire +* Report on Timezone Questionnaire +* Timezone Problems and Recommendations +* Timezone Registry and Service Recommendations + +=== TC TIMEZONE (Phase 2) + +==== Charter + +* Begin: May 2007 +* Continue work of TC TIMEZONE by developing formal +proposals based on Timezone Registry and Service +Recommendations + +==== Projects, topics + +* *Develop proposal for formal, authoritative Timezone +Registry for submission to IETF to be published as an RFC* +* *Develop requirements for Timezone Registry Service* +* *Develop proposals for Timezone Registry Service +implementations using current protocols* + +==== Products + +=== TC USECASE + +==== Charter + +* Begin: October 2004 +* Develop use cases for calendaring and scheduling and +their contextual environments +* Establish the ways that users actually want to use +calendaring environments +* Establish "Minimum Interoperable Subsets" (the minimum +set of functions which must be interoperable to make an +implementation useful to a customer) + +==== Projects, topics + +* *Assessment of access control in existing calendaring +implementations for TC CALDAV* +* *Develop Min-IOP use cases for Resources* + +==== Products + +* Min-IOP Use Cases for iCalendar +* CalDAV Use Cases (with TC CALDAV) +* Min-IOP Use Cases for Tasks +* Calendaring and Scheduling Glossary of Terms +* *Min-IOP Use Cases for Resources* + +=== DST AD HOC + +==== Charter + +* Begin: June 2005 +* Establish CalConnect position on Extended Daylight Savings Time +Proposal by U.S. Congress +* Continue DST Advisory Work + +==== Projects, topics + +* Develop CalConnect position on EDST and communicate to U.S. +Congress prior to enactment of law +* Develop guidance for industry on planning for and implementing +EDST Changes in March and October +* Work with TC TIMEZONE on recommendations on future of +timezone and DST support + +==== Products + +* Extended Daylight Savings Time Advisory +* Extended Daylight Savings Time Review and Considerations +* EDST Links, Advisories and Changes +* CalConnect Reflections and Recommendations + +=== vCard Ad Hoc + +==== Charter + +* Begin: January 2007 +* Determine interest in and support for revision of vCard +standard + +==== Projects, topics + +* vCard Workshop planning and implementation +* Liaisons with OMA/DS on interest in vCard Revision +* *Identify products of vCard Technical Committee* +* *Develop charter for vCard Technical Committee in support of IETF working group on vCard revision* +* *Recommendation on establishment of vCard TC* + +==== Products + +* vCard Workshop (September 2007) +* Draft Charter for vCard Technical Committee + +=== XML Ad Hoc + +==== Charter + +* Begin: May 2007 +* Plan for and explore XML representations of iCalendar +* Determine need for XML Technical Committee + +==== Projects, topics + +* Conduct BOFs to determine level of support for roundtrip +iCalendar/XML +* Review prior art in this are +* *Develop charter for XML Technical Committee* +* *Identify potential products of XML TC* +* *Recommendation for establishment of XML TC* + +==== Products + +* *Draft charter for XML Technical Committee* + +== Summary: New and Proposed Work + +=== New Activities + +* Mobile Calendaring Interoperability Test +Suite +* Planning for Mobile Calendaring +Interoperability Test Events +* Min-IOP Use Cases for Resources +* Expansion of IOP Testing areas +** EDST +** iTIP +** CalDAV Scheduling +* Formal Timezone Registry and Timezone +Registry Service proposals +* FREE/BUSY URL +* `VAVAILABILITY` ("Office Hours") +* `EVENTMAP` protocol +* Event Sharing between servers +* Automated Scheduling Updates (CalDAV) +* External Attachments (CalDAV) +* vCard Revision +* XML iCalendar Representations +* `REALTIME` issues for iTIP and scheduling +** Addressability +** Discovery +** Authentication/Authorization/Access Control +* Diverse calendaring specifications & tools +(CalATOM, RSS/SSE, microformats, CalDAV, +proprietary calendaring systems) +** Develop and publish guide and comparison +** Work towards ensuring interoperability and +synergy between various tools and specs + +== More Info + +. Website: http://www.calconnect.org +. Contact us: info@calconnect.org +. For more information: ++ +-- +Dave Thewlis, Executive Director + +The Calendaring and Scheduling Consortium + +4390 Chaffin Lane + +McKinleyville, CA 95519-8028 + +Voice: +1 707 840 9391 + +FAX: +1 415 946 3454 + +Mobile: +1 707 498 2238 + +Email: Dave.Thewlis@calconnect.org +-- + +[bibliography] +== References + +* [[[ccw, CalConnect Web Site]]], http://www.calconnect.org + +* [[[ccpd, CalConnect Published Documents]]], http://www.calconnect.org/aboutproducts.shtml (Questionnaires, Recommendations, Use Cases and Requirements, Mobile Interoperability Test Suite, Calendaring and Scheduling Glossary of Terms, Event Reports, vCard Workshop Report) + +* [[[ccs, CalConnect Calendaring Standards]]], http://www.calconnect.org/calendaringstandards.shtml + +* [[[ccp, CalConnect Presentations]]], http://www.calconnect.org/presentations.shtml + +* [[[ccdst, CalConnect DST Documents]]], http://www.calconnect.org/dstdocs.shtml diff --git a/sources/cc-0705-pres-overview/images/img01.png b/sources/cc-0705-pres-overview/images/img01.png new file mode 100644 index 0000000..f869c61 Binary files /dev/null and b/sources/cc-0705-pres-overview/images/img01.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/document.adoc b/sources/cc-0706-ioptest-suite-v1.1/document.adoc new file mode 100644 index 0000000..a4de059 --- /dev/null +++ b/sources/cc-0706-ioptest-suite-v1.1/document.adoc @@ -0,0 +1,3077 @@ += Mobile Calendar Interoperability Test Suite +:docnumber: 0706 +:copyright-year: 2008 +:language: en +:doctype: specification +:edition: 1.1 +:status: published +:revdate: 2008-08-24 +:published-date: 2008-08-24 +:technical-committee: MOBILE +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Chris Dudding +:affiliation: Symbian Ltd +:role: editor +:fullname_2: Mark Paterson +:role_2: editor +:affiliation_2: Oracle +:imagesdir: images + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +The Mobile Technical Committee of the Calendaring and +Scheduling Consortium created this document. It describes a +test suite to assess a mobile device's capability to synchronize +calendar data with a calendar store. + +[.preface] +== metanorma-extension + +=== document history + +[source,yaml] +---- +- date: + - type: published + value: 2007-08-28 + edition: 1.0 + amend: + - description: First publicly available version +- date: + - type: updated + value: 2008-08-04 + edition: 1.1 + amend: + - description: | + Added reference to 'Mobile Recurrence Interoperability Recommendations' paper + + Updated 'Repeating Entries' test cases to describe expected behavior for mobile devices and servers following the recommendations in the 'Mobile Recurrence Interoperability Recommendations' paper + + Revised 'Repeating Events and Recurrence Rules' section in Appendix A +---- + +== Introduction + +This document describes the test steps required to assess a mobile device's capability to +synchronize calendar data with a calendar store (referred to from now on as "the server"). + +It is provided as a resource for implementers to help promote interoperability, but the successful +execution of the test cases described herein should not be considered as any type of formal +validation. + +The tests described in this document are to be manually executed. Data synchronization sessions +will be initiated between the mobile device under test and the server. A desktop or web based +calendar client should be used to enter and verify data on the server. + +The testing method used will be a black box testing approach, wherein inputs will be provided +from both the server and device and outputs will be generated. Comparisons between the actual +output and the expected output will determine the capability of the device to synchronize calendar +data. + +The test cases have been written with the understanding that some form of synchronization is +occurring, but they make no assumptions concerning the underlying methodology. They can be +used for testing OMA Data Synchronization (formerly SyncML) implementations, cable based +synchronization solutions, or even mobile clients which reconcile a local store using <> (or +their own proprietary protocol). It should also be possible to test direct data transfer between +devices using short link connectivity protocols such as Bluetooth(R) or Infrared with minimal +changes. + +The test cases assume that the underlying data exchange formats used will be <> and +<>. + +It is possible to use these test cases with implementations that use <>, <>, or +some other proprietary format. Arguments supporting the importance of iCalendar to the Mobile +Industry are discussed in the Consortium white paper on +<>. + +The intent of this test suite is to verify the validity of the calendar data that is exchanged and to +guarantee that the calendar user has an accurate representation of their calendar regardless of +which side (mobile device or server) they are viewing it from. + +It does not attempt to go beyond this scope, so it does not include tests for such things as: + +* Conflict Resolution +* Correct protocol usage (e.g. support for OMA DS Server Alerted Notification or +Suspend/Resume) +* Stress tests for a large volume of calendar events +* Stress tests for calendar event content, such as very long `DESCRIPTION` properties (e.g. +copying full text of an email into the calendar description) +* Effects experienced when multiple synchronization technologies are used in parallel (e.g. +duplicate entry problems reported when using Palm(R) HotSync(R) or BlackBerry(R) clients +and OMA DS in conjunction) +* Negative test conditions. In other words, incorrect input data that deliberately generates +errors such as invalid recurrence patterns + +Each group of tests starts with basic test cases to verify that essential calendaring data can be +transferred back and forth accurately. These are followed by tests that focus on aspects that have +been identified as problem areas. + +Some test cases identify problem areas for further discussion at a forthcoming CalConnect Mobile +Interoperability Test Event. These 'Birds of a Feather' discussion items are marked with +'[underline]#_BOF Topic_#' in the text. References to external specifications are shown in the text in square brackets. + +A complete list of limitations and current omissions within this test suite are documented in +<>. + +[heading=terms and definitions,source=calgloss] +== Definitions + +=== Access control + +A mechanism to grant or deny privileges (Create, Read, Update, Delete) on +calendars, events, tasks or journal entries to other calendar users. + +=== Alarm + +A reminder for an event or a to-do. Alarms may be used to define a reminder for a +pending event or an overdue to-do. + +=== 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. + +[.source] +<> + +=== Calendar User +alt:[CU] + +An entity (often a human) that accesses calendar information. + +[.source] +<> + +=== Calendaring + +An application domain that covers systems that allow the interchange, access and +management of calendar data. + +=== CalConnect + +The Calendaring and Scheduling Consortium consists of vendors and user +groups interested in promoting and improving calendaring and scheduling standards and +interoperability. + +=== Coordinated Universal Time +alt:[UTC] + +An atomic realization of Universal Time (UT) or +Greenwich Mean Time, the astronomical basis for civil time. Time zones around the world are +expressed as positive and negative offsets from UT. UTC differs by an integral number of +seconds from International Atomic Time (TAI), as measured by atomic clocks and a fractional +number of seconds from UT. + +[.source] +<> + +=== Daylight Savings Time +alt:[DST] + +The period of the year in which the local time of a particular time +zone is adjusted forward, most commonly by one hour, to account for the additional hours of +daylight during summer months. + +=== Event + +A calendar object that usually takes up time on an individual calendar. Events are +commonly used to represent meetings, appointments, anniversaries, and day events. + +=== iCalendar + +The Internet Calendaring and Scheduling Core Object Specification. An IETF +standard (RFC 2445) for a text representation of calendar data. + +=== Instance + +When used with recurrences, an instance refers to an item in the set of recurring +items. + +=== Invite + +To request the attendance of someone to a calendar event. + +=== Notification + +. The action of making known, an intimation, a notice. +. Reminder or alarm sent +when any resource or parties interested in the resource need an indicator that some attention is +required. Possible notification methods include email, paging, audible signal at the computer, +visual indicator at the computer, voice mail, telephone. + +=== Organizer + +The originator of a calendar event typically involving more than one attendee. + +=== Priority + +A level of importance and/or urgency calendar users can apply to Tasks and Events. + +=== Recurring + +Happening more than once over a specified interval, such as weekly, monthly, daily, +etc. See {{Repeating}}. + +=== Repeating + +An event that happens more than once. You might want an event to occur on a +regular basis. To do this you schedule a repeating event. Any changes you make to the event can +automatically be made to all occurrences of the event. If necessary, changes can be made to +individual events without affecting the others. For example, if you need to attend a weekly +meeting, you can schedule a repeating event on your calendar. Using another example, if you +want to schedule a five day vacation, schedule an all-day event that repeats daily for a total of +five times. If you have to cancel one of the days, delete the one day without deleting the whole +event. + +=== Reminders + +See {{Notification}}. + +=== Time zone + +Areas of the Earth that have adopted the same local time. Time zones are generally +centered on meridians of a longitude, that is a multiple of stem:[15 "unitsml(deg)"], +thus making neighboring time +zones one hour apart. However, the one hour separation is not universal and the shapes of time +zones can be quite irregular because they usually follow the boundaries of states, countries or +other administrative areas. + +[.source] +<> + +== Abbreviations + +BOF:: Birds of a Feather +CJK:: Chinese, Japanese, Korean languages +GMT:: Greenwich Mean Time +IETF:: Internet Engineering Task Force +IOP:: Interoperability +OMA:: Open Mobile Alliance +OMA:: DS Open Mobile Alliance Data Synchronization (formerly SyncML) +PIM:: Personal Information Management +URL:: Uniform Resource Locator +UTC:: Universal Time Coordinated + +== Part I -- Calendar Tests + +=== Events + +The following set of tests verifies that basic events can be passed back and forth between the +mobile device and the server. They also attempt to verify the following: + +* that events with large amounts of data do not adversely affect the mobile device. +* that any form of truncation that may need to occur on the device does not adversely +effect the representation on the server +* that reminders can be part of the event +* that appropriate mappings are done for access level and priorities +* that special characters and multi-byte characters can be correctly displayed on either +side. + +NOTE: <> -- Special Information, has additional information on truncations, mappings, +reminders, special characters, and multi-byte characters. + +NOTE: All tests should be performed in succession. + +[cols="a,a,a,a",options=header] +.Server to Device +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 1.1 Create an Event with a Reminder +| Verify that basic events synchronize to the device. + +Verify that filling out all fields with long strings does not cause the device issues + +Verify that reminders can be sent +| From the Server, create a simple future event, filling out all fields with maximum input, with a reminder. + +Perform a synchronization + +From the device, modify the event and remove the reminder. + +Perform a synchronization +| The event should display on the device with all fields on the server correctly mapped to corresponding fields on the device. The device can only display what it supports and perhaps may need to truncate certain fields but the user should see an accurate representation of the event. The reminder should also be set on the device. + +After making modifications and synchronizing, the changes should display on the server as well. There should be no evidence of any truncation server-side if truncation occurred client-side but the field itself was not actually part of the modification done. + +The reminder should be removed from the server-side event. + +[reviewer="N.B."] +**** +Some implementations will preserve reminders on the server-side event. They consider that reminders on the mobile side are distinct from those on the server +**** + +h| 1.2 Access Level and Priority +| Verify that access level and priority values in events correctly synchronize to the device. + +Verify that any form of mapping that occurs does not have adverse effects +| From the Server, create an event with default access and priority (e.g. Normal/Medium). + +Perform a synchronization + +From the device, modify the event. + +Perform a synchronization + +Repeat making sure to test all supported access level and priorities. +| The event should display on the device with the access level and priority appropriately mapped if needed. + +After making modifications and synchronizing, the changes should display on the server as well. There should be no evidence of any change server-side to the access level or priority if not actually part of the modification done + +h| 1.3 Special Characters From Server +| Verify that special characters in events correctly synchronize to the device. +| From the Server, create an event filling out all fields with special characters. + +Perform a synchronization + +From the device, modify the event. + +Perform a synchronization +| The event should display on the device with all fields on the server correctly mapped to corresponding fields on the device. All special characters should correctly display on the device as it is displayed on the server. + +After modifying the event, the characters should remain correctly displayed on both the device and server and the changes made on the device should be reflected on the server + +h| 1.4 Multi-Byte Characters From Server +| Verify that multi-byte characters in events correctly synchronize to the device. +| From the server, create a meeting filling out all fields with multi-byte characters. + +Perform a synchronization + +From the device modify the event. + +Perform a synchronization +| The event should display on the device with all multi-byte characters correctly displayed. + +After modifying the event, the multi-byte characters should remain correctly displayed on both the device and server, and the changes made on the device should be reflected on the server. + +h| 1.5 Deletion +| Verify that events deleted server side are deleted on the device +| From the server delete all events created in previous tests. + +Perform a synchronization +| The deleted events should not be displayed on the device +|=== + +[cols="a,a,a,a",options=header] +.Device to Server +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 1.6 Create an Event with a Reminder +| Verify that basic events synchronize to the server. + +Verify that reminders can be sent +| From the device, create a simple future event with a reminder. + +Perform a synchronization + +From the server, edit the event and remove the reminder. + +Perform a synchronization +| The event should display on the server with all fields mapped correctly. The reminder should be set on the server as well. + +After editing the meeting and syncing, the meeting should be updated on the device. + +The reminder should be removed from the device-side event. + +[reviewer="N.B."] +**** +Some implementations will preserve reminders on the device-side event. They consider that reminders on the mobile side are distinct from those on the server +**** + +h| 1.7 Access Level and Priority (can only be done if device supports setting an access level or priority) +| Verify that access level and priority values in events correctly synchronize to the server. +| From the device, create an event with default access and priority (e.g. Normal/Medium). + +Perform a synchronization + +Repeat making sure to test all supported access level and priorities. +| The event should display on the server with the access level and priority appropriately mapped if needed. + +h| 1.8 Special Characters from Device +| Verify that special characters in events correctly synchronize to the server. +| From the device, create an event filling out all fields with special characters. + +Perform a synchronization + +From the server, modify the event. + +Perform a synchronization +| The event should display on the server with all fields on the device correctly mapped to corresponding fields on the server. All special characters should correctly display on the server as it is displayed on the device. + +After modifying the event, the characters should remain correctly displayed on both the device and server. + +h| 1.9 Multi-Byte Characters from Device +| Verify that multi-byte characters in meetings correctly synchronize to the server. +| From the device, create a meeting filling out all fields with multi-byte characters. + +Perform a synchronization + +From the server, modify the event + +Perform a synchronization +| The event should display on the server with all fields on the device correctly mapped to corresponding fields on the server. All multi-byte character should be displayed correctly. + +After modifying the event, the multi-byte characters should remain correctly displayed on both the device and server, and the changes on the server should be reflected on the device. + +h| 1.10 Deletion +| Verify that events deleted device side are deleted on the server +| From the device delete all events created in previous tests. + +Perform a synchronization +| The deleted events should be deleted off of the server as well. +|=== + +=== All Day Events + +The following set of tests verifies that all-day events can be passed back and forth between the +mobile device and the server. They also attempt to verify the following: + +* that all day events locked to a specific day remain locked to that day. +* that all day events which span multiple days can be handled + +NOTE: <> -- Special Information, has additional information on all day events. + +NOTE: All tests should be performed in succession. + +[cols="a,a,a,a",options=header] +.Server to Device +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 2.1 Create all-day event in same time zone +| Verify that all-day events can be synchronized when server and device are in the same time zone +| Verify that time zone selected on server and mobile device is the same. + +Create an all-day event on server on 6^th^ December 2006 (start date 06/12/06, end date 06/12/06) with a subject of 'all-day event'. + +Synchronize with mobile device. +| Event should display as an all-day event in the device calendar on 06/12/06. + +If the mobile device uses an icon to distinguish an all-day event from a timed appointment this is displayed for this entry. + +h| 2.2 Create all-day event to device in different time zone +| Verify that all-day events can be synchronized when server and device are in a different time zone +| Set the time zone on the server to GMT (London) and the time zone on the mobile device to GMT-5 (Eastern Time, US & Canada) + +Create an all-day event on server on 6^th^ December 2006 (start date 06/12/06, end date 06/12/06) with a subject of 'all-day event'. + +Synchronize with mobile device. +| Event should display as an all-day event in the mobile device on 06/12/06. + +If the mobile device uses an icon to distinguish an all-day event from a timed appointment this is displayed for this entry. + +h| 2.3 Create a Single Instance All Day Event with Reminder +| Verify that basic calendar entries synchronize to the device. +| From the Server, create a single instance future all-day event, filling out all fields with maximum input, with a reminder. + +Perform a synchronization + +From the device, modify the day event and remove the reminder. + +Perform a synchronization +| The day event should display on the device as an all day event with all fields on the server correctly mapped to corresponding fields on the device. The reminder should also be set on the device. + +After making modifications and synchronizing, the changes should display on the server as well. Any client side truncation of fields should not be propagated back to the server. + +[underline]#_BOF Topic_#: What form should the iCalendar be to represent a day event? Currently the vCalendar to send depends greatly on the manufacturer of the device. + +h| 2.4 Create an anniversary all-day event +| Verify that anniversaries can be synchronized +| Create an anniversary on the server on 4^th^ May 2007 + +Perform a synchronization +| The anniversary should display on the device on 4^th^ May 2007 + +h| 2.5 All-day event on last day of month & last day of year check +| Verify boundary conditions +| Create an all-day event/anniversary on 31^st^ March 2007 and 31^st^ December 2007 +| The all-day event/anniversary should display on the device on 31/03/2007 and 31/12/2007 + +h| 2.6 Create a Single Instance Holiday with Reminder +| Verify that basic calendar entries synchronize to the device. +| Perform previous test cases, but for Holidays instead of All Day Events + +A 'Holiday' is a special type of all-day event supported by some calendar products + +Holidays may not be supported in the same fashion for all systems. +| The Holiday should display on the device as something appropriate (as a holiday or an all day event depending on what the device can support) with all fields on the server correctly mapped to corresponding fields on the device. + +On the ensuing synchronization changes should not be propagated to the server as holidays can't be changed. + +[underline]#_BOF Topic_#: What should be expected behaviour? Should a modify be sent back to the device to put the holiday back? Some systems would allow the holiday to be removed. How do you specify that something is a holiday in iCalendar? + +h| 2.7 Update an all-day event on server and synchronize back to mobile device in same time zone +| Verify that all-day event modifications can be synchronized correctly +| Verify that time zone selected on server and mobile device is the same. + +Create an all-day event on server on 6^th^ December 2006 (start date 06/12/06, end date 06/12/06) with a subject of 'all-day event'. + +Perform a synchronization + +Update all-day event on server and modify subject to 'all-day event modified'. + +Perform a synchronization +| Event title on device calendar should be modified to 'all-day event modified' and remain an (untimed) all-day event. + +If the device calendar application uses an icon to distinguish an all-day event from a timed appointment this is displayed for this entry. + +h| 2.8 Update an all-day event on server and synchronize back to a device in different time zone +| Verify that all-day event modifications can be synchronized correctly +| Set the time zone on the server to GMT (London) and the time zone on the mobile device to GMT-5 (Eastern Time, US & Canada). + +Create an all-day event on server on 6^th^ December 2006 (start date 06/12/06, end date 06/12/06) with a subject of 'all-day event'. + +Perform a synchronization + +Update all-day event on server and modify subject to 'all-day event modified'. + +Perform a synchronization +| Event title on device calendar should be modified to 'all-day event modified' and remain an (untimed) all-day event. + +If the device calendar application uses an icon to distinguish an all-day event from a timed appointment this is displayed for this entry. + +h| 2.9 Create a Single Instance Multi-day Day Event +| Verify that basic calendar entries synchronize to the device. +| For multi-day Day Events, please read <> before testing. + +From the Server, create a single instance Day Event that starts tomorrow and ends 3 days later. Make sure this does not span outside your synchronization range. + +Perform a synchronization + +From the device, modify the end date to end 1 day earlier than the previous end date (If the device supports multi-day Day Events) + +Perform a synchronization +| For devices that support multi-day Day Events, the entry should display on the device with a Day Event that spans for the 4 days, as it is on the server. + +For devices that do not support multi-day Day Events results may vary. + +After modifying the end date from the device and synchronizing, the entry on the server should be one day shorter, reflecting the change made on the device. + +[underline]#_BOF Topic_#: What should be expected behaviour? What should iCalendar look like? + +h| 2.10 Remove Single Instance Meeting, Day Event, and Holiday +| Verify that a basic deletion synchronize to the device. +| From the Server, delete a single instance meeting, day event, and holiday + +Perform a synchronization +| All the selected entries are removed from the device. This should not affect any of the other existing entries. +|=== + +[cols="a,a,a,a",options=header] +.Device to Server +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 2.11 Create an all-day event and synchronize to a server in same time zone +| Verify that basic calendar entries can be synchronized to the server +| Verify that time zone selected on server and mobile device is the same. + +Create an all-day event on the mobile device on 6^th^ December 2006 (start date 06/12/06, end date 06/12/06) with a subject of 'all-day event'. + +Perform a synchronization +| Event should display on the server as an all-day event on 06/12/06. + +If the server calendar application uses an icon to distinguish an all-day event from a timed appointment this is displayed for this entry. + +h| 2.12 Create an all-day event and synchronize to a server in different time zone +| Verify that basic calendar entries can be synchronized to the server +| Set the time zone on the server to GMT (London) and the time zone on the mobile device to GMT-5 (Eastern Time, US & Canada). + +Create an all-day event on the mobile device on 6^th^ December 2006 (start date 06/12/06, end date 06/12/06) with a subject of 'all-day event'. + +Perform a synchronization +| Event should display on the server as an all-day event on 06/12/06. + +If the server calendar application uses an icon to distinguish an all-day event from a timed appointment this is displayed for this entry. + +h| 2.13 Create a Single Instance All Day Event with Reminder +| Verify that basic calendar entries can be synchronized to the server +| On the device, create a single instance future all-day event, filling out all fields with maximum input, with a reminder. + +Perform a synchronization + +From the device, modify the day event and remove the reminder. + +Perform a synchronization +| The day event should display on the server as an all day event with all fields on the server correctly mapped to corresponding fields on the device. The reminder should also be set on the server. + +After making modifications and synchronizing, the changes should display on the server as well. Any client side truncation of fields should not be propagated back to the server. + +[underline]#_BOF Topic_#: What form should the iCalendar be to represent a day event? + +h| 2.14 Create an anniversary all-day event +| Verify that anniversaries can be synchronized +| Create an anniversary on the device on 4^th^ May 2007 + +Perform a synchronization +| The anniversary should display on the server on 4^th^ May 2007 + +h| 2.15 Update an all-day event on mobile device and synchronize back to server in same time zone +| Verify that all-day event modifications can be synchronized correctly +| Verify that time zone selected on server and mobile device is the same. + +Create an all-day event on server on 6^th^ December 2006 (start date 06/12/06, end date 06/12/06) with a subject of 'all-day event'. + +Synchronize with mobile device. + +Update all-day event on mobile device and modify subject to 'all-day event modified'. + +Synchronize with server. +| Event subject should be modified to 'all-day event modified' and remain an (untimed) all-day event. + +If the server calendar application uses an icon to distinguish an all-day event from a timed appointment this is displayed for this entry. + +h| 2.16 Update an all-day event on mobile device and synchronize back to a server in different time zone +| Verify that all-day event modifications can be synchronized correctly +| Set the time zone on the server to GMT (London) and the time zone on the mobile device to GMT-5 (Eastern Time, US & Canada). Create an all-day event on server on 6^th^ December 2006 (start date 06/12/06, end date 06/12/06) with a subject of 'all-day event'. Synchronize with mobile device. + +Update all-day event on mobile device and modify subject to 'all-day event modified'. Synchronize with server. +| Event subject should be modified to 'all-day event modified' and remain an (untimed) all-day event. + +If the server calendar application uses an icon to distinguish an all-day event from a timed appointment this is displayed for this entry. + +h| 2.17 Create a Single Instance Multi-Day Day Event +| Verify that basic calendar entries can be synchronized to the server +| For multi-day Day Events, please read section in <> before testing. + +If the device allows for creation of multi-day Day Events, then create a single instance Day Event that starts tomorrow and ends 3 days later. Make sure this does not span outside your synchronization range. + +Perform a synchronization + +From the device, modify the end date to end 1 day earlier than the previous end date. + +Perform a synchronization +| Upon the first synchronization, the multi-day Day Event should display on the Server spanning 4 days. + +After modifying the entry and synchronizing, the server side entry should display as being one day less. + +h| 2.18 Remove Single Instance Meeting, Day Event, and Holiday +| Verify that a basic deletion synchronize to the server. +| From the device, delete a single instance meeting, day event, and holiday + +Perform a synchronization +| All the selected entries are removed from the server. This should not affect any of the other existing entries. +|=== + +=== Repeating Entries + +The following test cases verify that recurring events can be synchronized between device and +server. + +In particular + +* Repeating calendar events can be created +* Repeating calendar events can be modified (exceptions added/removed) +* Repeating calendar events can be deleted + +NOTE: The level of `REPEATING`/`RECURRING` meeting support will vary depending on the +server. See <> for explanation on possible levels of support. + +NOTE: All tests should be performed in succession. + +[options=header,cols="a,a,a,a"] +.Server to Device +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 3.1 Create Daily Repeat (every day, bounded) +| Verify that a daily repeat can be synchronized + +[example] +Five day conference +| Create an appointment on 23^rd^ April 2007 with a daily repeat until 27^th^ +April 2007 + +Perform a synchronization +| Device calendar should display 5 occurrences of a daily repeating meeting + +Level 0 device: Individual occurrences will not be linked + +Level 1 & 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img01.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.2 Create Daily Repeat (every other day, unbounded) +| Verify that a daily repeat can be synchronized + +[example] +Meeting every other day +| Create an appointment on 23^rd^ April 2007 with a daily repeat every other day + +Perform a synchronization +| Device calendar should display a daily repeating meeting every other day starting from 23^rd^ April 2007 + +The repeat pattern should remain unbounded (in other words, it should repeat forever) + +Level 0 device: Individual occurrences will not be linked + +Level 1 & 2 device: Meeting should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img02.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.3 Create Daily Repeat (every 7 days, unbounded) +| Verify that a daily repeat can be synchronized + +[example] +Weekly Staff Meeting +| Create an appointment on 2^nd^ May 2007 with a daily repeat every 7 days + +Perform a synchronization +| Device calendar should display a weekly meeting every seven days (every Wednesday) from 2^nd^ May 2007 + +The repeat pattern should be the same visible pattern as a weekly repeat and it should be unbounded + +Level 0 device: Individual occurrences will not be linked + +Level 1 & 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img03.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.4 Create Weekly Repeat (every Wed, unbounded) +| Verify that a weekly repeat can be synchronized + +[example] +Meeting every Wednesday +| Create an appointment on 2^nd^ May 2007 with a weekly repeat on Wednesday + +Perform a synchronization +| Device calendar should display a weekly meeting every Wednesday from 2^nd^ May 2007 + +The repeat pattern should remain unbounded + +Level 0 device: Individual occurrences will not be linked + +Level 1 & 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img04.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.5 Create Weekly repeat (Wed & Fri, unbounded) +| Verify that a weekly repeat can be synchronized + +[example] +Swimming class held every week on Wednesday and Fridays +| Create an appointment on 2^nd^ May 2007 with a weekly repeat on Wednesday and Friday + +Perform a synchronization +| Device calendar should display a weekly meeting with occurrences on Wednesday and Fridays from 2^nd^ May + +The first two occurrences should be 02/05/07 and 04/05/07 + +The repeat pattern should remain unbounded + +Level 0 device: Individual occurrences will not be linked + +Level 1 & 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img05.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.6 Create Fortnightly Repeat (unbounded) +| Verify that a weekly repeat can be synchronized + +[example] +Project status meeting held every two weeks +| Create an appointment on 1^st^ May 2007 with a fortnightly repeat + +Perform a synchronization +| Device calendar should display an appointment every two weeks starting from 1^st^ May + +The repeat pattern should remain unbounded + +Level 0 device: Individual occurrences will not be linked + +Level 1 & 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img06.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.7 Create Monthly By Date Repeat (unbounded) +| Verify that a monthly by date repeat can be synchronized + +[example] +Utility bill payment on 15^th^ day of the month + +| Create an appointment on 15^th^ May 2007 with a monthly by date repeat + +Perform a synchronization +| Device calendar should display an appointment on 15^th^ of every month starting from 15^th^ May 2007 + +The repeat pattern should remain unbounded + +Level 0 device: Individual occurrences will not be linked + +Level 1 & 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img07.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.8 Create Monthly By Day Repeat (first occurrence, bounded) +| Verify that a monthly by date repeat can be synchronized + +[example] +Monthly meeting on the first Monday of every month +| Create an appointment on 7^th^ May 2007 repeating every month on the first Monday for a year (13 occurrences in total) + +Perform a synchronization +| Device calendar should display an appointment on the following dates: + +07/05/2007, + +04/06/2007, + +02/07/2007, + +06/08/2007, + +03/09/2007, + +01/10/2007, + +05/11/2007, + +03/12/2007, + +07/01/2008, + +04/02/2008, + +03/03/2008, + +07/04/2008, + +05/05/2008 + +Level 0 device: Individual occurrences will not be linked + +Level 1 & 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img08.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.9 Create Monthly By Day Repeat (n^th^ occurrences, bounded) +| Verify that a monthly by day repeat can be synchronized + +[example] +Monthly meeting on the 2^nd^ Tuesday of every month +| Create an appointment 2^nd^ & 3^rd^ Sunday of every month starting on 13^th^ May 2007 until 10^th^ June 2007 (3 occurrences in total) + +Perform a synchronization +| Device calendar should display an appointment on the following dates: + +13/05/2007, + +20/05/2007, + +10/06/2007 + +Level 0 device: Individual occurrences will not be linked + +Level 1 & 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img09.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.10 Create Monthly By Day Repeat (last occurrence, bounded) +| Verify that a monthly by day repeat can be synchronized + +[example] +Monthly meeting on the last Friday of every month +| Create an appointment on the last Friday of every month starting 25^th^ May 2007 until 29^th^ June 2007 (2 occurrences in total) + +Perform a synchronization +| Device calendar should display an appointment on the following dates: + +25/05/2007, + +29/06/2007 + +Level 0 device: Individual occurrences will not be linked + +Level 1 & 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img10.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.11 Create Yearly Repeat (every year, unbounded) +| Verify that anniversary events can be synchronized + +[example] +Birthday + +[example] +St Patrick's Day (17^th^ March) +| Create an anniversary entry for Valentine's Day (14^th^ February 2007) on server + +Perform a synchronization +| Device calendar should display an anniversary event on 14/02/2007 and future years (2008, 2009 etc.) + +The repeat pattern should remain unbounded + +Level 0 device: Individual occurrences will not be linked + +Level 1 & 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img11.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.12 Create Yearly Repeat (every year for 5 years, bounded) +| Verify that yearly events can be synchronized +| Create an event with a yearly repeat on 1^st^ April 2007 for five years + +Perform a synchronization +| Device calendar should display an event on the following dates: + +01/04/2007, + +01/04/2008, + +01/04/2009, + +01/04/2010, + +01/04/2011 + +Level 0 device: Individual occurrences will not be linked + +Level 1 & 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img12.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.13 Create Yearly Repeat (every 4 years, bounded) +| Verify that yearly events can be synchronized + +[example] +Leap year occurs every four years on 29^th^ February +| Create an event with a yearly repeat on 29^th^ February 2004 every four years until 01/03/2012 + +Perform a synchronization +| Device calendar should display an event on the following dates + +29/02/2004, + +29/02/2008, + +29/02/2012 + +Level 0 device: Individual occurrences will not be linked + +Level 1 & 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img13.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.14 Create custom repeat (`RDATES` only) +| Verify that custom repeat can be synchronized + +[example,source=miniop] +Dates for a lecture series: Tuesday this week, Wednesday next week, & Friday the following week. +| Create custom repeat pattern Tuesday 1^st^ May 2007, Wednesday 9^th^ May 2007, Friday 18^th^ May 2007 + +Perform a synchronization +| Device calendar should display the event on the following dates: + +01/05/2007, + +09/05/2007, + +18/05/2007 + +Level 0 & 1 device: Individual occurrences will not be linked + +Level 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img14.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.15 Create repeat combination +| Verify that combinations of repeat patterns can be synchronized + +[example] +Daylight Saving Time starts on second Sunday in March in 2007 +| Create appointment with a repeat combination, for example: Second Sunday in March every year (`RRULE:FREQ=YEARLY; BYMONTH=3; BYDAY=2SU`) + +Perform a synchronization +| Device calendar should display event on 2^nd^ Sunday of March (11^th^ March 2007) + +The repeat pattern should remain unbounded + +Level 0 & 1 device: Individual occurrences will not be linked + +Level 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img15.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.16 Create repeating event plus custom repeat (`RRULE` + `RDATE`) +| Verify that more complex repeat patterns can be synchronized + +[example] +Weekly meeting with an extra meeting this week + +| Create a weekly repeating meeting (every Monday starting 5^th^ May 2007) and add an additional `RDATE` on Wed 7^th^ May + +Perform a synchronization +| Device calendar should display weekly repeat every Monday starting 5^th^ May 2007 and an additional meeting occurrence on 7^th^ May with the same event description + +Level 0 & 1 device: Individual occurrences will not be linked + +Level 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img16.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.17 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) +| Verify repeating meetings with exceptions can be synchronized + +[example] +Daily repeating meeting except for Wednesday +| Create a daily repeating meeting starting 30^th^ April 2007 until Friday 4^th^ May 2007. + +Create meeting exception on Wednesday 2^nd^ May (i.e. cancel meeting) +| Device calendar should display daily repeat between 30/04/07 and 04/05/07 with no meeting on 02/05/07 + +Level 0 & 1 device: Individual occurrences will not be linked + +Level 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img17.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.18 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) +| Verify that more complex repeat patterns can be synchronized +| Create custom repeat pattern + +Perform a synchronization +| Device calendar correctly displays repeating pattern + +Level 0 & 1 device: Individual occurrences will not be linked + +Level 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img18.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.19 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) +| Verify that more complex repeat patterns can be synchronized +| Create custom repeat pattern + +Perform a synchronization +| Device calendar correctly displays repeating pattern + +Level 0 & 1 device: Individual occurrences will not be linked + +Level 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img19.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.20 Modify anniversary +| Verify that modification of meeting details does not cause device representation to become non-repeating +| Create anniversary event on 4^th^ July 2007 on device + +Perform a synchronization + +Modify subject of event on server + +Perform a synchronization +| Device calendar correctly displays anniversary event on 04/07/07 + +Server modification of event subject is correctly synchronized to client + +Level 0 device: Individual occurrences will not be linked + +Level 1 & 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img20.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.21 Modify occurrences of repeating meeting +| Verify that modification of the repeat rule is correctly synchronized to the device +| Create daily repeating meeting starting on 1^st^ May 2007 until 5^th^ May (5 occurrences) + +Perform a synchronization + +Cancel occurrence on 4^th^ May & 5^th^ May (select this and future instances when deleting) from server + +Perform a synchronization +| Device calendar displays repeating meeting 1-5^th^ May + +After synchronization, device calendar displays meeting 1-3^rd^ May only + +Level 0 & 1 device: Individual occurrences will not be linked + +Level 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img21.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.22 Modify exceptions of repeating meeting +| Verify that addition, modification and deletion of exceptions is correctly synchronized +| Create daily repeating meeting starting on 1^st^ May 2007 until 5^th^ May (5 occurrences) + +Perform a synchronization + +Cancel occurrence on 4^th^ May & 5^th^ May (select this and future instances when deleting) from server + +Perform a synchronization + +Extend meeting to 4^th^ May (Modify exception) + +Perform a synchronization +| Device calendar displays repeating meeting 1-5^th^ May + +After second synchronization, device calendar displays meeting 1-3^rd^ May + +After third synchronization, calendar displays meeting 1-4^th^ May + +Level 0 & 1 device: Individual occurrences will not be linked + +Level 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img22.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.23 Delete recurring meeting +| Verify deletion of recurring meeting is correctly synchronized to the device +| Create recurring meeting on server + +Perform a synchronization + +Delete recurring meeting from server + +Perform a synchronization +| Device calendar displays recurring meeting + +After synchronization, device calendar no longer displays recurring meeting + +Level 0 & 1 device: Individual occurrences will not be linked + +Level 2 device: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img23.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +*:: Meeting not linked + +h| 3.24 Create Daily Repeat (every day, bounded) +| Verify that a daily repeat can be synchronized + +[example] +Five day conference +| Create an appointment on 23^rd^ April 2007 with a daily repeat until 27^th^ April 2007 + +Perform a synchronization +| Server calendar should display 5 occurrences of a daily repeating meeting + +Level 0 server: Test cannot be performed + +Level 1 & 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img24.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.25 Create Daily Repeat (every other day, unbounded) +| Verify that a daily repeat can be synchronized + +[example] +Meeting every other day +| Create an appointment on 23^rd^ April 2007 with a daily repeat every other day + +Perform a synchronization +| Server calendar should display a daily repeating meeting every other day starting from 23^rd^ April 2007 + +The repeat pattern should remain unbounded (in other words, it should repeat forever) + +Level 0 server: Test cannot be performed + +Level 1 & 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img25.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.26 Create Daily Repeat (every 7 days, unbounded) +| Verify that a daily repeat can be synchronized + +[example] +Weekly Staff Meeting +| Create an appointment on 2^nd^ May 2007 with a daily repeat every 7 days + +Perform a synchronization +| Server calendar should display a weekly meeting every seven days (every Wednesday) from 2^nd^ May 2007 + +The repeat pattern should be the same visible pattern as a weekly repeat and it should be unbounded + +Level 0 server: Test cannot be performed + +Level 1 & 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img26.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.27 Create Weekly Repeat (every Wed, unbounded) +| Verify that a weekly repeat can be synchronized + +[example] +Meeting every Wednesday +| Create an appointment on 2^nd^ May 2007 with a weekly repeat on Wednesday + +Perform a synchronization +| Server calendar should display a weekly meeting every Wednesday from 2^nd^ May 2007 + +The repeat pattern should remain unbounded + +Level 0 server: Test cannot be performed + +Level 1 & 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img27.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.28 Create Weekly repeat (Wed & Fri, unbounded) +| Verify that a weekly repeat can be synchronized + +[example] +Swimming class held every week on Wednesday and Fridays +| Create an appointment on 2^nd^ May 2007 with a weekly repeat on Wednesday and Friday + +Perform a synchronization +| Server calendar should display a weekly meeting with occurrences on Wednesday and Fridays from 2^nd^ May + +The first two occurrences should be 02/05/07 and 04/05/07 + +The repeat pattern should remain unbounded + +Level 0 server: Test cannot be performed + +Level 1 & 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img28.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.29 Create Fortnightly Repeat (unbounded) +| Verify that a weekly repeat can be synchronized + +[example] +Project status meeting held every two weeks +| Create an appointment on 1^st^ May 2007 with a fortnightly repeat + +Perform a synchronization +| Server calendar should display an appointment every two weeks starting from 1^st^ May + +The repeat pattern should remain unbounded + +Level 0 server: Test cannot be performed + +Level 1 & 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img29.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.30 Create Monthly By Date Repeat (unbounded) +| Verify that a monthly by date repeat can be synchronized + +[example] +Utility bill payment on 15^th^ day of the month +| Create an appointment on 15^th^ May 2007 with a monthly by date repeat + +Perform a synchronization +| Server calendar should display an appointment on 15^th^ of every month starting from 15^th^ May 2007 + +The repeat pattern should remain unbounded + +Level 0 server: Test cannot be performed + +Level 1 & 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img30.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.31 Create Monthly By Day Repeat (first occurrence, bounded) +| Verify that a monthly by date repeat can be synchronized + +[example] +Monthly meeting on the first Monday of every month +| Create an appointment on 7^th^ May 2007 repeating every month on the first Monday for a year (13 occurrences in total) + +Perform a synchronization +| Server calendar should display an appointment on the following dates: + +07/05/2007, + +04/06/2007, + +02/07/2007, + +06/08/2007, + +03/09/2007, + +01/10/2007, + +05/11/2007, + +03/12/2007, + +07/01/2008, + +04/02/2008, + +03/03/2008, + +07/04/2008, + +05/05/2008 + +Level 0 server: Test cannot be performed + +Level 1 & 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img31.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.32 Create Monthly By Day Repeat (n^th^ occurrences, bounded) +| Verify that a monthly by day repeat can be synchronized + +[example] +Monthly meeting on the 2^nd^ Tuesday of every month +| Create an appointment 2^nd^ & 3^rd^ Sunday of every month starting on 13^th^ May 2007 until 10^th^ June 2007 (3 occurrences in total) + +Perform a synchronization +| Server calendar should display an appointment on the following dates: + +13/05/2007, + +20/05/2007, + +10/06/2007 + +Level 0 server: Test cannot be performed + +Level 1 & 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img32.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.33 Create Monthly By Day Repeat (last occurrence, bounded) +| Verify that a monthly by day repeat can be synchronized + +[example] +Monthly meeting on the last Friday of every month +| Create an appointment on the last Friday of every month starting 25^th^ May 2007 until 29^th^ June 2007 (2 occurrences in total) + +Perform a synchronization +| Server calendar should display an appointment on the following dates: + +25/05/2007, + +29/06/2007 + +Level 0 server: Test cannot be performed + +Level 1 & 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img33.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.34 Create Yearly Repeat (every year, unbounded) +| Verify that anniversary events can be synchronized + +[example] +Birthday + +[example] +St Patrick's Day (17^th^ March) +| Create an anniversary entry for Valentine's Day (14^th^ February 2007) on server + +Perform a synchronization +| Server calendar should display an anniversary event on 14/02/2007 and future years (2008, 2009 etc.) + +The repeat pattern should remain unbounded + +Level 0 server: Test cannot be performed + +Level 1 & 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img34.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.35 Create Yearly Repeat (every year for 5 years, bounded) +| Verify that yearly events can be synchronized +| Create an event with a yearly repeat on 1^st^ April 2007 for five years + +Perform a synchronization +| Server calendar should display an event on the following dates: + +01/04/2007, + +01/04/2008, + +01/04/2009, + +01/04/2010, + +01/04/2011 + +Level 0 server: Test cannot be performed + +Level 1 & 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img35.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.36 Create Yearly Repeat (every 4 years, bounded) +| Verify that yearly events can be synchronized + +[example] +Leap year occurs every four years on 29^th^ February +| Create an event with a yearly repeat on 29^th^ February 2004 every four years until 01/03/2012 + +Perform a synchronization +| Server calendar should display an event on the following dates: + +29/02/2004, + +29/02/2008, + +29/02/2012 + +Level 0 server: Test cannot be performed + +Level 1 & 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img36.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.37 Create custom repeat (`RDATES` only) + +_Optional test - Mobile UI may not allow creation of this type of repeat_ +| Verify that custom repeat can be synchronized + +[example,source=miniop] +Dates for a lecture series: Tuesday this week, Wednesday next week, & Friday the following week. +| Create custom repeat pattern Tuesday 1^st^ May 2007, Wednesday 9^th^ May 2007, Friday 18^th^ May 2007 + +Perform a synchronization +| Server calendar should display the event on the following dates: + +01/05/2007, + +09/05/2007, + +18/05/2007 + +Level 0 & 1 server: Test cannot be performed + +Level 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img37.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.38 Create repeat combination + +_Optional test - Mobile UI may not allow creation of this type of repeat +| Verify that combinations of repeat patterns can be synchronized + +[example] +Daylight Saving Time starts on second Sunday in March in 2007 +| Create appointment with a repeat combination, for example: Second Sunday in March every year (`RRULE:FREQ=YEARLY; BYMONTH=3; BYDAY=2SU`) + +Perform a synchronization +| Server calendar displays event on 2^nd^ Sunday of March (11^th^ March 2007) + +The repeat pattern should remain unbounded + +Level 0 & 1 server: Test cannot be performed + +Level 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img38.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.39 Create repeating event plus custom repeat (`RRULE` + `RDATE`) + +_Optional test - Mobile UI may not allow creation of this type of repeat_ +| Verify that more complex repeat patterns can be synchronized + +[example] +Weekly meeting with an extra meeting this week +| Create a weekly repeating meeting (every Monday starting 5^th^ May 2007) and add an additional `RDATE` on Wed 7^th^ May + +Perform a synchronization +| Server calendar displays weekly repeat every Monday starting 5^th^ May 2007 and an additional meeting occurrence on 7^th^ May with the same event description + +Level 0 & 1 server: Test cannot be performed + +Level 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img39.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.40 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) + +_Optional test - Mobile UI may not allow creation of this type of repeat_ +| Verify repeating meetings with exceptions can be synchronized + +[example] +Daily repeating meeting except for Wednesday +| Create a daily repeating meeting starting 30^th^ April 2007 until Friday 4^th^ May 2007. + +Create meeting exception on Wednesday 2^nd^ May (i.e. cancel meeting) +| Server calendar displays daily repeat between 30/04/07 and 04/05/07 with no meeting on 02/05/07 + +Level 0 & 1 server: Test cannot be performed + +Level 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img40.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.41 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) + +_Optional test - Mobile UI may not allow creation of this type of repeat_ +| Verify that more complex repeat patterns can be synchronized +| Create custom repeat pattern + +Perform a synchronization +| Server calendar correctly displays repeating pattern + +Level 0 & 1 server: Test cannot be performed + +Level 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img41.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.42 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) + +_Optional test - Mobile UI may not allow creation of this type of repeat_ +| Verify that more complex repeat patterns can be synchronized +| Create custom repeat pattern + +Perform a synchronization +| Server calendar correctly displays repeating pattern + +Level 0 & 1 server: Test cannot be performed + +Level 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img42.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.43 Modify anniversary +| Verify that modification of meeting details does not cause server representation to become non-repeating +| Create anniversary event on 4^th^ July 2007 on server + +Perform a synchronization + +Modify subject of event on device + +Perform a synchronization +| Server calendar correctly displays anniversary event on 04/07/07 + +Device modification of event subject is correctly synchronized to server + +Level 0 server: Test cannot be performed + +Level 1 & 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img43.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.44 Modify occurrences of repeating meeting +| Verify that modification of the repeat rule is correctly synchronized to the server +| Create daily repeating meeting starting on 1^st^ May 2007 until 5^th^ May (5 occurrences) + +Perform a synchronization + +Cancel occurrence on 4^th^ May & 5^th^ May (select this and future instances when deleting) from device + +Perform a synchronization +| Server calendar displays repeating meeting 1-5^th^ May + +After synchronization, server calendar displays meeting 1-3^rd^ May only + +Level 0 & 1 server: Test cannot be performed + +Level 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img44.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass + +h| 3.45 Delete recurring meeting +| Verify deletion of recurring meeting is correctly synchronized to the server +| Create recurring meeting on server + +Perform a synchronization + +Delete recurring meeting from device + +Perform a synchronization +| Server calendar displays recurring meeting + +After synchronization, server calendar no longer displays recurring meeting + +Level 0 & 1 server: Test cannot be performed + +Level 2 server: Appointment should be shown as a single recurrence set (e.g. an icon may be shown to indicate the appointment is recurring) + +[%unnumbered] +image::img45.png[] + +[%key] +X:: Test can't be performed +✓:: Test should pass +|=== + +=== Scheduling + +The following set of tests verifies that basic scheduling of events can be accomplished. In +particular they attempt to verify the following: + +* that attendee information can be correctly displayed on a mobile device. +* that users invited to a meeting can accept or decline invitations from their mobile device. +* that users can initiate invitations from their mobile device. + +NOTE: <> -- Special Information, has additional information on Scheduling. + +NOTE: All tests should be performed in succession. + +NOTE: In order to perform these tests the mobile device must be able to support the concept of +attendees. + +[%unnumbered,cols="a,a,a,a",options=header] +|=== +| Test ID | Objective | Procedure | Expected Result +h| 4.1 Create Entry as owner with Attendees from Server +| Verify that basic synchronize with attendees work. +| As the owner, from the server, create a meeting and a day event, each with the owner and 2 attendees. + +Perform a synchronization + +As the owner, from the server, add 1 more attendees to each entry and remove an attendee. As the original remaining attendee update your attendance status server side. + +Perform a synchronization +| The two entries should display on the device with all attendees and the appropriate reply status. + +After adding and removing attendees and syncing, the new attendees should be reflected on the device as well as the updated attendance status for the original remaining attendee. + +h| 4.2 Accept Entry as Invitee from Device +| Verify that modifying the reply status of an invitation is reflected on the server. +| As another user, from the server, create a meeting and invite the mobile device user as well as one other user. + +Perform a synchronization + +From the device accept the invitation, server side update the attendance status for the other invite. + +Perform a synchronization +| After the first synchronization, the meeting invitation should display on the device with all attendees displayed. + +After the second synchronization, the updated acceptance of the invitation should be evident server side as well as on the device. The updated attendance status of the other invitee should also display on the device. + +h| 4.3 Create Entry as owner with Attendees from Device +| Verify that device initiated invitations work. +| From the device, create a meeting and a day event, each with the owner and 2 attendees. + +Perform a synchronization + +Server-side have the attendees accept and/or decline the invitations. + +Perform a synchronization +| The two entries should display on the server with all attendees and the appropriate reply status. All attendees should receive invitations. + +After the second synchronization, the updated attendee status of the invitees should be evident device side. +|=== + +=== Time Zones and Daylight Savings + +The following set of tests verifies that events can be passed back and forth regardless of differing +timezones and changes to or from daylight savings. In particular they attempt to verify the +following: + +* that events (simple and repeating) are displayed correctly regardless of whether or not +the server and mobile device are set to the same timezone and that any change to the +timezone on either side will not effect the events in any way. +* that when a synchronization date range spans over a change from daylight savings to +standard time (or vice versa) that events (simple and repeating) on either side of the +change are still displayed correctly and that when the current time actually does move +into the new time setting there is no adverse effects. + + +NOTE: <> -- Special Information, has additional information on time zones and daylight +savings. + +NOTE: All tests should be performed in succession. + +NOTE: In order to perform the daylight savings tests, you must be able to synchronize across +that period of time. + +[%unnumbered,cols="a,a,a,a",options=header] +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 5.1 Time Zones and Simple Meetings +| Verify that simple meetings can be passed back and forth regardless of what time zone setting is in place on either side. +| Make sure the current time zone on the server and the device matches. + +From the server, create a meeting that starts at 10am. + +Perform a synchronization + +Change the time zone on the device to a different time zone 3 hours later. + +Create a new meeting starting at 10am from the server. + +Perform a synchronization + +Change the time zone of the server to match the new time zone. + +Modify the title of one of the meetings. + +Perform a synchronization + +Repeat tests starting with device and server in opposite time zones. + +Repeat tests with the server side meetings being created by another person inviting the owner of the mobile device where by the organizer is in a completely different time zone then those being used in the test. +| The meeting should first display on the device at the correct time, 10am. + +After changing time zones, the device should automatically change the times for all entries. The first meeting should now be displayed at 7am on the device. + +After creating the second meeting and synchronizing, the server is still on the old time zone, so the times will differ. On the device, the first meeting is at 7am and the second at 10am, but on the server, the first meeting is at 10am, and the second at 1pm. + +After changing the time zone on the server and making modifications, both the device and server should display the first meeting at 7am and the second meeting at 10am. + +When tests are repeated the appropriate offsets should be seen but everything should still be where it is intended. + +h| 5.2 Time Zones and Repeating Meetings +| Verify that repeating meetings can be passed back and forth regardless of what time zone setting is in place on either side. +| Make sure the current time zone on the server and the device matches. + +From the server, create a repeating weekly meeting that starts at 10am. + +Perform a synchronization + +Change the time zone on the device to a different time zone 3 hours later. + +Create a new repeating weekly meeting starting at 10am from the server. + +Perform a synchronization + +Change the time zone of the server to match the new time zone. + +Modify the title of one of the meetings. + +Perform a synchronization + +Repeat tests starting with device and server in opposite time zones. + +Repeat tests with the server side meetings being created by another person inviting the owner of the mobile device where by the organizer is in a completely different time zone then those being used in the test. +| The meetings should first display on the device at the correct time, 10am. + +After changing time zones, the device should automatically change the times for all entries. The meetings should now be displayed at 7am on the device. + +After creating the second meeting and synchronizing, the server is still on the old time zone, so the times will differ. On the device, the first meetings are at 7am and the second ones at 10am, but on the server, they are at 10am and at 1pm respectively. + +After changing the time zone on the server and making modifications, both the device and server should display the first set of meetings at 7am and the second set of meetings at 10am. + +When tests are repeated the appropriate offsets should be seen but everything should still be where it is intended. + +h| 5.3 Time Zones and All-Day Events +| Verify that day events can be passed back and forth regardless of what time zone setting is in place on either side. +| Make sure the current time zone on the server and the device matches. + +From the server, create a Day Event filling out all fields. + +Perform a synchronization + +Change the time zone on the device to a different time zone 3 hours earlier. + +Modify the title of the Day Event from the device. + +Perform a synchronization + +Change the time zone of the server to match the new time zone. + +Modify the title of the Day Event from the server. + +Perform a synchronization + +Repeat tests starting with device and server in opposite time zones. + +Repeat tests with the server side meetings being created by another person inviting the owner of the mobile device where by the organizer is in a completely different time zone then those being used in the test. +| The Day Event should first display on the device. The Day Event should be displayed on the correct day on the device. + +After changing the time zone on the device, the device should automatically change the times for all the entries. After modifying and syncing, the Day Event, the Day Event should still be displayed on the same date with the new title on both server and device. + +After changing the time zone on the server, the Day Event should still be displayed on the same day with the new title on the device. + +Day Events are independent of time zone changes. + +When tests are repeated Day Events should continue to be seen as independent of differing time zones. + +h| 5.4 Spring Daylight Savings Single Entries from Server +| Verify that entries originating form the server before and after a switch remain displayed correctly to users. +| Make sure you modify the synchronization range to include the daylight savings period you are about to test. + +From the Server, create a single entry before and another single entry after the Spring daylight savings date at 10am, with all fields filled out. + +Perform a synchronization + +Push the time on the server and the device ahead to simulate crossing into daylight savings. + +Create a new meeting server side at 10am + +Perform a synchronization + +Repeat tests with the server side meetings being created by another person inviting the owner of the mobile device where by the organizer is in a completely different time zone then those being used in the test which has a different date for DST changes. +| The two entries should display on the device with all fields correctly mapped. + +The time of the two entries should be at 10am. + +After the time change the time of the two original entries and the new entry should still be at 10am + +When tests are repeated meetings between when the organizer's Time zone switch to DST and when the invitee's Time zone switches should be offset by an hour (e.g. A 10am London meeting will normally be a 5am Montreal meeting but it will be at 6am after the province of Quebec switches to DST up until the point where British Summer Time kicks in at which point it will go back to being at 5am). + +h| 5.5 Spring Daylight Savings Repeating Entry from Server +| Verify that repeating entries originating form the server before and after a switch remain displayed correctly to users. +| Make sure you modify the synchronization range to include the daylight savings period you are about to test. + +From the Server, create a repeating daily entry that starts at 10am, with all fields filled out, which spans across a Spring daylight savings date + +Perform a synchronization + +Repeat tests with the server side meetings being created by another person inviting the owner of the mobile device where by the organizer is in a completely different time zone then those being used in the test which has a different date for DST changes. +| All instances of the repeating entry should display on the device. + +The times of *ALL* instances before and after the daylight savings date should be 10am. + +When tests are repeated meetings between when the organizer's Time zone switch to DST and when the invitee's Time zone switches should be offset by an hour (e.g. A 10am London meeting will normally be a 5am Montreal meeting but it will be at 6am after the province of Quebec switches to DST up until the point where British Summer Time kicks in at which point it will go back to being at 5am). + +h| 5.6 Autumn Daylight Savings Single Entries from Device +| Verify that entries originating for the device before and after a switch remain displayed correctly to users. +| Make sure you modify the synchronization range to include the daylight savings period you are about to test. + +From the device, create a single entry before and another single entry after the Autumn daylight savings date at 10am, with all fields filled out. + +Perform a synchronization + +Push the time on the server and the device ahead to simulate crossing into daylight savings. + +Create a new meeting device side at 10am + +Perform a synchronization +| The two entries should display on the server with all fields correctly mapped. + +The time of the two entries should be at 10am. + +After the time change the time of the two original entries and the new entry should still be at 10am + +h| 5.7 Autumn Daylight Savings Recurring Entry from Device +| Verify that repeating entries originating form the device before and after a switch remain displayed correctly to users. +| Make sure you modify the synchronization range to include the daylight savings period you are about to test. + +From the device, create a repeating daily entry that starts at 10am, with all fields filled out, which spans across an Autumn daylight savings date. + +Perform a synchronization +| All instances of the repeating entry should display on the Server. + +The times of *ALL* instances before and after the daylight savings date should be 10am +|=== + +== Part II - Task Tests + +The following set of tests verifies that basic mobile task management can be accomplished. In +particular they attempt to verify the following: + +* that Tasks can be created, modified, and deleted on the device or server +* that Task Access Levels and Priorities can be correctly mapped +* that Task reminders can be correctly mapped +* that Tasks can be marked as completed and have this fact reflected on either side +* that special characters and multi byte characters can be correctly handled + +NOTE: <> -- Special Information, has additional information on Mapping, Reminders, +Special Characters, Multi Byte Characters, and Task Completion. + +NOTE: All tests should be performed in succession. + +[cols="a,a,a,a",options=header] +.Server to Device +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 6.1 Create task +| Verify that basic task information can be synchronized +| Create a task on the server + +Complete all fields with maximum input. + +Perform a synchronization + +Modify the task on the device. + +Perform a synchronization + +Modify the task on the server + +Perform a synchronization +| The task should be synchronized to the device with server fields correctly mapped to the corresponding supported fields on the device. + +After second synchronization device modification should be propagated to the server. Any truncation that occurred device side should not affect the server. + +After third synchronization server modification should be reflected on the device. +h| 6.2 Task Access Level and Priority +| Verify that access level and priority values in tasks correctly synchronize to the device. + +Verify that any form of mapping that occurs does not have adverse effects +| From the Server, create a task with default access and priority (e.g. Normal/Medium). + +Perform a synchronization + +From the device, modify the event. + +Perform a synchronization + +Repeat making sure to test all supported access level and priorities. +| The task should display on the device with the access level and priority appropriately mapped if needed. + +After making modifications and synchronizing, the changes should display on the server as well. There should be no evidence of any change server-side to the access level or priority if not actually part of the modification done + +h| 6.3 Create task with alarm +| Verify that task reminders can be synchronized +| Create a task on the server + +Complete title, due date, priority, and access/privacy fields. + +Set category for task (if supported) + +Set an alarm reminder for both the start date and the due date. + +Perform a synchronization +| The task should be synchronized to the device with all fields correctly mapped to the corresponding fields on the device. + +An appropriate mapping of the server side reminders should be present on the devices. + +h| 6.4 Mark task as completed +| Verify that task completion can be synchronized +| Create a task on the server + +Complete title, due date, priority and access/privacy fields + +Perform a synchronization + +Set task as complete on server + +Perform a synchronization +| The task should be synchronized to the device, with all fields correctly mapped. + +After second synchronization, task should be marked as complete on the device + +h| 6.5 Special Characters From Server +| Verify that special characters in tasks correctly synchronize to the device. +| From the Server, create a task filling out all fields with special characters. + +Perform a synchronization + +From the device, modify the task. + +Perform a synchronization +| The task should display on the device with all fields on the server correctly mapped to corresponding fields on the device. All special characters should correctly display on the device as it is displayed on the server. + +After modifying the task, the characters should remain correctly displayed on both the device and server and the changes made on the device should be reflected on the server + +h| 6.6 Multi-Byte Characters From Server +| Verify that multi-byte characters in tasks correctly synchronize to the device. +| From the server, create a task filling out all fields with multi-byte characters. + +Perform a synchronization + +From the device modify the event. + +Perform a synchronization +| The task should display on the device with all multi-byte characters correctly displayed. + +After modifying the task, the multi-byte characters should remain correctly displayed on both the device and server, and the changes made on the device should be reflected on the server. + +h| 6.7 Deletion +| Verify that tasks deleted server side are deleted on the device +| From the server delete all tasks created in previous tests. + +Perform a synchronization +| The deleted tasks should be deleted off of the device as well. +|=== + +[cols="a,a,a,a",options=header] +.Device to Server +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 6.8 Create task +| Verify that basic task information can be synchronized +| Create a task on the device + +Complete all fields with maximum input. + +Perform a synchronization + +Modify the task on the device + +Perform a synchronization +| The task should be synchronized to the server with fields correctly mapped to the corresponding supported fields on the server. + +After second synchronization device modification should be reflected on the server. + +h| 6.9 Task Access Level and Priority +| Verify that access level and priority values in tasks correctly synchronize to the server. +| From the device, create a task with default access and priority (e.g. Normal/Medium). + +Perform a synchronization + +Repeat making sure to test all supported access level and priorities. +| The task should display on the server with the access level and priority appropriately mapped if needed. + +h| 6.10 Create task with alarm +| Verify that task reminders can be synchronized +| Create a task on the device + +Set an alarm reminder (as allowed by the device). + +Perform a synchronization +| The task should be synchronized to the device with all fields correctly mapped to the corresponding fields on the device. + +An appropriate mapping of the device side reminder(s) should be present on the server. + +h| 6.11 Mark task as completed +| Verify that task completion can be synchronized +| Create a task on the device + +Complete title, due date, priority and access/privacy fields + +Perform a synchronization + +Set task as complete on device + +Perform a synchronization +| The task should be synchronized to the server, with all fields correctly mapped. + +After second synchronization, task should be marked as complete on the server + +h| 6.12 Special Characters From Device +| Verify that special characters in tasks correctly synchronize to the server. +| From the device, create a task filling out all fields with special characters. + +Perform a synchronization + +From the server, modify the task. + +Perform a synchronization +| The task should display on the server with all fields on the device correctly mapped to corresponding fields on the server. All special characters should correctly display on the server as it is displayed on the device. + +After modifying the task, the characters should remain correctly displayed on both the device and server and the changes made on the server should be reflected on the device + +h| 6.13 Multi-Byte Characters From Device +| Verify that multi-byte characters in tasks correctly synchronize to the server. +| From the device, create a task filling out all fields with multi-byte characters. + +Perform a synchronization + +From the server modify the event. + +Perform a synchronization +| The task should display on the server with all multi-byte characters correctly displayed. + +After modifying the task, the multi-byte characters should remain correctly displayed on both the device and server, and the changes made on the server should be reflected on the device. + +h| 6.14 Deletion +| Verify that tasks deleted device side are deleted on the device +| From the device delete all tasks created in previous tests. + +Perform a synchronization +| The deleted tasks should be deleted off of the server as well. +|=== + +== Part III - Contact Tests + +=== Contacts + +The following set of tests verifies that basic synchronization of contact information can be +accomplished. In particular they attempt to verify the following: + +* that Contacts can be created, modified, and deleted on the device or server and that +appropriate mappings are maintained to verify that there is no corruption or loss of data. +* that special characters and multi byte characters can be correctly handled + +NOTE: <> -- Special Information, has additional information on Mapping, Special +Characters, and Multi Byte Characters. + +NOTE: All tests should be performed in succession. + +[%unnumbered,options=header,cols="a,a,a,a"] +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 7.1 Create new contact with minimal fields from the server +| To verify that the fields that are already supported for a device are correctly transferred from server to device upon creation and from device to server upon modification. +| Create a new contact entry from the server with all fields (except for addresses, emails, telephone numbers, and URLs) + +Perform a synchronization + +Modify it from the device, and then synchronize again. +| The address book entry created on the server should be reflected on the device with an appropriate mapping of fields taking advantage of what the device supports. + +After modifying the entry and synchronizing, the modified entry is similar on both the device and server. + +The mappings used to send data to the devices should be the same on data returning to the server so that the expected fields are modified. + +h| 7.2 Create new contact with minimal fields from the device +| To verify that the fields that are already supported for a device are correctly transferred from device to server upon creation and from device to server upon modification. +| Create a new contact entry from the device with all fields filled out (except for addresses, emails, telephone numbers, and URLs) + +Perform a synchronization + +Modify it from the server, and then synchronize again. +| The address book entry created on the device should be reflected on the server with an appropriate mapping of fields taking advantage of what the server supports + +After modifying the entry and synchronizing, the modified entry is similar on both the device and server. + +The mappings used to send data to the server should be the same on data returning to the device so that the expected fields are modified. + +h| 7.3 Special Characters +| Verify that special characters in contacts correctly synchronize to and from the device. +| From the Server, create a contact filling out all text fields with special characters. + +Perform a synchronization + +From the device modify the contact. + +Perform a synchronization + +Repeat creating contact on device and modifying on the server. +| The contact should display on the device with all fields on the server correctly mapped to corresponding fields on the device. All special characters should correctly display on the device as it is displayed on the server. + +After modifying the contact, the characters should remain correctly displayed on both the device and server and the changes made on the device should be reflected on the server + +h| 7.4 Multi-Byte Characters +| Verify that multi-byte characters in contacts correctly synchronize to and from the device. +| From the server, create a contact filling out all text fields with multi-byte characters. + +Perform a synchronization + +From the device modify the contact + +Perform a synchronization + +Repeat creating contact on device and modifying on the server. +| The contact should display on the device with all multi-byte characters correctly displayed. + +After modifying the contact, the multi-byte characters should remain correctly displayed on both the device and server, and the changes made on the device should be reflected on the server. + +h| 7.5 Delete a contact from the server +| To verify that when a contact is deleted on the server, it is also deleted on the device. +| From the server, delete an existing contact entry and synchronize. +| The corresponding address book entry is removed from the device. + +h| 7.6 Delete a contact from the device +| To verify that when a contact is deleted on the device, it is also deleted on the server. +| From the device, delete an existing contact entry and synchronize +| The corresponding address book entry is removed from the server. +|=== + +=== Addresses + +The following set of tests target specifically the ability to synchronize addresses. In particular they +attempt to verify the following: + +* that multiple addresses can be handled. +* that address formatting is correctly maintained + +NOTE: <> -- Special Information, has additional information on Addresses. + +NOTE: All tests should be performed in succession. + +[%unnumbered,cols="a,a,a,a",options=header] +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 8.1 Create new contact with addresses from the server +| To verify that the address fields that are supported for a device are correctly transferred from server to device upon creation, modification and deletion. +| Create a contact with several addresses (home, business, etc...) from the server + +Perform a synchronization + +Modify the contact from device changing one of the addresses. + +From the server, delete the first address property and add a new address property + +Perform a synchronization + +Modify the new address property from the server. + +Perform a synchronization. +| The contact should display on the device and address types supported by the device should be available and formatted in a way that is usable to the user. + +The modification made on the device should be reflected on the server but any server side formatting of the address should be maintained and other address (not supported on the device) should remain unaffected. + +The device side address affected by the server side changes should be correctly updated and the correct ordering should be maintained. + +Last modification should update the corresponding address on the device. + +h| 8.2 Create new contact with addresses from the device +| To verify that the address fields that are supported for a device are correctly transferred from device to server upon creation, modification and deletion. +| Create a contact with several addresses (home, business, etc...) from the device (if the device supports it). + +Perform a synchronization + +Modify the contact from server changing one of the addresses. + +From the device, delete the first address property and add a new address property + +Perform a synchronization + +Modify the new address property from the device. + +Perform a synchronization. +| The contact should display on the server and address types entered on the device should be correctly mapped, available, and formatted in a way that is usable to the user on the server. + +The modification made on the server should be reflected on the device but any device side formatting of the address should be maintained. + +The device side changes should get correctly reflected server side with the ordering correctly maintained. + +Last modification should update the corresponding address on the server. +|=== + +=== Phone Numbers + +The following set of tests target specifically the ability to synchronize phone numbers. In particular +they attempt to verify the following: + +* that multiple phone numbers can be handled. +* that phone number formatting is correctly maintained + +NOTE: <> -- Special Information, has additional information on Phone Numbers. + +NOTE: All tests should be performed in succession. + +[%unnumbered,cols="a,a,a,a",options=header] +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 9.1 Create new contact with telephone numbers from the server +| To verify that the telephone fields that are supported for a device are correctly transferred from server to device upon creation, modification and deletion. +| Create a contact with several phone numbers (home1, home2, business, etc...) from the server. + +Perform a synchronization + +Modify the contact from device changing one of the phone numbers. + +From the server, delete the first phone number and add a new phone number + +Perform a synchronization + +Modify the new phone number from the server. + +Perform a synchronization +| The contact should display on the device and the phone numbers supported by the device should be available and formatted in a way that is usable to the user. + +The modification made on the device should be reflected on the server but any server side formatting of the phone number should be maintained and other phone numbers (not supported on the device) should remain unaffected. + +The device side phone numbers affected by the server side changes should be correctly updated and the correct ordering should be maintained. + +Last modification should update the corresponding phone number on the device. + +h| 9.2 Create new contact with telephone numbers from the device +| To verify that the telephone fields that are supported for a device are correctly transferred from device to server upon creation, modification and deletion. +| Create a contact with several phone numbers (home1, home2, business, etc...) from the device (if the device supports it). + +Perform a synchronization + +Modify the contact from server changing one of the phone numbers. + +From the device, delete the first phone number and add a new phone number + +Perform a synchronization + +Modify the new phone number from the device. + +Perform a synchronization +| The contact should display on the server and phone numbers entered on the device should be correctly mapped, available, and formatted in a way that is usable to the user on the server. + +The modification made on the server should be reflected on the device but any device side formatting of the phone number should be maintained. + +The device side changes should get correctly reflected server side with the ordering correctly maintained. + +Last modification should update the corresponding phone number on the server. +|=== + +=== Emails and URLs + +The following set of tests target specifically the ability to synchronize emails addresses and +URLs. + +[%unnumbered,options=header,cols="a,a,a,a"] +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 10.1 Create new contact with emails from the server +| To verify that the email fields that are supported for a device are correctly transferred from server to device upon creation, modification and deletion. +| Create a contact with several email addresses (home1, home2, business, etc...) from the server. + +Perform a synchronization + +Modify the contact from device changing one of the email addresses. + +From the server, delete the first email address and add a new email address + +Perform a synchronization + +Modify the new email address from the server. + +Perform a synchronization +| The contact should display on the device and the email addresses supported by the device should be available and formatted in a way that is usable to the user. + +The modification made on the device should be reflected on the server but other email addresses (not supported on the device) should remain unaffected. + +The device side email addresses affected by the server side changes should be correctly updated and the correct ordering should be maintained. + +Last modification should update the corresponding email address on the device. + +h| 10.2 Create new contact with URLs/web page addresses from the server. +| To verify that the URL fields that are supported for a device are correctly transferred from server to device upon creation, modification and deletion. +| Create a contact with several web page URLs (work web site, home web site, etc...) from the server. + +Perform a synchronization + +Modify the contact from device changing one of the web page URLs + +From the server, delete the first URL and add a new URL + +Perform a synchronization + +Modify the new URL from the server. + +Perform a synchronization +| The contact should display on the device and the URLs supported by the device should be available and formatted in a way that is usable to the user. + +The modification made on the device should be reflected on the server but other URLs (not supported on the device) should remain unaffected. + +The device side URLs affected by the server side changes should be correctly updated and the correct ordering should be maintained. + +Last modification should update the corresponding URL on the device. + +h| 10.3 Create new contact with emails from the device +| To verify that the email fields that are supported for a device are correctly transferred from device to server upon creation, modification and deletion. +| Create a contact with several email addresses (home1, home2, business, etc...) from the device. + +Perform a synchronization + +Modify the contact from the server changing one of the email addresses. + +From the device, delete the first email address and add a new email address + +Perform a synchronization + +Modify the new email address from the device. + +Perform a synchronization +| The contact should display on the server and email addresses entered on the device should be correctly mapped, available, and formatted in a way that is usable to the user on the server. + +The modification made on the server should be reflected on the device. + +The device side changes should get correctly reflected server side with the ordering correctly maintained. + +Last modification should update the corresponding email address on the server + +h| 10.4 Create new contact with URLs/web page addresses from the device +| To verify that the URL fields that are supported for a device are correctly transferred from device to server upon creation, modification and deletion. +| Create a contact with several web page URLs (work web site, home web site, etc...) from the device. + +Perform a synchronization + +Modify the contact from server changing one of the web page URLs + +From the device, delete the first URL and add a new URL + +Perform a synchronization + +Modify the new URL from the device. + +Perform a synchronization +| The contact should display on the server and URLs entered on the device should be correctly mapped, available, and formatted in a way that is usable to the user on the server. + +The modification made on the server should be reflected on the device. + +The device side changes should get correctly reflected server side with the ordering correctly maintained. + +Last modification should update the corresponding URL on the server +|=== + +[[appendix-A]] +[appendix] +== Supporting Information + +=== Truncation + +In an ideal scenario all servers and all mobile devices would store their calendar data as +iCalendar and they would support all attributes that iCalendar supports and would support +attribute values of any length. Given the inherit restrictions of memory and storage prevalent with +most mobile devices this utopian vision however is a rarity. + +More then likely (although this is changing as mobile devices become more and more +sophisticated) the device may only be able to expose a subset of the information possible from +the desktop application and certain attribute values may need to be truncated. This is acceptable +as long as an adequately accurate representation of the event is still available to the calendar +user and if such restrictions do not end up adversely effecting the original server-side +representation. + +[example] +A user creates a meeting with a start time, duration, title, and some details. The +calendar application on the device the user uses can only display start time, duration, and title. If +the user modifies the start time from the device and then synchronizes the details should not be +lost on the server-side representation of the event. + +[example] +A user creates a meeting with a start time, duration, title, and a long description of +the agenda. The calendar application on the device the user uses can display the start time, the +duration, the title, and some details but it is limited to an amount of characters less then the +length of the agenda so the entire agenda cannot be seen by the user from the device. If the user +modifies the start time from the device and then synchronizes the agenda should not get +truncated server-side. + +=== Mapping + +Most iCalendar attribute values are either a string or a date and time and thus there is no real +issues regarding mapping for such values. For access levels and priorities however the values +are based on enumerated lists. The iCalendar specification does describe appropriate values for +these attributes but often desktop calendar client solutions support a much richer set of values +and often mobile devices will support a lesser set (if at all). + +The case where the mobile device simply doesn't support such concepts is fairly easy to support. +Simply don't display them and make sure changes on the device do not affect them server-side +(as described in the section above about truncation). + +It becomes much more complicated when the mobile device does support these attributes but +supports a different set of accepted values. In such cases an appropriate mapping needs to +occur. This is acceptable as long as an adequately accurate representation of the event is still +available to the calendar user and if such mappings do not end up adversely effecting the original +server-side representation. + +[example] +A user creates a meeting with normal access (which is different then public for the +system they use). The calendar application on the device the user uses can only display public or +private so the event is displayed as public. If the user modifies the start time from the device and +then synchronizes the access level should not now be changed to Public on the server-side +representation of the event. It is important that it remains normal. + +[example] +A user creates a public meeting by mistake. Later the user uses the calendar +application on the device to switch it to private. The access level should change on the server as +the user explicitly modified it. + +[example] +A user creates a meeting of highest priority (which is different than high for the +system they use). The calendar application on the device the user uses can only display low, +medium, or high so the event is displayed as high. If the user modifies the start time from the +device and then synchronizes the priority level should not now be changed to high on the server-side +representation of the event. It is important that it remains highest. This issue affects events +and tasks. + +[example] +A user creates a task in their mobile device calendar with a priority of 'Normal' +(iCalendar created by device uses a `PRIORITY` value of 2). The user sends this task via +Bluetooth to their desktop and imports the task to their desktop Calendar application. The desktop +calendar application displays the task as 'Medium'. + +=== Reminders + +Reminders are interesting in that the reminder you may want your desktop calendar client to give +you concerning an event is not necessarily the reminder you'd like your mobile calendar client to +provide. You may want your desktop application to provide you with a popup reminder 15 minutes +before the start of the event and you may want your device to beep and vibrate when the event is +scheduled to actually start. Since they are both the same and yet different the way in which they +get synchronized can sometimes be of interest. + +If a user creates events using their desktop client they certainly don't want to have to manually +create reminders on the events that get sent to their mobile device however if they edit when they +want a desktop reminder or choose to remove a desktop reminder does this really correlate in +any way to the mobile alert? + +As a general rule it makes sense that any new event with a reminder being sent from either side +(device or server) should result in an appropriate default reminder being setup on the other side. + +[example] +A user's desktop calendar client by default sets up events with 15-minute popup +reminders. The calendar application on the device the user uses by default sets up events with +reminders to beep when the meeting is due to start. Events created on either side by the user +result in the same type of expected reminder. + +[example] +A user has a meeting in an hour with a 15-minute popup reminder. Because the user +is currently giving a web conference presentation she does not want the reminder popping up +while she is presenting so she removes the reminder. She still wants to be reminded of her next +call however and is relying on the fact that her mobile phone will beep when it is time. + +[underline]#_BOF Topic_#: _If a reminder is removed on the device (or vice versa) should the reminder be +removed from the event on the server?_ + +Task reminders are also interesting since most desktop calendar applications will allow you to +setup a reminder based on when you should start working on the task or based on the due date +where is most mobile devices either don't support Task reminders or only support one reminder. +Implementations should attempt map task reminders accordingly. + +=== Special Characters + +The following illustrates some of the special characters that can be used to test when dealing with +test cases for special characters: + +Accented Characters:: çèéêëìíîïàáâãäåõöôóòùúûüñý +Euro Sign:: €€€€€ +Numbers:: ½¼ +Omega Characters:: ƒ†‡¶£¤¥§©® +Special Characters:: ~`!@#$%^&()_+=-{}|\][:"';<>?/., +New Line character:: (↵) + +=== Multi-Byte Characters + +Characters from East Asian languages such as Chinese, Japanese and Korean (CJK) cannot be +represented using 8-bit text like many European languages. CJK character sets typically use +multi-byte variable-length encodings such as UTF-8. + +The following illustrates some of the multi-byte characters that can be used to test when dealing +with test cases for multi-byte characters: + +Chinese Characters: + +* U+5317 U+4EAC Beijing + +Japanese Characters: + +* U+3042 Hiragana Letter A +* U+3044 Hiragana Letter I +* U+3046 Hiragana Letter U +* U+3048 Hiragana Letter E +* U+304A Hiragana Letter O + +Korean Characters: + +* U+1100 Latin characters k/g +* U+1105 Latin characters r/l + +Implementations should use UTF-8 encoding form as a default character set as recommended by +iCalendar to guarantee correct display of multi-byte characters (such as CJK languages). +However, mobile devices may wish to use specific character sets for the market the device is +being sold within (e.g. Many Japanese phones use Shift-JIS exclusively). Regardless of the +implementation however users never want to see "%^($%^^^##@???" + +=== All Day Events + +An 'all-day event' is a scheduled activity covering an entire day or a block of days. These types of +events are also known as 'day events' or 'memo' events. + +A common use of all-day events is to represent a vacation and some products support a special +type of all-day event just for holidays. Anniversary events, an annually repeating all-day event, +are also very common provided in Calendar & Scheduling products. + +==== Representation of All-Day Events in vCalendar/iCalendar + +The <> specification, which is widely adopted on mobile devices, does not describe a +standard representation of all day events. + +The OMA data synchronisation group has published a Minimum Interoperability Profile <> +which aims to provide guidance on how to interpret some ambiguous areas of the vCalendar 1.0 +specification. + +It recommends that all-day events should be represented using the same date for `DTSTART` and +`DTEND`, with a time of 00:00:00 for `DTSTART` and 24:00:00 for `DTEND`. 24 hour events that +begin at midnight should be represented using `DTSTART` and `DTEND` time of 00:00:00 and +`DTEND` set to one day after the event. However, a time value of 24:00:00 is illegal syntax in +iCalendar; the valid range for the hour value is 0 through 23. + +The iCalendar specification states that the `DTEND` property is exclusive (i.e. the date specified in +the `DTEND` is not included in the event duration). An event that lasts all day on June 19^th^ 2007 +should be represented as: + +[source%unnumbered] +---- +DTSTART;VALUE=DATE:20070619 +DTEND;VALUE=DATE:20070620 +---- + +Most major Calendar implementations follow this guidance. For example, Microsoft(R) Outlook(R): + +[source%unnumbered] +---- +BEGIN:VCALENDAR +PRODID:-//Microsoft Corporation//Outlook 9.0 MIMEDIR//EN +VERSION:2.0 +METHOD:PUBLISH +BEGIN:VEVENT +ORGANIZER:MAILTO:< omitted > +DTSTART;VALUE=DATE:20070402 +DTEND;VALUE=DATE:20070403 +LOCATION:London office +TRANSP:OPAQUE +SEQUENCE:0 +UID:040000008200E00074C5B7101A82E00800000000E0F088CC1875C7010000000000 + 000000100000008863E35F4A64624397C17A75BF6F4C4A +DTSTAMP:20070402T101937Z +SUMMARY:MS all day event\, time +PRIORITY:5 +CLASS:PUBLIC +END:VEVENT +END:VCALENDAR +---- + +For example, Google(TM): + +[source%unnumbered] +---- +BEGIN:VCALENDAR +PRODID:-//Google Inc//Google Calendar 70.9054//EN +VERSION:2.0 +CALSCALE:GREGORIAN +METHOD:REQUEST +BEGIN:VEVENT +DTSTART;VALUE=DATE:20070404 +DTEND;VALUE=DATE:20070405 +< additional properties omitted for readability > +STATUS:CONFIRMED +SUMMARY:Birthday +TRANSP:TRANSPARENT +END:VEVENT +END:VCALENDAR +---- + +==== Do All Day Events have a duration? + +The biggest issue with day events has always been do they have duration and how should they +be presented using iCalendar? iCalendar certainly is robust enough to support the concept but it +does not explicitly dictate how to represent a day event. + +Christmas is the 25^th^ of December regardless of were you are in the world. It can be represented +as an all day event on the 25^th^. If a user is attending a conference in Hong Kong from Monday to +Friday then for the user's boss in North America the user is actually starting to attend some time +on Sunday. Which is right? + +The reality is that some systems support one way or the other or in some cases both then add +into the mix a mobile device that itself does its own thing and you have a dreadful mess. + +[underline]#_BOF Topic_#: _What form of iCALENDAR should be passed back and forth to ensure these +concepts are correctly handled?_ + +==== Multi-Day Day Events + +Some servers support multi-day All Day events and treat them as entries that spans across a few +days. For devices that support multi-day All day events, the entry will be displayed in the same +manner as it is on the server. + +Unfortunately many devices that support All Day Events do not support them across multiple +days. For such cases the server has to do something appropriate. Refusing to send such day +events is one solution or perhaps the entry is displayed on the device as a one day event, but the +string "~(x)" is appended to the title field, where x is the number of days that entry spans across. +For example: If the device does not support multi-day events, then creating one on the server +with the title "Multi-Day Event" that spans across 5 days will be displayed on the device as a one +day Day Event with the title "Multi-Day Event ~(5)". When testing multi-day day events it is +important to understand what the device can support and what the server does to compensate. + +=== Repeating Events and Recurrence Rules + +Mismatches between mobile device and server-side representations of repeating events are +commonly observed by users of calendar synchronization. Irregular recurrence patterns and +modified instances of a recurrence set are a particular problem. These mismatches can have a +serious impact as they can lead to corruption of a server-side calendar. + +There are two main causes for incorrect synchronization of repeating events -- usage of +vCalendar and a lack of common understanding about recurrence capabilities. Devices often +claim that they can support repeating meetings, but in reality can only support a very small subset +of the repeating capabilities that iCalendar provides for. For example, devices will support deleted +exceptions but not modified exceptions or only support a small subset of recurrence rules. + +To ensure there is a common understanding between the mobile device and the server, the +Calendar & Scheduling Consortium Mobile Technical Committee produced a recommendations +paper [Mobile Recurrence Interoperability Recommendations] to propose three levels of +recurrence support. + +A simplified summary of the levels for mobile devices are: + +. Device provides no support for repeating events +. Device can handle recurrence rules +. Device can handle recurrence rules with exceptions and extra dates + +For devices that don't claim any sort of repeating support (level 0 devices) server-side +implementations should expand all repeating events and send simple single instance events for +all instances within the synchronization range. The fact that the event is repeating should be +maintained server-side and any modification done on the device side should not affect this. This +means that although the meeting is not shown as recurring on the device, the user will not miss +an important meeting because the device has limited capabilities. + +=== Scheduling + +Ideally any mobile calendar solution should allow a mobile user to perform any sort of operation +on their mobile device that they would expect to be able to do from their desktop. Most mobile +calendar clients however are still very PIM centric. Basic mobile scheduling capabilities are +beginning to emerge however. At a minimum mobile devices should be able to display +information about who the attendees of a meeting are, should allow users to accept or decline +invitations from their mobile device, and should allow users to initiate invitations for their mobile +device. + +=== Time Zones and Daylight Savings + +In order to correctly display an event and interoperate with major calendar applications, it is +necessary for mobile calendar solutions to provide support for time zones. Unfortunately, most +mobile calendar solutions do not provide full support for time zones currently and are therefore +unable to correctly display events in all situations. + +The following different classes of device time zone support have been identified: + +Full Time zone support + +* has time zone configuration option +* stores all events as local time, UTC or local time with time zone rule (as appropriate) +* transfers recurring events in local time with a time zone definition +* supports day events independent of time zone changes (aka "floating" time) +* when the time zone is changed on the device, all events shift in the device calendar +(excluding day events) +* switches to and from daylight savings do not effect the display of events + +Type 1 Partial time zone support + +* has time zone configuration option +* stores all events in UTC +* day events are stored as events starting at midnight with no duration +* when the time zone is changed on the device, all events shift, including day events which +initially display at midnight (until the time zone was changed) +the synchronization server requires the user's default calendar server time zone to +correctly synchronize day events to this device (so that they hopefully end up at midnight) + +Type 2 Partial time zone support + +* has time zone configuration option +* accepts UTC, but actually stores them in local time +* supports day events independent of time zone changes +* when the time zone is changed on the device, events are not shifted in the device +calendar + +No Timezone support + +* the device may have an option for setting the time zone, but the information is not used +by the device calendar application or the synchronization application +* all events are stored in local time +* day events may or may not be supported correctly +* when the time zone is changed on the device, events are not shifted in the device +calendar + +The timezone and daylight savings test cases described in this test suite assume that full time +zone support has been correctly implemented. Other implementations are simply considered +broken. + +=== Task Completion + +How should a task (to-do) be marked as completed? + +iCalendar defines three properties to indicate that a task is completed. `STATUS` describes the +overall status for the task, `PERCENT-COMPLETE` allows a delegate to communicate the +percentage completion of the task to the organizer and `COMPLETED` indicates the date/time that +the to-do was actually completed. An example of how a completed task can be expressed using +these properties is shown below: + +[source%unnumbered] +---- +STATUS:COMPLETED +PERCENT-COMPLETE:100 +COMPLETED:20070101T100000Z +---- + +Unfortunately, iCalendar does not prescribe a single way to mark a task as completed. Device-side +clients may support any combination of these properties. A server must be able to send a +device a completed task using the format it is expecting and be able to recognize how a device +client indicates a completed task. + +=== Contact Mappings + +vCard as a data format supports an endless number of combinations. This makes it very difficult +to guarantee that both sides can support each others representations. Despite its flexibility +however it does not support a way to enumerate multiple properties of the same type. + +=== Addresses + +Address formats differ greatly from country to country. When an address is represented as just a +text field it is easy to pass back and forth but often servers will store address information in +separate fields (e.g. Street, City, Country, Postal Code) therefore when working with a device that +expects things all in one label this information must be merged together. If it is then modified on +the device it is important that server side the representation remains intact. +Address formatting for majority of Asian countries will typically require more than one address +field. Some software implementation allows for two fields (e.g. Address1 and Address2) to allow +the extra information to be entered and rendered where as others provide a single Address field. +It may be helpful to provide guidelines on how to handle these occurrences which are extremely +common for Asian addresses. + +[example] +==== +The Yamasa Institute + +Address 1: 1-2-1 Hanehigashi-machi + +Address 2: AichiPrefecture + +City: OkazakiCity + +Country: JAPAN + +Zip Code: 444-0832 +==== + +[example] +==== +Samsung Seoul (Head Office) + +Address 1: SAMSUNGMainBuilding + +Address 2: 250-2 ga,Taepyung-roChung-gu + +City: Seoul + +Country: Korea +==== + +=== Phone numbers + +13336669999, +13336669999, 1 (333) 666-999, all of these are valid and some servers store the +country code, area code, and actual number separately. + +While this format generally works, there are instances where simple concatenation of country +code, area code, and actual number may not work correctly. For instance, a phone number in +Tokyo, Japan(e.g. 03-3580-3377) may not be dialled correctly by using +810335803377. The +area code (03) must be translated to (3) so that the mobile device omits the extra (0) and dials ++81335803377. These types of area codes are quite common for many Asian countries. It would +be ideal if software applications can interpret these type of numbers and automatically convert the +phone numbers accordingly. Also, the display of the phone numbers should be rendered +according to where the end-user is. (e.g. If the user is in Japan, the number 03-3580-3377 should +be used, but if the user is outside of Japan +81335803377 should be displayed). + +[[appendix-B]] +[appendix] +== Sample iCalendar and vCard Streams + +The Calendaring & Scheduling Consortium plans to collect sample iCalendar and vCard +contributions for each of the Calendar, Task, and Contact test cases. These will be made +available from the Consortium's _CalConnect Interoperability Testing Resources_ page: + +http://www.calconnect.org/ioptesting.shtml + +[[appendix-C]] +[appendix] +== Open Issues & Known Omissions + +There are currently no test cases defined for the following areas: + +. Calendar test cases do not include attachments +. Day Event test cases are not considered complete. Issues such as time transparency for +all-day events. For example, should all-day events block time (free/busy handling)? Is the +meaning preserved between device & server? A consensus within the industry needs to +be reached before these tests can be considered complete. +. Recurrence tests are not considered complete: Frequencies less than a day (secondly, +minutely, hourly), various until/count/interval combinations, various `BYXXX` repeat +patterns, `WKST`, limited coverage of combinations of repeat patterns, limited coverage of +exception combinations and repeat modification/deletion. If iCalendar test data is +supplied, verify that recurrence property parameters can be specified in any order. A +consensus within the industry on what the minimal level of support should be on a mobile +device is required to complete a concrete set of tests. +. Minimal Alarms/Meeting reminders and the handling of alarms on the device are provided +but a proper consensus on how to have reminders specified that make sense for the +environment they are going off in needs to be reached. +. Tests covering meetings that start, end, or cross over the shift between standard and +daylight savings are not covered. Consensus on what should be the expected behaviour +is needed. +. Various scheduling operations such as delegation, meeting cancellation, and meeting +reschedules are not covered. Once Scheduling capabilities are more prevalent on mobile +devices additional test cases should be added. +. Repeating Tasks or Task Assignments are not covered. When such support becomes +more widespread on mobile devices additional test cases should be added. +. Character Encoding IOP issues. For example: Shift JIS support & confusion with +encoding Yen symbol/backslash characters, base64/quoted printable encodings, line +folding, UTF-8 support + +[bibliography] +== References + +* [[[rfc4791,RFC 4791]]] + +* [[[calgloss,CC/R 1102]]] + +* [[[rfc2445,IETF RFC 2445]]] + +* [[[oma,OMA DS]]], Open Mobile Alliance Data Synchronization V1.1.2, Open Mobile Alliance, 10 July 2006 http://www.openmobilealliance.org/release_program/ds_v12.html + +* [[[miniop, CC/S 0601]]] + +* [[[iop-rec, CC/R 0805]]], Mobile Recurrence Interoperability Recommendations, 29 July 2008 https://www.calconnect.org/pubdocs/CD0805%20Mobile%20Recurrence%20Interoperability%20Recommendations%20V1.0.pdf + +* [[[rfc3283,IETF RFC 3283]]] + +* [[[ical, CC/Adv 0611]]] + +* [[[vcal,vCalendar 1.0]]], vCalendar The Electronic Calendaring and Scheduling Exchange Format Version 1.0, Versit Consortium, September 18 1996 http://www.imc.org/pdi/vcal-10.txt + +* [[[vcard21,vCard 2.1]]], vCard The Electronic Business Card Version 2.1, Versit Consortium, September 18 1996 http://www.imc.org/pdi/vcard-21.txt + +* [[[rfc2426,RFC 2426]]] + +* [[[vobj,vObject]]], OMA vObject Minimum Interoperability Profile Version 1.0, Open Mobile Alliance, 18 January 2005 +http://www.openmobilealliance.org/release_program/vObject_v10.html + +* [[[wiki,hidden(Wikipedia)]]], https://www.wikipedia.org/ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img01.png b/sources/cc-0706-ioptest-suite-v1.1/images/img01.png new file mode 100644 index 0000000..e6dfd52 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img01.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img02.png b/sources/cc-0706-ioptest-suite-v1.1/images/img02.png new file mode 100644 index 0000000..141bd83 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img02.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img03.png b/sources/cc-0706-ioptest-suite-v1.1/images/img03.png new file mode 100644 index 0000000..ecea32a Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img03.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img04.png b/sources/cc-0706-ioptest-suite-v1.1/images/img04.png new file mode 100644 index 0000000..cd953f4 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img04.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img05.png b/sources/cc-0706-ioptest-suite-v1.1/images/img05.png new file mode 100644 index 0000000..25ca815 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img05.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img06.png b/sources/cc-0706-ioptest-suite-v1.1/images/img06.png new file mode 100644 index 0000000..4e9a55c Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img06.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img07.png b/sources/cc-0706-ioptest-suite-v1.1/images/img07.png new file mode 100644 index 0000000..9aebdba Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img07.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img08.png b/sources/cc-0706-ioptest-suite-v1.1/images/img08.png new file mode 100644 index 0000000..27d3a18 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img08.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img09.png b/sources/cc-0706-ioptest-suite-v1.1/images/img09.png new file mode 100644 index 0000000..49d3b14 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img09.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img10.png b/sources/cc-0706-ioptest-suite-v1.1/images/img10.png new file mode 100644 index 0000000..8533651 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img10.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img11.png b/sources/cc-0706-ioptest-suite-v1.1/images/img11.png new file mode 100644 index 0000000..280e3cc Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img11.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img12.png b/sources/cc-0706-ioptest-suite-v1.1/images/img12.png new file mode 100644 index 0000000..270e3eb Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img12.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img13.png b/sources/cc-0706-ioptest-suite-v1.1/images/img13.png new file mode 100644 index 0000000..4405991 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img13.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img14.png b/sources/cc-0706-ioptest-suite-v1.1/images/img14.png new file mode 100644 index 0000000..d35519d Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img14.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img15.png b/sources/cc-0706-ioptest-suite-v1.1/images/img15.png new file mode 100644 index 0000000..55803d3 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img15.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img16.png b/sources/cc-0706-ioptest-suite-v1.1/images/img16.png new file mode 100644 index 0000000..9a385bf Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img16.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img17.png b/sources/cc-0706-ioptest-suite-v1.1/images/img17.png new file mode 100644 index 0000000..54a63d4 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img17.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img18.png b/sources/cc-0706-ioptest-suite-v1.1/images/img18.png new file mode 100644 index 0000000..aa41ebc Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img18.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img19.png b/sources/cc-0706-ioptest-suite-v1.1/images/img19.png new file mode 100644 index 0000000..fc79fd5 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img19.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img20.png b/sources/cc-0706-ioptest-suite-v1.1/images/img20.png new file mode 100644 index 0000000..b36d673 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img20.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img21.png b/sources/cc-0706-ioptest-suite-v1.1/images/img21.png new file mode 100644 index 0000000..ada4f43 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img21.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img22.png b/sources/cc-0706-ioptest-suite-v1.1/images/img22.png new file mode 100644 index 0000000..2dbcf34 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img22.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img23.png b/sources/cc-0706-ioptest-suite-v1.1/images/img23.png new file mode 100644 index 0000000..98f815c Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img23.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img24.png b/sources/cc-0706-ioptest-suite-v1.1/images/img24.png new file mode 100644 index 0000000..3d66a38 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img24.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img25.png b/sources/cc-0706-ioptest-suite-v1.1/images/img25.png new file mode 100644 index 0000000..942c96d Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img25.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img26.png b/sources/cc-0706-ioptest-suite-v1.1/images/img26.png new file mode 100644 index 0000000..0957e22 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img26.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img27.png b/sources/cc-0706-ioptest-suite-v1.1/images/img27.png new file mode 100644 index 0000000..fe3e576 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img27.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img28.png b/sources/cc-0706-ioptest-suite-v1.1/images/img28.png new file mode 100644 index 0000000..e56cac0 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img28.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img29.png b/sources/cc-0706-ioptest-suite-v1.1/images/img29.png new file mode 100644 index 0000000..5035821 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img29.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img30.png b/sources/cc-0706-ioptest-suite-v1.1/images/img30.png new file mode 100644 index 0000000..182117e Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img30.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img31.png b/sources/cc-0706-ioptest-suite-v1.1/images/img31.png new file mode 100644 index 0000000..d3a0158 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img31.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img32.png b/sources/cc-0706-ioptest-suite-v1.1/images/img32.png new file mode 100644 index 0000000..e736a26 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img32.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img33.png b/sources/cc-0706-ioptest-suite-v1.1/images/img33.png new file mode 100644 index 0000000..0fc47b9 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img33.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img34.png b/sources/cc-0706-ioptest-suite-v1.1/images/img34.png new file mode 100644 index 0000000..61c9183 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img34.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img35.png b/sources/cc-0706-ioptest-suite-v1.1/images/img35.png new file mode 100644 index 0000000..68ed44c Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img35.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img36.png b/sources/cc-0706-ioptest-suite-v1.1/images/img36.png new file mode 100644 index 0000000..09062ca Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img36.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img37.png b/sources/cc-0706-ioptest-suite-v1.1/images/img37.png new file mode 100644 index 0000000..0d4a1ea Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img37.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img38.png b/sources/cc-0706-ioptest-suite-v1.1/images/img38.png new file mode 100644 index 0000000..86c2dba Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img38.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img39.png b/sources/cc-0706-ioptest-suite-v1.1/images/img39.png new file mode 100644 index 0000000..c00d955 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img39.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img40.png b/sources/cc-0706-ioptest-suite-v1.1/images/img40.png new file mode 100644 index 0000000..c17b002 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img40.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img41.png b/sources/cc-0706-ioptest-suite-v1.1/images/img41.png new file mode 100644 index 0000000..8fdb611 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img41.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img42.png b/sources/cc-0706-ioptest-suite-v1.1/images/img42.png new file mode 100644 index 0000000..468f522 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img42.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img43.png b/sources/cc-0706-ioptest-suite-v1.1/images/img43.png new file mode 100644 index 0000000..7853ef4 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img43.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img44.png b/sources/cc-0706-ioptest-suite-v1.1/images/img44.png new file mode 100644 index 0000000..219f229 Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img44.png differ diff --git a/sources/cc-0706-ioptest-suite-v1.1/images/img45.png b/sources/cc-0706-ioptest-suite-v1.1/images/img45.png new file mode 100644 index 0000000..bb4b26a Binary files /dev/null and b/sources/cc-0706-ioptest-suite-v1.1/images/img45.png differ diff --git a/sources/cc-0706-ioptest-suite/document.adoc b/sources/cc-0706-ioptest-suite/document.adoc new file mode 100644 index 0000000..93f0e69 --- /dev/null +++ b/sources/cc-0706-ioptest-suite/document.adoc @@ -0,0 +1,2529 @@ += Mobile Calendar Interoperability Test Suite +:docnumber: 0706 +:copyright-year: 2007 +:language: en +:doctype: specification +:edition: 1 +:status: published +:revdate: 2007-08-28 +:published-date: 2007-08-28 +:technical-committee: MOBILE +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Chris Dudding +:affiliation: Symbian Ltd +:role: editor +:fullname_2: Mark Paterson +:role_2: editor +:affiliation_2: Oracle + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +The Mobile Technical Committee of the Calendaring and +Scheduling Consortium created this document. It describes a +test suite to assess a mobile device's capability to synchronize +calendar data with a calendar store. + +== Introduction + +This document describes the test steps required to assess a mobile device's capability to +synchronize calendar data with a calendar store (referred to from now on as "the server"). + +It is provided as a resource for implementers to help promote interoperability, but the successful +execution of the test cases described herein should not be considered as any type of formal +validation. + +The tests described in this document are to be manually executed. Data synchronization sessions +will be initiated between the mobile device under test and the server. A desktop or web based +calendar client should be used to enter and verify data on the server. + +The testing method used will be a black box testing approach, wherein inputs will be provided +from both the server and device and outputs will be generated. Comparisons between the actual +output and the expected output will determine the capability of the device to synchronize calendar +data. + +The test cases have been written with the understanding that some form of synchronization is +occurring, but they make no assumptions concerning the underlying methodology. They can be +used for testing OMA Data Synchronization (formerly SyncML) implementations, cable based +synchronization solutions, or even mobile clients which reconcile a local store using <> (or +their own proprietary protocol). It should also be possible to test direct data transfer between +devices using short link connectivity protocols such as Bluetooth or Infrared with minimal +changes. + +The test cases assume that the underlying data exchange formats used will be <> and +<>. + +It is possible to use these test cases with implementations that use <>, <>, or +some other proprietary format. Arguments supporting the importance of iCalendar to the Mobile +Industry are discussed in the Consortium white paper on +<>. + +The intent of this test suite is to verify the validity of the calendar data that is exchanged and to +guarantee that the calendar user has an accurate representation of their calendar regardless of +which side (mobile device or server) they are viewing it from. + +It does not attempt to go beyond this scope, so it does not include tests for such things as: + +* Conflict Resolution +* Correct protocol usage (e.g. support for OMA DS Server Alerted Notification or +Suspend/Resume) +* Stress tests for a large volume of calendar events +* Stress tests for calendar event content, such as very long `DESCRIPTION` properties (e.g. +copying full text of an email into the calendar description) +* Effects experienced when multiple synchronization technologies are used in parallel (e.g. +duplicate entry problems reported when using Palm HotSync or BlackBerry clients and +OMA DS in conjunction) +* Negative test conditions. In other words, incorrect input data that deliberately generates +errors such as invalid recurrence patterns + +Each group of tests starts with basic test cases to verify that essential calendaring data can be +transferred back and forth accurately. These are followed by tests that focus on aspects that have +been identified as problem areas. + +Some test cases identify problem areas for further discussion at a forthcoming CalConnect Mobile +Interoperability Test Event. These 'Birds of a Feather' discussion items are marked with +'[underline]#_BOF Topic_#' in the text. References to external specifications are shown in the text in square brackets. + +A complete list of limitations and current omissions within this test suite are documented in +<>. + +[heading=terms and definitions,source=calgloss] +== Definitions + +=== Access control + +A mechanism to grant or deny privileges (Create, Read, Update, Delete) on +calendars, events, tasks or journal entries to other calendar users. + +=== Alarm + +A reminder for an event or a to-do. Alarms may be used to define a reminder for a +pending event or an overdue to-do. + +=== 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. + +[.source] +<> + +=== Calendar User +alt:[CU] + +An entity (often a human) that accesses calendar information. + +[.source] +<> + +=== Calendaring + +An application domain that covers systems that allow the interchange, access and +management of calendar data. + +=== CalConnect + +The Calendaring and Scheduling Consortium consisting of vendors and user +groups interested in promoting and improving calendaring and scheduling standards and +interoperability. + +=== Coordinated Universal Time +alt:[UTC] + +An atomic realization of Universal Time (UT) or +Greenwich Mean Time, the astronomical basis for civil time. Time zones around the world are +expressed as positive and negative offsets from UT. UTC differs by an integral number of +seconds from International Atomic Time (TAI), as measured by atomic clocks and a fractional +number of seconds from UT. + +[.source] +<> + +=== Daylight Savings Time +alt:[DST] + +The period of the year in which the local time of a particular time +zone is adjusted forward, most commonly by one hour, to account for the additional hours of +daylight during summer months. + +=== Event + +A calendar object that usually takes up time on an individual calendar. Events are +commonly used to represent meetings, appointments, anniversaries, and day events. + +=== iCalendar + +The Internet Calendaring and Scheduling Core Object Specification. An IETF +standard (RFC 2445) for a text representation of calendar data. + +=== Instance + +When used with recurrences, an instance refers to an item in the set of recurring +items. + +=== Invite + +To request the attendance of someone to a calendar event. + +=== Notification + +. The action of making known, an intimation, a notice. +. Reminder or alarm sent +when any resource or parties interested in the resource need an indicator that some attention is +required. Possible notification methods include email, paging, audible signal at the computer, +visual indicator at the computer, voice mail, telephone. + +=== Organizer + +The originator of a calendar event typically involving more than one attendee. + +=== Priority + +A level of importance and/or urgency calendar users can apply to Tasks and Events. + +=== Recurring + +Happening more than once over a specified interval, such as weekly, monthly, daily, +etc. See {{Repeating}}. + +=== Repeating + +An event that happens more than once. You might want an event to occur on a +regular basis. To do this you schedule a repeating event. Any changes you make to the event can +automatically be made to all occurrences of the event. If necessary, changes can be made to +individual events without affecting the others. For example, if you need to attend a weekly +meeting, you can schedule a repeating event on your calendar. Using another example, if you +want to schedule a five day vacation, schedule an all-day event that repeats daily for a total of +five times. If you have to cancel one of the days, delete the one day without deleting the whole +event. + +=== Reminders + +See {{Notification}}. + +=== Time zone + +Areas of the Earth that have adopted the same local time. Time zones are generally +centered on meridians of a longitude, that is a multiple of stem:[15 "unitsml(deg)"], +thus making neighboring time +zones one hour apart. However, the one hour separation is not universal and the shapes of time +zones can be quite irregular because they usually follow the boundaries of states, countries or +other administrative areas. + +[.source] +<> + +== Abbreviations + +BOF:: Birds of a Feather +CJK:: Chinese, Japanese, Korean languages +GMT:: Greenwich Mean Time +IETF:: Internet Engineering Task Force +IOP:: Interoperability +OMA:: Open Mobile Alliance +OMA:: DS Open Mobile Alliance Data Synchronization (formerly SyncML) +PIM:: Personal Information Management +URL:: Uniform Resource Locator +UTC:: Universal Time Coordinated + +== Part I -- Calendar Tests + +=== Events + +The following set of tests verifies that basic events can be passed back and forth between the +mobile device and the server. They also attempt to verify the following: + +* that events with large amounts of data do not adversely affect the mobile device. +* that any form of truncation that may need to occur on the device does not adversely +effect the representation on the server +* that reminders can be part of the event +* that appropriate mappings are done for access level and priorities +* that special characters and multi-byte characters can be correctly displayed on either +side. + +NOTE: <> -- Special Information, has additional information on truncations, mappings, +reminders, special characters, and multi-byte characters. + +NOTE: All tests should be performed in succession. + +[cols="a,a,a,a",options=header] +.Server to Device +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 1.1 Create an Event with a Reminder +| Verify that basic events synchronize to the device. + +Verify that filling out all fields with long strings does not cause the device issues + +Verify that reminders can be sent +| From the Server, create a simple future event, filling out all fields with maximum input, with a reminder. + +Perform a synchronization + +From the device, modify the event and remove the reminder. + +Perform a synchronization +| The event should display on the device with all fields on the server correctly mapped to corresponding fields on the device. The device can only display what it supports and perhaps may need to truncate certain fields but the user should see an accurate representation of the event. The reminder should also be set on the device. + +After making modifications and synchronizing, the changes should display on the server as well. There should be no evidence of any truncation server-side if truncation occurred client-side but the field itself was not actually part of the modification done. + +The reminder should be removed from the server-side event. + +[reviewer="N.B."] +**** +Some implementations will preserve reminders on the server-side event. They consider that reminders on the mobile side are distinct from those on the server +**** + +h| 1.2 Access Level and Priority +| Verify that access level and priority values in events correctly synchronize to the device. + +Verify that any form of mapping that occurs does not have adverse effects +| From the Server, create an event with default access and priority (e.g. Normal/Medium). + +Perform a synchronization + +From the device, modify the event. + +Perform a synchronization + +Repeat making sure to test all supported access level and priorities. +| The event should display on the device with the access level and priority appropriately mapped if needed. + +After making modifications and synchronizing, the changes should display on the server as well. There should be no evidence of any change server-side to the access level or priority if not actually part of the modification done + +h| 1.3 Special Characters From Server +| Verify that special characters in events correctly synchronize to the device. +| From the Server, create an event filling out all fields with special characters. + +Perform a synchronization + +From the device, modify the event. + +Perform a synchronization +| The event should display on the device with all fields on the server correctly mapped to corresponding fields on the device. All special characters should correctly display on the device as it is displayed on the server. + +After modifying the event, the characters should remain correctly displayed on both the device and server and the changes made on the device should be reflected on the server + +h| 1.4 Multi-Byte Characters From Server +| Verify that multi-byte characters in events correctly synchronize to the device. +| From the server, create a meeting filling out all fields with multi-byte characters. + +Perform a synchronization + +From the device modify the event. + +Perform a synchronization +| The event should display on the device with all multi-byte characters correctly displayed. + +After modifying the event, the multi-byte characters should remain correctly displayed on both the device and server, and the changes made on the device should be reflected on the server. + +h| 1.5 Deletion +| Verify that events deleted server side are deleted on the device +| From the server delete all events created in previous tests. + +Perform a synchronization +| The deleted events should not be displayed on the device +|=== + +[cols="a,a,a,a",options=header] +.Device to Server +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 1.6 Create an Event with a Reminder +| Verify that basic events synchronize to the server. + +Verify that reminders can be sent +| From the device, create a simple future event with a reminder. + +Perform a synchronization + +From the server, edit the event and remove the reminder. + +Perform a synchronization +| The event should display on the server with all fields mapped correctly. The reminder should be set on the server as well. + +After editing the meeting and syncing, the meeting should be updated on the device. + +The reminder should be removed from the device-side event. + +[reviewer="N.B."] +**** +Some implementations will preserve reminders on the device-side event. They consider that reminders on the mobile side are distinct from those on the server +**** + +h| 1.7 Access Level and Priority (can only be done if device supports setting an access level or priority) +| Verify that access level and priority values in events correctly synchronize to the server. +| From the device, create an event with default access and priority (e.g. Normal/Medium). + +Perform a synchronization + +Repeat making sure to test all supported access level and priorities. +| The event should display on the server with the access level and priority appropriately mapped if needed. + +h| 1.8 Special Characters from Device +| Verify that special characters in events correctly synchronize to the server. +| From the device, create an event filling out all fields with special characters. + +Perform a synchronization + +From the server, modify the event. + +Perform a synchronization +| The event should display on the server with all fields on the device correctly mapped to corresponding fields on the server. All special characters should correctly display on the server as it is displayed on the device. + +After modifying the event, the characters should remain correctly displayed on both the device and server. + +h| 1.9 Multi-Byte Characters from Device +| Verify that multi-byte characters in meetings correctly synchronize to the server. +| From the device, create a meeting filling out all fields with multi-byte characters. + +Perform a synchronization + +From the server, modify the event + +Perform a synchronization +| The event should display on the server with all fields on the device correctly mapped to corresponding fields on the server. All multi-byte character should be displayed correctly. + +After modifying the event, the multi-byte characters should remain correctly displayed on both the device and server, and the changes on the server should be reflected on the device. + +h| 1.10 Deletion +| Verify that events deleted device side are deleted on the server +| From the device delete all events created in previous tests. + +Perform a synchronization +| The deleted events should be deleted off of the server as well. +|=== + +=== All Day Events + +The following set of tests verifies that all-day events can be passed back and forth between the +mobile device and the server. They also attempt to verify the following: + +* that all day events locked to a specific day remain locked to that day. +* that all day events which span multiple days can be handled + +NOTE: <> -- Special Information, has additional information on all day events. + +NOTE: All tests should be performed in succession. + +[cols="a,a,a,a",options=header] +.Server to Device +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 2.1 Create all-day event in same time zone +| Verify that all-day events can be synchronized when server and device are in the same time zone +| Verify that time zone selected on server and mobile device is the same. + +Create an all-day event on server on 6^th^ December 2006 (start date 06/12/06, end date 06/12/06) with a subject of 'all-day event'. + +Synchronize with mobile device. +| Event should display as an all-day event in the device calendar on 06/12/06. + +If the mobile device uses an icon to distinguish an all-day event from a timed appointment this is displayed for this entry. + +h| 2.2 Create all-day event to device in different time zone +| Verify that all-day events can be synchronized when server and device are in a different time zone +| Set the time zone on the server to GMT (London) and the time zone on the mobile device to GMT-5 (Eastern Time, US & Canada) + +Create an all-day event on server on 6^th^ December 2006 (start date 06/12/06, end date 06/12/06) with a subject of 'all-day event'. + +Synchronize with mobile device. +| Event should display as an all-day event in the mobile device on 06/12/06. + +If the mobile device uses an icon to distinguish an all-day event from a timed appointment this is displayed for this entry. + +h| 2.3 Create a Single Instance All Day Event with Reminder +| Verify that basic calendar entries synchronize to the device. +| From the Server, create a single instance future all-day event, filling out all fields with maximum input, with a reminder. + +Perform a synchronization + +From the device, modify the day event and remove the reminder. + +Perform a synchronization +| The day event should display on the device as an all day event with all fields on the server correctly mapped to corresponding fields on the device. The reminder should also be set on the device. + +After making modifications and synchronizing, the changes should display on the server as well. Any client side truncation of fields should not be propagated back to the server. + +[underline]#_BOF Topic_#: What form should the iCalendar be to represent a day event? Currently the vCalendar to send depends greatly on the manufacturer of the device. + +h| 2.4 Create an anniversary all-day event +| Verify that anniversaries can be synchronized +| Create an anniversary on the server on 4^th^ May 2007 + +Perform a synchronization +| The anniversary should display on the device on 4^th^ May 2007 + +h| 2.5 All-day event on last day of month & last day of year check +| Verify boundary conditions +| Create an all-day event/anniversary on 31^st^ March 2007 and 31^st^ December 2007 +| The all-day event/anniversary should display on the device on 31/03/2007 and 31/12/2007 + +h| 2.6 Create a Single Instance Holiday with Reminder +| Verify that basic calendar entries synchronize to the device. +| Perform previous test cases, but for Holidays instead of All Day Events + +A 'Holiday' is a special type of all-day event supported by some calendar products + +Holidays may not be supported in the same fashion for all systems. +| The Holiday should display on the device as something appropriate (as a holiday or an all day event depending on what the device can support) with all fields on the server correctly mapped to corresponding fields on the device. + +On the ensuing synchronization changes should not be propagated to the server as holidays can't be changed. + +[underline]#_BOF Topic_#: What should be expected behaviour? Should a modify be sent back to the device to put the holiday back? Some systems would allow the holiday to be removed. How do you specify that something is a holiday in iCalendar? + +h| 2.7 Update an all-day event on server and synchronize back to mobile device in same time zone +| Verify that all-day event modifications can be synchronized correctly +| Verify that time zone selected on server and mobile device is the same. + +Create an all-day event on server on 6^th^ December 2006 (start date 06/12/06, end date 06/12/06) with a subject of 'all-day event'. + +Perform a synchronization + +Update all-day event on server and modify subject to 'all-day event modified'. + +Perform a synchronization +| Event title on device calendar should be modified to 'all-day event modified' and remain an (untimed) all-day event. + +If the device calendar application uses an icon to distinguish an all-day event from a timed appointment this is displayed for this entry. + +h| 2.8 Update an all-day event on server and synchronize back to a device in different time zone +| Verify that all-day event modifications can be synchronized correctly +| Set the time zone on the server to GMT (London) and the time zone on the mobile device to GMT-5 (Eastern Time, US & Canada). + +Create an all-day event on server on 6^th^ December 2006 (start date 06/12/06, end date 06/12/06) with a subject of 'all-day event'. + +Perform a synchronization + +Update all-day event on server and modify subject to 'all-day event modified'. + +Perform a synchronization +| Event title on device calendar should be modified to 'all-day event modified' and remain an (untimed) all-day event. + +If the device calendar application uses an icon to distinguish an all-day event from a timed appointment this is displayed for this entry. + +h| 2.9 Create a Single Instance Multi-day Day Event +| Verify that basic calendar entries synchronize to the device. +| For multi-day Day Events, please read <> before testing. + +From the Server, create a single instance Day Event that starts tomorrow and ends 3 days later. Make sure this does not span outside your synchronization range. + +Perform a synchronization + +From the device, modify the end date to end 1 day earlier than the previous end date (If the device supports multi-day Day Events) + +Perform a synchronization +| For devices that support multi-day Day Events, the entry should display on the device with a Day Event that spans for the 4 days, as it is on the server. + +For devices that do not support multi-day Day Events results may vary. + +After modifying the end date from the device and synchronizing, the entry on the server should be one day shorter, reflecting the change made on the device. + +[underline]#_BOF Topic_#: What should be expected behaviour? What should iCalendar look like? + +h| 2.10 Remove Single Instance Meeting, Day Event, and Holiday +| Verify that a basic deletion synchronize to the device. +| From the Server, delete a single instance meeting, day event, and holiday + +Perform a synchronization +| All the selected entries are removed from the device. This should not affect any of the other existing entries. +|=== + +[cols="a,a,a,a",options=header] +.Device to Server +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 2.11 Create an all-day event and synchronize to a server in same time zone +| Verify that basic calendar entries can be synchronized to the server +| Verify that time zone selected on server and mobile device is the same. + +Create an all-day event on the mobile device on 6^th^ December 2006 (start date 06/12/06, end date 06/12/06) with a subject of 'all-day event'. + +Perform a synchronization +| Event should display on the server as an all-day event on 06/12/06. + +If the server calendar application uses an icon to distinguish an all-day event from a timed appointment this is displayed for this entry. + +h| 2.12 Create an all-day event and synchronize to a server in different time zone +| Verify that basic calendar entries can be synchronized to the server +| Set the time zone on the server to GMT (London) and the time zone on the mobile device to GMT-5 (Eastern Time, US & Canada). + +Create an all-day event on the mobile device on 6^th^ December 2006 (start date 06/12/06, end date 06/12/06) with a subject of 'all-day event'. + +Perform a synchronization +| Event should display on the server as an all-day event on 06/12/06. + +If the server calendar application uses an icon to distinguish an all-day event from a timed appointment this is displayed for this entry. + +h| 2.13 Create a Single Instance All Day Event with Reminder +| Verify that basic calendar entries can be synchronized to the server +| On the device, create a single instance future all-day event, filling out all fields with maximum input, with a reminder. + +Perform a synchronization + +From the device, modify the day event and remove the reminder. + +Perform a synchronization +| The day event should display on the server as an all day event with all fields on the server correctly mapped to corresponding fields on the device. The reminder should also be set on the server. + +After making modifications and synchronizing, the changes should display on the server as well. Any client side truncation of fields should not be propagated back to the server. + +[underline]#_BOF Topic_#: What form should the iCalendar be to represent a day event? + +h| 2.14 Create an anniversary all-day event +| Verify that anniversaries can be synchronized +| Create an anniversary on the device on 4^th^ May 2007 + +Perform a synchronization +| The anniversary should display on the server on 4^th^ May 2007 + +h| 2.15 Update an all-day event on mobile device and synchronize back to server in same time zone +| Verify that all-day event modifications can be synchronized correctly +| Verify that time zone selected on server and mobile device is the same. + +Create an all-day event on server on 6^th^ December 2006 (start date 06/12/06, end date 06/12/06) with a subject of 'all-day event'. + +Synchronize with mobile device. + +Update all-day event on mobile device and modify subject to 'all-day event modified'. + +Synchronize with server. +| Event subject should be modified to 'all-day event modified' and remain an (untimed) all-day event. + +If the server calendar application uses an icon to distinguish an all-day event from a timed appointment this is displayed for this entry. + +h| 2.16 Update an all-day event on mobile device and synchronize back to a server in different time zone +| Verify that all-day event modifications can be synchronized correctly +| Set the time zone on the server to GMT (London) and the time zone on the mobile device to GMT-5 (Eastern Time, US & Canada). Create an all-day event on server on 6^th^ December 2006 (start date 06/12/06, end date 06/12/06) with a subject of 'all-day event'. Synchronize with mobile device. + +Update all-day event on mobile device and modify subject to 'all-day event modified'. Synchronize with server. +| Event subject should be modified to 'all-day event modified' and remain an (untimed) all-day event. + +If the server calendar application uses an icon to distinguish an all-day event from a timed appointment this is displayed for this entry. + +h| 2.17 Create a Single Instance Multi-Day Day Event +| Verify that basic calendar entries can be synchronized to the server +| For multi-day Day Events, please read section in <> before testing. + +If the device allows for creation of multi-day Day Events, then create a single instance Day Event that starts tomorrow and ends 3 days later. Make sure this does not span outside your synchronization range. + +Perform a synchronization + +From the device, modify the end date to end 1 day earlier than the previous end date. + +Perform a synchronization +| Upon the first synchronization, the multi-day Day Event should display on the Server spanning 4 days. + +After modifying the entry and synchronizing, the server side entry should display as being one day less. + +h| 2.18 Remove Single Instance Meeting, Day Event, and Holiday +| Verify that a basic deletion synchronize to the server. +| From the device, delete a single instance meeting, day event, and holiday + +Perform a synchronization +| All the selected entries are removed from the server. This should not affect any of the other existing entries. +|=== + +=== Repeating Entries + +The following test cases verify that recurring events can be synchronized between device and +server. + +In particular + +* Repeating calendar events can be created +* Repeating calendar events can be modified (exceptions added/removed) +* Repeating calendar events can be deleted + +NOT ALL DEVICES SUPPORT RECURRING ENTRIES. Only perform these tests if the +device does support the creation of recurring entries. + +NOTE: The level of REPEATING/RECURRING meeting support will vary depending on the +server. See <> for explanation on possible levels of support. + +NOTE: All tests should be performed in succession. + +[options=header,cols="a,a,a,a"] +.Server to Device +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 3.1 Create Daily Repeat (every day, bounded) +| Verify that a daily repeat can be synchronized + +[example] +Five day conference +| Create an appointment on 23^rd^ April 2007 with a daily repeat until 27^th^ +April 2007 + +Perform a synchronization +| Device calendar should display 5 occurrences of a daily repeating meeting + +h| 3.2 Create Daily Repeat (every other day, unbounded) +| Verify that a daily repeat can be synchronized + +[example] +Meeting every other day +| Create an appointment on 23^rd^ April 2007 with a daily repeat every other day + +Perform a synchronization +| Device calendar should display a daily repeating meeting every other day starting from 23^rd^ April 2007 + +The repeat pattern should remain unbounded (in other words, it should repeat forever) + +h| 3.3 Create Daily Repeat (every 7 days, unbounded) +| Verify that a daily repeat can be synchronized + +[example] +Weekly Staff Meeting +| Create an appointment on 2^nd^ May 2007 with a daily repeat every 7 days + +Perform a synchronization +| Device calendar should display a weekly meeting every seven days (every Wednesday) from 2^nd^ May 2007 + +The repeat pattern should be the same visible pattern as a weekly repeat and it should be unbounded + +h| 3.4 Create Weekly Repeat (every Wed, unbounded) +| Verify that a weekly repeat can be synchronized + +[example] +Meeting every Wednesday +| Create an appointment on 2^nd^ May 2007 with a weekly repeat on Wednesday + +Perform a synchronization +| Device calendar should display a weekly meeting every Wednesday from 2^nd^ May 2007 + +The repeat pattern should remain unbounded + +h| 3.5 Create Weekly repeat (Wed & Fri, unbounded) +| Verify that a weekly repeat can be synchronized + +[example] +Swimming class held every week on Wednesday and Fridays +| Create an appointment on 2^nd^ May 2007 with a weekly repeat on Wednesday and Friday + +Perform a synchronization +| Device calendar should display a weekly meeting with occurrences on Wednesday and Fridays from 2^nd^ May + +The first two occurrences should be 02/05/07 and 04/05/07 + +The repeat pattern should remain unbounded + +h| 3.6 Create Fortnightly Repeat (unbounded) +| Verify that a weekly repeat can be synchronized + +[example] +Project status meeting held every two weeks +| Create an appointment on 1^st^ May 2007 with a fortnightly repeat + +Perform a synchronization +| Device calendar should display an appointment every two weeks starting from 1^st^ May + +The repeat pattern should remain unbounded + +h| 3.7 Create Monthly By Date Repeat (unbounded) +| Verify that a monthly by date repeat can be synchronized + +[example] +Utility bill payment on 15^th^ day of the month + +| Create an appointment on 15^th^ May 2007 with a monthly by date repeat + +Perform a synchronization +| Device calendar should display an appointment on 15^th^ of every month starting from 15^th^ May 2007 + +The repeat pattern should remain unbounded + +h| 3.8 Create Monthly By Day Repeat (first occurrence, bounded) +| Verify that a monthly by date repeat can be synchronized + +[example] +Monthly meeting on the first Monday of every month +| Create an appointment on 7^th^ May 2007 repeating every month on the first Monday for a year (13 occurrences in total) + +Perform a synchronization +| Device calendar should display an appointment on the following dates: + +07/05/2007, + +04/06/2007, + +02/07/2007, + +06/08/2007, + +03/09/2007, + +01/10/2007, + +05/11/2007, + +03/12/2007, + +07/01/2008, + +04/02/2008, + +03/03/2008, + +07/04/2008, + +05/05/2008 + +h| 3.9 Create Monthly By Day Repeat (n^th^ occurrences, bounded) +| Verify that a monthly by day repeat can be synchronized + +[example] +Monthly meeting on the 2^nd^ Tuesday of every month +| Create an appointment 2^nd^ & 3^rd^ Sunday of every month starting on 13^th^ May 2007 until 10^th^ June 2007 (3 occurrences in total) + +Perform a synchronization +| Device calendar should display an appointment on the following dates: + +13/05/2007, + +20/05/2007, + +10/06/2007 + +h| 3.10 Create Monthly By Day Repeat (last occurrence, bounded) +| Verify that a monthly by day repeat can be synchronized + +[example] +Monthly meeting on the last Friday of every month +| Create an appointment on the last Friday of every month starting 25^th^ May 2007 until 29^th^ June 2007 (2 occurrences in total) + +Perform a synchronization +| Device calendar should display an appointment on the following dates: + +25/05/2007, + +29/06/2007 + +h| 3.11 Create Yearly Repeat (every year, unbounded) +| Verify that anniversary events can be synchronized + +[example] +Birthday + +[example] +St Patrick's Day (17^th^ March) +| Create an anniversary entry for Valentine's Day (14^th^ February 2007) on server + +Perform a synchronization +| Device calendar should display an anniversary event on 14/02/2007 and future years (2008, 2009 etc.) + +The repeat pattern should remain unbounded + +h| 3.12 Create Yearly Repeat (every year for 5 years, bounded) +| Verify that yearly events can be synchronized +| Create an event with a yearly repeat on 1^st^ April 2007 for five years + +Perform a synchronization +| Device calendar should display an event on the following dates: + +01/04/2007, + +01/04/2008, + +01/04/2009, + +01/04/2010, + +01/04/2011 + +h| 3.13 Create Yearly Repeat (every 4 years, bounded) +| Verify that yearly events can be synchronized + +[example] +Leap year occurs every four years on 29^th^ February +| Create an event with a yearly repeat on 29^th^ February 2004 every four years until 01/03/2012 + +Perform a synchronization +| Device calendar should display an event on the following dates + +29/02/2004, + +29/02/2008, + +29/02/2012 + +h| 3.14 Create custom repeat (`RDATES` only) +| Verify that custom repeat can be synchronized + +[example,source=miniop] +Dates for a lecture series: Tuesday this week, Wednesday next week, & Friday the following week. +| Create custom repeat pattern Tuesday 1^st^ May 2007, Wednesday 9^th^ May 2007, Friday 18^th^ May 2007 + +Perform a synchronization +| Device calendar should display the event on the following dates: + +01/05/2007, + +09/05/2007, + +18/05/2007 + +h| 3.15 Create repeat combination +| Verify that combinations of repeat patterns can be synchronized + +[example] +Daylight Saving Time starts on second Sunday in March in 2007 +| Create appointment with a repeat combination, for example: Second Sunday in March every year (`RRULE:FREQ=YEARLY; BYMONTH=3; BYDAY=2SU`) + +Perform a synchronization +| Device calendar should display event on 2^nd^ Sunday of March (11^th^ March 2007) + +The repeat pattern should remain unbounded + +h| 3.16 Create repeating event plus custom repeat (`RRULE` + `RDATE`) +| Verify that more complex repeat patterns can be synchronized + +[example] +Weekly meeting with an extra meeting this week + +| Create a weekly repeating meeting (every Monday starting 5^th^ May 2007) and add an additional `RDATE` on Wed 7^th^ May + +Perform a synchronization +| Device calendar should display weekly repeat every Monday starting 5^th^ May 2007 and an additional meeting occurrence on 7^th^ May with the same event description + +h| 3.17 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) +| Verify repeating meetings with exceptions can be synchronized + +[example] +Daily repeating meeting except for Wednesday +| Create a daily repeating meeting starting 30^th^ April 2007 until Friday 4^th^ May 2007. + +Create meeting exception on Wednesday 2^nd^ May (i.e. cancel meeting) +| Device calendar should display daily repeat between 30/04/07 and 04/05/07 with no meeting on 02/05/07 + +h| 3.18 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) +| Verify that more complex repeat patterns can be synchronized +| Create custom repeat pattern + +Perform a synchronization +| Device calendar correctly displays repeating pattern + +h| 3.19 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) +| Verify that more complex repeat patterns can be synchronized +| Create custom repeat pattern + +Perform a synchronization +| Device calendar correctly displays repeating pattern + +h| 3.20 Modify anniversary +| Verify that modification of meeting details does not cause device representation to become non-repeating +| Create anniversary event on 4^th^ July 2007 on device + +Perform a synchronization + +Modify subject of event on server + +Perform a synchronization +| Device calendar correctly displays anniversary event on 04/07/07 + +Server modification of event subject is correctly synchronized to client + +h| 3.21 Modify occurrences of repeating meeting +| Verify that modification of the repeat rule is correctly synchronized to the device +| Create daily repeating meeting starting on 1^st^ May 2007 until 5^th^ May (5 occurrences) + +Perform a synchronization + +Cancel occurrence on 4^th^ May & 5^th^ May (select this and future instances when deleting) from server + +Perform a synchronization +| Device calendar displays repeating meeting 1-5^th^ May + +After synchronization, device calendar displays meeting 1-3^rd^ May only + +h| 3.22 Modify exceptions of repeating meeting +| Verify that addition, modification and deletion of exceptions is correctly synchronized +| Create daily repeating meeting starting on 1^st^ May 2007 until 5^th^ May (5 occurrences) + +Perform a synchronization + +Cancel occurrence on 4^th^ May & 5^th^ May (select this and future instances when deleting) from server + +Perform a synchronization + +Extend meeting to 4^th^ May (Modify exception) + +Perform a synchronization +| Device calendar displays repeating meeting 1-5^th^ May + +After second synchronization, device calendar displays meeting 1-3^rd^ May + +After third synchronization, calendar displays meeting 1-4^th^ May + +h| 3.23 Delete recurring meeting +| Verify deletion of recurring meeting is correctly synchronized to the device +| Create recurring meeting on server + +Perform a synchronization + +Delete recurring meeting from server + +Perform a synchronization +| Device calendar displays recurring meeting + +After synchronization, device calendar no longer displays recurring meeting + +h| 3.24 Create Daily Repeat (every day, bounded) +| Verify that a daily repeat can be synchronized + +[example] +Five day conference +| Create an appointment on 23^rd^ April 2007 with a daily repeat until 27^th^ April 2007 + +Perform a synchronization +| Server calendar should display 5 occurrences of a daily repeating meeting + +h| 3.25 Create Daily Repeat (every other day, unbounded) +| Verify that a daily repeat can be synchronized + +[example] +Meeting every other day +| Create an appointment on 23^rd^ April 2007 with a daily repeat every other day + +Perform a synchronization +| Server calendar should display a daily repeating meeting every other day starting from 23^rd^ April 2007 + +The repeat pattern should remain unbounded (in other words, it should repeat forever) + +h| 3.26 Create Daily Repeat (every 7 days, unbounded) +| Verify that a daily repeat can be synchronized + +[example] +Weekly Staff Meeting +| Create an appointment on 2^nd^ May 2007 with a daily repeat every 7 days + +Perform a synchronization +| Server calendar should display a weekly meeting every seven days (every Wednesday) from 2^nd^ May 2007 + +The repeat pattern should be the same visible pattern as a weekly repeat and it should be unbounded + +h| 3.27 Create Weekly Repeat (every Wed, unbounded) +| Verify that a weekly repeat can be synchronized + +[example] +Meeting every Wednesday +| Create an appointment on 2^nd^ May 2007 with a weekly repeat on Wednesday + +Perform a synchronization +| Server calendar should display a weekly meeting every Wednesday from 2^nd^ May 2007 + +The repeat pattern should remain unbounded + +h| 3.28 Create Weekly repeat (Wed & Fri, unbounded) +| Verify that a weekly repeat can be synchronized + +[example] +Swimming class held every week on Wednesday and Fridays +| Create an appointment on 2^nd^ May 2007 with a weekly repeat on Wednesday and Friday + +Perform a synchronization +| Server calendar should display a weekly meeting with occurrences on Wednesday and Fridays from 2^nd^ May + +The first two occurrences should be 02/05/07 and 04/05/07 + +The repeat pattern should remain unbounded + +h| 3.29 Create Fortnightly Repeat (unbounded) +| Verify that a weekly repeat can be synchronized + +[example] +Project status meeting held every two weeks +| Create an appointment on 1^st^ May 2007 with a fortnightly repeat + +Perform a synchronization +| Server calendar should display an appointment every two weeks starting from 1^st^ May + +The repeat pattern should remain unbounded + +h| 3.30 Create Monthly By Date Repeat (unbounded) +| Verify that a monthly by date repeat can be synchronized + +[example] +Utility bill payment on 15^th^ day of the month +| Create an appointment on 15^th^ May 2007 with a monthly by date repeat + +Perform a synchronization +| Server calendar should display an appointment on 15^th^ of every month starting from 15^th^ May 2007 + +The repeat pattern should remain unbounded + +h| 3.31 Create Monthly By Day Repeat (first occurrence, bounded) +| Verify that a monthly by date repeat can be synchronized + +[example] +Monthly meeting on the first Monday of every month +| Create an appointment on 7^th^ May 2007 repeating every month on the first Monday for a year (13 occurrences in total) + +Perform a synchronization +| Server calendar should display an appointment on the following dates: + +07/05/2007, + +04/06/2007, + +02/07/2007, + +06/08/2007, + +03/09/2007, + +01/10/2007, + +05/11/2007, + +03/12/2007, + +07/01/2008, + +04/02/2008, + +03/03/2008, + +07/04/2008, + +05/05/2008 + +h| 3.32 Create Monthly By Day Repeat (n^th^ occurrences, bounded) +| Verify that a monthly by day repeat can be synchronized + +[example] +Monthly meeting on the 2^nd^ Tuesday of every month +| Create an appointment 2^nd^ & 3^rd^ Sunday of every month starting on 13^th^ May 2007 until 10^th^ June 2007 (3 occurrences in total) + +Perform a synchronization +| Server calendar should display an appointment on the following dates: + +13/05/2007, + +20/05/2007, + +10/06/2007 + +h| 3.33 Create Monthly By Day Repeat (last occurrence, bounded) +| Verify that a monthly by day repeat can be synchronized + +[example] +Monthly meeting on the last Friday of every month +| Create an appointment on the last Friday of every month starting 25^th^ May 2007 until 29^th^ June 2007 (2 occurrences in total) + +Perform a synchronization +| Server calendar should display an appointment on the following dates: + +25/05/2007, + +29/06/2007 + +h| 3.34 Create Yearly Repeat (every year, unbounded) +| Verify that anniversary events can be synchronized + +[example] +Birthday + +[example] +St Patrick's Day (17^th^ March) +| Create an anniversary entry for Valentine's Day (14^th^ February 2007) on server + +Perform a synchronization +| Server calendar should display an anniversary event on 14/02/2007 and future years (2008, 2009 etc.) + +The repeat pattern should remain unbounded + +h| 3.35 Create Yearly Repeat (every year for 5 years, bounded) +| Verify that yearly events can be synchronized +| Create an event with a yearly repeat on 1^st^ April 2007 for five years + +Perform a synchronization +| Server calendar should display an event on the following dates: + +01/04/2007, + +01/04/2008, + +01/04/2009, + +01/04/2010, + +01/04/2011 + +h| 3.36 Create Yearly Repeat (every 4 years, bounded) +| Verify that yearly events can be synchronized + +[example] +Leap year occurs every four years on 29^th^ February +| Create an event with a yearly repeat on 29^th^ February 2004 every four years until 01/03/2012 + +Perform a synchronization +| Server calendar should display an event on the following dates: + +29/02/2004, + +29/02/2008, + +29/02/2012 + +h| 3.37 Create custom repeat (`RDATES` only) + +_Optional test - Mobile UI may not allow creation of this type of repeat_ +| Verify that custom repeat can be synchronized + +[example,source=miniop] +Dates for a lecture series: Tuesday this week, Wednesday next week, & Friday the following week. +| Create custom repeat pattern Tuesday 1^st^ May 2007, Wednesday 9^th^ May 2007, Friday 18^th^ May 2007 + +Perform a synchronization +| Server calendar should display the event on the following dates: + +01/05/2007, + +09/05/2007, + +18/05/2007 + +h| 3.38 Create repeat combination + +_Optional test - Mobile UI may not allow creation of this type of repeat +| Verify that combinations of repeat patterns can be synchronized + +[example] +Daylight Saving Time starts on second Sunday in March in 2007 +| Create appointment with a repeat combination, for example: Second Sunday in March every year (`RRULE:FREQ=YEARLY; BYMONTH=3; BYDAY=2SU`) + +Perform a synchronization +| Server calendar displays event on 2^nd^ Sunday of March (11^th^ March 2007) + +The repeat pattern should remain unbounded + +h| 3.39 Create repeating event plus custom repeat (`RRULE` + `RDATE`) + +_Optional test - Mobile UI may not allow creation of this type of repeat_ +| Verify that more complex repeat patterns can be synchronized + +[example] +Weekly meeting with an extra meeting this week +| Create a weekly repeating meeting (every Monday starting 5^th^ May 2007) and add an additional `RDATE` on Wed 7^th^ May + +Perform a synchronization +| Server calendar displays weekly repeat every Monday starting 5^th^ May 2007 and an additional meeting occurrence on 7^th^ May with the same event description + +h| 3.40 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) + +_Optional test - Mobile UI may not allow creation of this type of repeat_ +| Verify repeating meetings with exceptions can be synchronized + +[example] +Daily repeating meeting except for Wednesday +| Create a daily repeating meeting starting 30^th^ April 2007 until Friday 4^th^ May 2007. + +Create meeting exception on Wednesday 2^nd^ May (i.e. cancel meeting) +| Server calendar displays daily repeat between 30/04/07 and 04/05/07 with no meeting on 02/05/07 + +h| 3.41 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) + +_Optional test - Mobile UI may not allow creation of this type of repeat_ +| Verify that more complex repeat patterns can be synchronized +| Create custom repeat pattern + +Perform a synchronization +| Server calendar correctly displays repeating pattern + +h| 3.42 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) + +_Optional test - Mobile UI may not allow creation of this type of repeat_ +| Verify that more complex repeat patterns can be synchronized +| Create custom repeat pattern + +Perform a synchronization +| Server calendar correctly displays repeating pattern + +h| 3.43 Modify anniversary +| Verify that modification of meeting details does not cause server representation to become non-repeating +| Create anniversary event on 4^th^ July 2007 on server + +Perform a synchronization + +Modify subject of event on device + +Perform a synchronization +| Server calendar correctly displays anniversary event on 04/07/07 + +Device modification of event subject is correctly synchronized to server + +h| 3.44 Modify occurrences of repeating meeting +| Verify that modification of the repeat rule is correctly synchronized to the server +| Create daily repeating meeting starting on 1^st^ May 2007 until 5^th^ May (5 occurrences) + +Perform a synchronization + +Cancel occurrence on 4^th^ May & 5^th^ May (select this and future instances when deleting) from device + +Perform a synchronization +| Server calendar displays repeating meeting 1-5^th^ May + +After synchronization, server calendar displays meeting 1-3^rd^ May only + +h| 3.45 Delete recurring meeting +| Verify deletion of recurring meeting is correctly synchronized to the server +| Create recurring meeting on server + +Perform a synchronization + +Delete recurring meeting from device + +Perform a synchronization +| Server calendar displays recurring meeting + +After synchronization, server calendar no longer displays recurring meeting +|=== + +=== Scheduling + +The following set of tests verifies that basic scheduling of events can be accomplished. In +particular they attempt to verify the following: + +* that attendee information can be correctly displayed on a mobile device. +* that users invited to a meeting can accept or decline invitations from their mobile device. +* that users can initiate invitations from their mobile device. + +NOTE: <> -- Special Information, has additional information on Scheduling. + +NOTE: All tests should be performed in succession. + +NOTE: In order to perform these tests the mobile device must be able to support the concept of +attendees. + +[%unnumbered,cols="a,a,a,a",options=header] +|=== +| Test ID | Objective | Procedure | Expected Result +h| 4.1 Create Entry as owner with Attendees from Server +| Verify that basic synchronize with attendees work. +| As the owner, from the server, create a meeting and a day event, each with the owner and 2 attendees. + +Perform a synchronization + +As the owner, from the server, add 1 more attendees to each entry and remove an attendee. As the original remaining attendee update your attendance status server side. + +Perform a synchronization +| The two entries should display on the device with all attendees and the appropriate reply status. + +After adding and removing attendees and syncing, the new attendees should be reflected on the device as well as the updated attendance status for the original remaining attendee. + +h| 4.2 Accept Entry as Invitee from Device +| Verify that modifying the reply status of an invitation is reflected on the server. +| As another user, from the server, create a meeting and invite the mobile device user as well as one other user. + +Perform a synchronization + +From the device accept the invitation, server side update the attendance status for the other invite. + +Perform a synchronization +| After the first synchronization, the meeting invitation should display on the device with all attendees displayed. + +After the second synchronization, the updated acceptance of the invitation should be evident server side as well as on the device. The updated attendance status of the other invitee should also display on the device. + +h| 4.3 Create Entry as owner with Attendees from Device +| Verify that device initiated invitations work. +| From the device, create a meeting and a day event, each with the owner and 2 attendees. + +Perform a synchronization + +Server-side have the attendees accept and/or decline the invitations. + +Perform a synchronization +| The two entries should display on the server with all attendees and the appropriate reply status. All attendees should receive invitations. + +After the second synchronization, the updated attendee status of the invitees should be evident device side. +|=== + +=== Time Zones and Daylight Savings + +The following set of tests verifies that events can be passed back and forth regardless of differing +timezones and changes to or from daylight savings. In particular they attempt to verify the +following: + +* that events (simple and repeating) are displayed correctly regardless of whether or not +the server and mobile device are set to the same timezone and that any change to the +timezone on either side will not effect the events in any way. +* that when a synchronization date range spans over a change from daylight savings to +standard time (or vice versa) that events (simple and repeating) on either side of the +change are still displayed correctly and that when the current time actually does move +into the new time setting there is no adverse effects. + + +NOTE: <> -- Special Information, has additional information on time zones and daylight +savings. + +NOTE: All tests should be performed in succession. + +NOTE: In order to perform the daylight savings tests, you must be able to synchronize across +that period of time. + +[%unnumbered,cols="a,a,a,a",options=header] +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 5.1 Time Zones and Simple Meetings +| Verify that simple meetings can be passed back and forth regardless of what time zone setting is in place on either side. +| Make sure the current time zone on the server and the device matches. + +From the server, create a meeting that starts at 10am. + +Perform a synchronization + +Change the time zone on the device to a different time zone 3 hours later. + +Create a new meeting starting at 10am from the server. + +Perform a synchronization + +Change the time zone of the server to match the new time zone. + +Modify the title of one of the meetings. + +Perform a synchronization + +Repeat tests starting with device and server in opposite time zones. + +Repeat tests with the server side meetings being created by another person inviting the owner of the mobile device where by the organizer is in a completely different time zone then those being used in the test. +| The meeting should first display on the device at the correct time, 10am. + +After changing time zones, the device should automatically change the times for all entries. The first meeting should now be displayed at 7am on the device. + +After creating the second meeting and synchronizing, the server is still on the old time zone, so the times will differ. On the device, the first meeting is at 7am and the second at 10am, but on the server, the first meeting is at 10am, and the second at 1pm. + +After changing the time zone on the server and making modifications, both the device and server should display the first meeting at 7am and the second meeting at 10am. + +When tests are repeated the appropriate offsets should be seen but everything should still be where it is intended. + +h| 5.2 Time Zones and Repeating Meetings +| Verify that repeating meetings can be passed back and forth regardless of what time zone setting is in place on either side. +| Make sure the current time zone on the server and the device matches. + +From the server, create a repeating weekly meeting that starts at 10am. + +Perform a synchronization + +Change the time zone on the device to a different time zone 3 hours later. + +Create a new repeating weekly meeting starting at 10am from the server. + +Perform a synchronization + +Change the time zone of the server to match the new time zone. + +Modify the title of one of the meetings. + +Perform a synchronization + +Repeat tests starting with device and server in opposite time zones. + +Repeat tests with the server side meetings being created by another person inviting the owner of the mobile device where by the organizer is in a completely different time zone then those being used in the test. +| The meetings should first display on the device at the correct time, 10am. + +After changing time zones, the device should automatically change the times for all entries. The meetings should now be displayed at 7am on the device. + +After creating the second meeting and synchronizing, the server is still on the old time zone, so the times will differ. On the device, the first meetings are at 7am and the second ones at 10am, but on the server, they are at 10am and at 1pm respectively. + +After changing the time zone on the server and making modifications, both the device and server should display the first set of meetings at 7am and the second set of meetings at 10am. + +When tests are repeated the appropriate offsets should be seen but everything should still be where it is intended. + +h| 5.3 Time Zones and All-Day Events +| Verify that day events can be passed back and forth regardless of what time zone setting is in place on either side. +| Make sure the current time zone on the server and the device matches. + +From the server, create a Day Event filling out all fields. + +Perform a synchronization + +Change the time zone on the device to a different time zone 3 hours earlier. + +Modify the title of the Day Event from the device. + +Perform a synchronization + +Change the time zone of the server to match the new time zone. + +Modify the title of the Day Event from the server. + +Perform a synchronization + +Repeat tests starting with device and server in opposite time zones. + +Repeat tests with the server side meetings being created by another person inviting the owner of the mobile device where by the organizer is in a completely different time zone then those being used in the test. +| The Day Event should first display on the device. The Day Event should be displayed on the correct day on the device. + +After changing the time zone on the device, the device should automatically change the times for all the entries. After modifying and syncing, the Day Event, the Day Event should still be displayed on the same date with the new title on both server and device. + +After changing the time zone on the server, the Day Event should still be displayed on the same day with the new title on the device. + +Day Events are independent of time zone changes. + +When tests are repeated Day Events should continue to be seen as independent of differing time zones. + +h| 5.4 Spring Daylight Savings Single Entries from Server +| Verify that entries originating form the server before and after a switch remain displayed correctly to users. +| Make sure you modify the synchronization range to include the daylight savings period you are about to test. + +From the Server, create a single entry before and another single entry after the Spring daylight savings date at 10am, with all fields filled out. + +Perform a synchronization + +Push the time on the server and the device ahead to simulate crossing into daylight savings. + +Create a new meeting server side at 10am + +Perform a synchronization + +Repeat tests with the server side meetings being created by another person inviting the owner of the mobile device where by the organizer is in a completely different time zone then those being used in the test which has a different date for DST changes. +| The two entries should display on the device with all fields correctly mapped. + +The time of the two entries should be at 10am. + +After the time change the time of the two original entries and the new entry should still be at 10am + +When tests are repeated meetings between when the organizer's Time zone switch to DST and when the invitee's Time zone switches should be offset by an hour (e.g. A 10am London meeting will normally be a 5am Montreal meeting but it will be at 6am after the province of Quebec switches to DST up until the point where British Summer Time kicks in at which point it will go back to being at 5am). + +h| 5.5 Spring Daylight Savings Repeating Entry from Server +| Verify that repeating entries originating form the server before and after a switch remain displayed correctly to users. +| Make sure you modify the synchronization range to include the daylight savings period you are about to test. + +From the Server, create a repeating daily entry that starts at 10am, with all fields filled out, which spans across a Spring daylight savings date + +Perform a synchronization + +Repeat tests with the server side meetings being created by another person inviting the owner of the mobile device where by the organizer is in a completely different time zone then those being used in the test which has a different date for DST changes. +| All instances of the repeating entry should display on the device. + +The times of *ALL* instances before and after the daylight savings date should be 10am. + +When tests are repeated meetings between when the organizer's Time zone switch to DST and when the invitee's Time zone switches should be offset by an hour (e.g. A 10am London meeting will normally be a 5am Montreal meeting but it will be at 6am after the province of Quebec switches to DST up until the point where British Summer Time kicks in at which point it will go back to being at 5am). + +h| 5.6 Autumn Daylight Savings Single Entries from Device +| Verify that entries originating for the device before and after a switch remain displayed correctly to users. +| Make sure you modify the synchronization range to include the daylight savings period you are about to test. + +From the device, create a single entry before and another single entry after the Autumn daylight savings date at 10am, with all fields filled out. + +Perform a synchronization + +Push the time on the server and the device ahead to simulate crossing into daylight savings. + +Create a new meeting device side at 10am + +Perform a synchronization +| The two entries should display on the server with all fields correctly mapped. + +The time of the two entries should be at 10am. + +After the time change the time of the two original entries and the new entry should still be at 10am + +h| 5.7 Autumn Daylight Savings Recurring Entry from Device +| Verify that repeating entries originating form the device before and after a switch remain displayed correctly to users. +| Make sure you modify the synchronization range to include the daylight savings period you are about to test. + +From the device, create a repeating daily entry that starts at 10am, with all fields filled out, which spans across an Autumn daylight savings date. + +Perform a synchronization +| All instances of the repeating entry should display on the Server. + +The times of *ALL* instances before and after the daylight savings date should be 10am +|=== + +== Part II - Task Tests + +The following set of tests verifies that basic mobile task management can be accomplished. In +particular they attempt to verify the following: + +* that Tasks can be created, modified, and deleted on the device or server +* that Task Access Levels and Priorities can be correctly mapped +* that Task reminders can be correctly mapped +* that Tasks can be marked as completed and have this fact reflected on either side +* that special characters and multi byte characters can be correctly handled + +NOTE: <> -- Special Information, has additional information on Mapping, Reminders, +Special Characters, Multi Byte Characters, and Task Completion. + +NOTE: All tests should be performed in succession. + +[cols="a,a,a,a",options=header] +.Server to Device +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 6.1 Create task +| Verify that basic task information can be synchronized +| Create a task on the server + +Complete all fields with maximum input. + +Perform a synchronization + +Modify the task on the device. + +Perform a synchronization + +Modify the task on the server + +Perform a synchronization +| The task should be synchronized to the device with server fields correctly mapped to the corresponding supported fields on the device. + +After second synchronization device modification should be propagated to the server. Any truncation that occurred device side should not affect the server. + +After third synchronization server modification should be reflected on the device. +h| 6.2 Task Access Level and Priority +| Verify that access level and priority values in tasks correctly synchronize to the device. + +Verify that any form of mapping that occurs does not have adverse effects +| From the Server, create a task with default access and priority (e.g. Normal/Medium). + +Perform a synchronization + +From the device, modify the event. + +Perform a synchronization + +Repeat making sure to test all supported access level and priorities. +| The task should display on the device with the access level and priority appropriately mapped if needed. + +After making modifications and synchronizing, the changes should display on the server as well. There should be no evidence of any change server-side to the access level or priority if not actually part of the modification done + +h| 6.3 Create task with alarm +| Verify that task reminders can be synchronized +| Create a task on the server + +Complete title, due date, priority, and access/privacy fields. + +Set category for task (if supported) + +Set an alarm reminder for both the start date and the due date. + +Perform a synchronization +| The task should be synchronized to the device with all fields correctly mapped to the corresponding fields on the device. + +An appropriate mapping of the server side reminders should be present on the devices. + +h| 6.4 Mark task as completed +| Verify that task completion can be synchronized +| Create a task on the server + +Complete title, due date, priority and access/privacy fields + +Perform a synchronization + +Set task as complete on server + +Perform a synchronization +| The task should be synchronized to the device, with all fields correctly mapped. + +After second synchronization, task should be marked as complete on the device + +h| 6.5 Special Characters From Server +| Verify that special characters in tasks correctly synchronize to the device. +| From the Server, create a task filling out all fields with special characters. + +Perform a synchronization + +From the device, modify the task. + +Perform a synchronization +| The task should display on the device with all fields on the server correctly mapped to corresponding fields on the device. All special characters should correctly display on the device as it is displayed on the server. + +After modifying the task, the characters should remain correctly displayed on both the device and server and the changes made on the device should be reflected on the server + +h| 6.6 Multi-Byte Characters From Server +| Verify that multi-byte characters in tasks correctly synchronize to the device. +| From the server, create a task filling out all fields with multi-byte characters. + +Perform a synchronization + +From the device modify the event. + +Perform a synchronization +| The task should display on the device with all multi-byte characters correctly displayed. + +After modifying the task, the multi-byte characters should remain correctly displayed on both the device and server, and the changes made on the device should be reflected on the server. + +h| 6.7 Deletion +| Verify that tasks deleted server side are deleted on the device +| From the server delete all tasks created in previous tests. + +Perform a synchronization +| The deleted tasks should be deleted off of the device as well. +|=== + +[cols="a,a,a,a",options=header] +.Device to Server +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 6.8 Create task +| Verify that basic task information can be synchronized +| Create a task on the device + +Complete all fields with maximum input. + +Perform a synchronization + +Modify the task on the device + +Perform a synchronization +| The task should be synchronized to the server with fields correctly mapped to the corresponding supported fields on the server. + +After second synchronization device modification should be reflected on the server. + +h| 6.9 Task Access Level and Priority +| Verify that access level and priority values in tasks correctly synchronize to the server. +| From the device, create a task with default access and priority (e.g. Normal/Medium). + +Perform a synchronization + +Repeat making sure to test all supported access level and priorities. +| The task should display on the server with the access level and priority appropriately mapped if needed. + +h| 6.10 Create task with alarm +| Verify that task reminders can be synchronized +| Create a task on the device + +Set an alarm reminder (as allowed by the device). + +Perform a synchronization +| The task should be synchronized to the device with all fields correctly mapped to the corresponding fields on the device. + +An appropriate mapping of the device side reminder(s) should be present on the server. + +h| 6.11 Mark task as completed +| Verify that task completion can be synchronized +| Create a task on the device + +Complete title, due date, priority and access/privacy fields + +Perform a synchronization + +Set task as complete on device + +Perform a synchronization +| The task should be synchronized to the server, with all fields correctly mapped. + +After second synchronization, task should be marked as complete on the server + +h| 6.12 Special Characters From Device +| Verify that special characters in tasks correctly synchronize to the server. +| From the device, create a task filling out all fields with special characters. + +Perform a synchronization + +From the server, modify the task. + +Perform a synchronization +| The task should display on the server with all fields on the device correctly mapped to corresponding fields on the server. All special characters should correctly display on the server as it is displayed on the device. + +After modifying the task, the characters should remain correctly displayed on both the device and server and the changes made on the server should be reflected on the device + +h| 6.13 Multi-Byte Characters From Device +| Verify that multi-byte characters in tasks correctly synchronize to the server. +| From the device, create a task filling out all fields with multi-byte characters. + +Perform a synchronization + +From the server modify the event. + +Perform a synchronization +| The task should display on the server with all multi-byte characters correctly displayed. + +After modifying the task, the multi-byte characters should remain correctly displayed on both the device and server, and the changes made on the server should be reflected on the device. + +h| 6.14 Deletion +| Verify that tasks deleted device side are deleted on the device +| From the device delete all tasks created in previous tests. + +Perform a synchronization +| The deleted tasks should be deleted off of the server as well. +|=== + +== Part III - Contact Tests + +=== Contacts + +The following set of tests verifies that basic synchronization of contact information can be +accomplished. In particular they attempt to verify the following: + +* that Contacts can be created, modified, and deleted on the device or server and that +appropriate mappings are maintained to verify that there is no corruption or loss of data. +* that special characters and multi byte characters can be correctly handled + +NOTE: <> -- Special Information, has additional information on Mapping, Special +Characters, and Multi Byte Characters. + +NOTE: All tests should be performed in succession. + +[%unnumbered,options=header,cols="a,a,a,a"] +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 7.1 Create new contact with minimal fields from the server +| To verify that the fields that are already supported for a device are correctly transferred from server to device upon creation and from device to server upon modification. +| Create a new contact entry from the server with all fields (except for addresses, emails, telephone numbers, and URLs) + +Perform a synchronization + +Modify it from the device, and then synchronize again. +| The address book entry created on the server should be reflected on the device with an appropriate mapping of fields taking advantage of what the device supports. + +After modifying the entry and synchronizing, the modified entry is similar on both the device and server. + +The mappings used to send data to the devices should be the same on data returning to the server so that the expected fields are modified. + +h| 7.2 Create new contact with minimal fields from the device +| To verify that the fields that are already supported for a device are correctly transferred from device to server upon creation and from device to server upon modification. +| Create a new contact entry from the device with all fields filled out (except for addresses, emails, telephone numbers, and URLs) + +Perform a synchronization + +Modify it from the server, and then synchronize again. +| The address book entry created on the device should be reflected on the server with an appropriate mapping of fields taking advantage of what the server supports + +After modifying the entry and synchronizing, the modified entry is similar on both the device and server. + +The mappings used to send data to the server should be the same on data returning to the device so that the expected fields are modified. + +h| 7.3 Special Characters +| Verify that special characters in contacts correctly synchronize to and from the device. +| From the Server, create a contact filling out all text fields with special characters. + +Perform a synchronization + +From the device modify the contact. + +Perform a synchronization + +Repeat creating contact on device and modifying on the server. +| The contact should display on the device with all fields on the server correctly mapped to corresponding fields on the device. All special characters should correctly display on the device as it is displayed on the server. + +After modifying the contact, the characters should remain correctly displayed on both the device and server and the changes made on the device should be reflected on the server + +h| 7.4 Multi-Byte Characters +| Verify that multi-byte characters in contacts correctly synchronize to and from the device. +| From the server, create a contact filling out all text fields with multi-byte characters. + +Perform a synchronization + +From the device modify the contact + +Perform a synchronization + +Repeat creating contact on device and modifying on the server. +| The contact should display on the device with all multi-byte characters correctly displayed. + +After modifying the contact, the multi-byte characters should remain correctly displayed on both the device and server, and the changes made on the device should be reflected on the server. + +h| 7.5 Delete a contact from the server +| To verify that when a contact is deleted on the server, it is also deleted on the device. +| From the server, delete an existing contact entry and synchronize. +| The corresponding address book entry is removed from the device. + +h| 7.6 Delete a contact from the device +| To verify that when a contact is deleted on the device, it is also deleted on the server. +| From the device, delete an existing contact entry and synchronize +| The corresponding address book entry is removed from the server. +|=== + +=== Addresses + +The following set of tests target specifically the ability to synchronize addresses. In particular they +attempt to verify the following: + +* that multiple addresses can be handled. +* that address formatting is correctly maintained + +NOTE: <> -- Special Information, has additional information on Addresses. + +NOTE: All tests should be performed in succession. + +[%unnumbered,cols="a,a,a,a",options=header] +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 8.1 Create new contact with addresses from the server +| To verify that the address fields that are supported for a device are correctly transferred from server to device upon creation, modification and deletion. +| Create a contact with several addresses (home, business, etc...) from the server + +Perform a synchronization + +Modify the contact from device changing one of the addresses. + +From the server, delete the first address property and add a new address property + +Perform a synchronization + +Modify the new address property from the server. + +Perform a synchronization. +| The contact should display on the device and address types supported by the device should be available and formatted in a way that is usable to the user. + +The modification made on the device should be reflected on the server but any server side formatting of the address should be maintained and other address (not supported on the device) should remain unaffected. + +The device side address affected by the server side changes should be correctly updated and the correct ordering should be maintained. + +Last modification should update the corresponding address on the device. + +h| 8.2 Create new contact with addresses from the device +| To verify that the address fields that are supported for a device are correctly transferred from device to server upon creation, modification and deletion. +| Create a contact with several addresses (home, business, etc...) from the device (if the device supports it). + +Perform a synchronization + +Modify the contact from server changing one of the addresses. + +From the device, delete the first address property and add a new address property + +Perform a synchronization + +Modify the new address property from the device. + +Perform a synchronization. +| The contact should display on the server and address types entered on the device should be correctly mapped, available, and formatted in a way that is usable to the user on the server. + +The modification made on the server should be reflected on the device but any device side formatting of the address should be maintained. + +The device side changes should get correctly reflected server side with the ordering correctly maintained. + +Last modification should update the corresponding address on the server. +|=== + +=== Phone Numbers + +The following set of tests target specifically the ability to synchronize phone numbers. In particular +they attempt to verify the following: + +* that multiple phone numbers can be handled. +* that phone number formatting is correctly maintained + +NOTE: <> -- Special Information, has additional information on Phone Numbers. + +NOTE: All tests should be performed in succession. + +[%unnumbered,cols="a,a,a,a",options=header] +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 9.1 Create new contact with telephone numbers from the server +| To verify that the telephone fields that are supported for a device are correctly transferred from server to device upon creation, modification and deletion. +| Create a contact with several phone numbers (home1, home2, business, etc...) from the server. + +Perform a synchronization + +Modify the contact from device changing one of the phone numbers. + +From the server, delete the first phone number and add a new phone number + +Perform a synchronization + +Modify the new phone number from the server. + +Perform a synchronization +| The contact should display on the device and the phone numbers supported by the device should be available and formatted in a way that is usable to the user. + +The modification made on the device should be reflected on the server but any server side formatting of the phone number should be maintained and other phone numbers (not supported on the device) should remain unaffected. + +The device side phone numbers affected by the server side changes should be correctly updated and the correct ordering should be maintained. + +Last modification should update the corresponding phone number on the device. + +h| 9.2 Create new contact with telephone numbers from the device +| To verify that the telephone fields that are supported for a device are correctly transferred from device to server upon creation, modification and deletion. +| Create a contact with several phone numbers (home1, home2, business, etc...) from the device (if the device supports it). + +Perform a synchronization + +Modify the contact from server changing one of the phone numbers. + +From the device, delete the first phone number and add a new phone number + +Perform a synchronization + +Modify the new phone number from the device. + +Perform a synchronization +| The contact should display on the server and phone numbers entered on the device should be correctly mapped, available, and formatted in a way that is usable to the user on the server. + +The modification made on the server should be reflected on the device but any device side formatting of the phone number should be maintained. + +The device side changes should get correctly reflected server side with the ordering correctly maintained. + +Last modification should update the corresponding phone number on the server. +|=== + +=== Emails and URLs + +The following set of tests target specifically the ability to synchronize emails addresses and +URLs. + +[%unnumbered,options=header,cols="a,a,a,a"] +|=== +| Test ID | Objective | Procedure | Expected Result + +h| 10.1 Create new contact with emails from the server +| To verify that the email fields that are supported for a device are correctly transferred from server to device upon creation, modification and deletion. +| Create a contact with several email addresses (home1, home2, business, etc...) from the server. + +Perform a synchronization + +Modify the contact from device changing one of the email addresses. + +From the server, delete the first email address and add a new email address + +Perform a synchronization + +Modify the new email address from the server. + +Perform a synchronization +| The contact should display on the device and the email addresses supported by the device should be available and formatted in a way that is usable to the user. + +The modification made on the device should be reflected on the server but other email addresses (not supported on the device) should remain unaffected. + +The device side email addresses affected by the server side changes should be correctly updated and the correct ordering should be maintained. + +Last modification should update the corresponding email address on the device. + +h| 10.2 Create new contact with URLs/web page addresses from the server. +| To verify that the URL fields that are supported for a device are correctly transferred from server to device upon creation, modification and deletion. +| Create a contact with several web page URLs (work web site, home web site, etc...) from the server. + +Perform a synchronization + +Modify the contact from device changing one of the web page URLs + +From the server, delete the first URL and add a new URL + +Perform a synchronization + +Modify the new URL from the server. + +Perform a synchronization +| The contact should display on the device and the URLs supported by the device should be available and formatted in a way that is usable to the user. + +The modification made on the device should be reflected on the server but other URLs (not supported on the device) should remain unaffected. + +The device side URLs affected by the server side changes should be correctly updated and the correct ordering should be maintained. + +Last modification should update the corresponding URL on the device. + +h| 10.3 Create new contact with emails from the device +| To verify that the email fields that are supported for a device are correctly transferred from device to server upon creation, modification and deletion. +| Create a contact with several email addresses (home1, home2, business, etc...) from the device. + +Perform a synchronization + +Modify the contact from the server changing one of the email addresses. + +From the device, delete the first email address and add a new email address + +Perform a synchronization + +Modify the new email address from the device. + +Perform a synchronization +| The contact should display on the server and email addresses entered on the device should be correctly mapped, available, and formatted in a way that is usable to the user on the server. + +The modification made on the server should be reflected on the device. + +The device side changes should get correctly reflected server side with the ordering correctly maintained. + +Last modification should update the corresponding email address on the server + +h| 10.4 Create new contact with URLs/web page addresses from the device +| To verify that the URL fields that are supported for a device are correctly transferred from device to server upon creation, modification and deletion. +| Create a contact with several web page URLs (work web site, home web site, etc...) from the device. + +Perform a synchronization + +Modify the contact from server changing one of the web page URLs + +From the device, delete the first URL and add a new URL + +Perform a synchronization + +Modify the new URL from the device. + +Perform a synchronization +| The contact should display on the server and URLs entered on the device should be correctly mapped, available, and formatted in a way that is usable to the user on the server. + +The modification made on the server should be reflected on the device. + +The device side changes should get correctly reflected server side with the ordering correctly maintained. + +Last modification should update the corresponding URL on the server +|=== + +[[appendix-A]] +[appendix] +== Supporting Information + +=== Truncation + +In an ideal scenario all servers and all mobile devices would store their calendar data as +iCalendar and they would support all attributes that iCalendar supports and would support +attribute values of any length. Given the inherit restrictions of memory and storage prevalent with +most mobile devices this utopian vision however is a rarity. + +More then likely (although this is changing as mobile devices become more and more +sophisticated) the device may only be able to expose a subset of the information possible from +the desktop application and certain attribute values may need to be truncated. This is acceptable +as long as an adequately accurate representation of the event is still available to the calendar +user and if such restrictions do not end up adversely effecting the original server-side +representation. + +[example] +A user creates a meeting with a start time, duration, title, and some details. The +calendar application on the device the user uses can only display start time, duration, and title. If +the user modifies the start time from the device and then synchronizes the details should not be +lost on the server-side representation of the event. + +[example] +A user creates a meeting with a start time, duration, title, and a long description of +the agenda. The calendar application on the device the user uses can display the start time, the +duration, the title, and some details but it is limited to an amount of characters less then the +length of the agenda so the entire agenda cannot be seen by the user from the device. If the user +modifies the start time from the device and then synchronizes the agenda should not get +truncated server-side. + +=== Mapping + +Most iCalendar attribute values are either a string or a date and time and thus there is no real +issues regarding mapping for such values. For access levels and priorities however the values +are based on enumerated lists. The iCalendar specification does describe appropriate values for +these attributes but often desktop calendar client solutions support a much richer set of values +and often mobile devices will support a lesser set (if at all). + +The case where the mobile device simply doesn't support such concepts is fairly easy to support. +Simply don't display them and make sure changes on the device do not affect them server-side +(as described in the section above about truncation). + +It becomes much more complicated when the mobile device does support these attributes but +supports a different set of accepted values. In such cases an appropriate mapping needs to +occur. This is acceptable as long as an adequately accurate representation of the event is still +available to the calendar user and if such mappings do not end up adversely effecting the original +server-side representation. + +[example] +A user creates a meeting with normal access (which is different then public for the +system they use). The calendar application on the device the user uses can only display public or +private so the event is displayed as public. If the user modifies the start time from the device and +then synchronizes the access level should not now be changed to Public on the server-side +representation of the event. It is important that it remains normal. + +[example] +A user creates a public meeting by mistake. Later the user uses the calendar +application on the device to switch it to private. The access level should change on the server as +the user explicitly modified it. + +[example] +A user creates a meeting of highest priority (which is different than high for the +system they use). The calendar application on the device the user uses can only display low, +medium, or high so the event is displayed as high. If the user modifies the start time from the +device and then synchronizes the priority level should not now be changed to high on the server-side +representation of the event. It is important that it remains highest. This issue affects events +and tasks. + +[example] +A user creates a task in their mobile device calendar with a priority of 'Normal' +(iCalendar created by device uses a `PRIORITY` value of 2). The user sends this task via +Bluetooth to their desktop and imports the task to their desktop Calendar application. The desktop +calendar application displays the task as 'Medium'. + +=== Reminders + +Reminders are interesting in that the reminder you may want your desktop calendar client to give +you concerning an event is not necessarily the reminder you'd like your mobile calendar client to +provide. You may want your desktop application to provide you with a popup reminder 15 minutes +before the start of the event and you may want your device to beep and vibrate when the event is +scheduled to actually start. Since they are both the same and yet different the way in which they +get synchronized can sometimes be of interest. + +If a user creates events using their desktop client they certainly don't want to have to manually +create reminders on the events that get sent to their mobile device however if they edit when they +want a desktop reminder or choose to remove a desktop reminder does this really correlate in +any way to the mobile alert? + +As a general rule it makes sense that any new event with a reminder being sent from either side +(device or server) should result in an appropriate default reminder being setup on the other side. + +[example] +A user's desktop calendar client by default sets up events with 15-minute popup +reminders. The calendar application on the device the user uses by default sets up events with +reminders to beep when the meeting is due to start. Events created on either side by the user +result in the same type of expected reminder. + +[example] +A user has a meeting in an hour with a 15-minute popup reminder. Because the user +is currently giving a web conference presentation she does not want the reminder popping up +while she is presenting so she removes the reminder. She still wants to be reminded of her next +call however and is relying on the fact that her mobile phone will beep when it is time. + +[underline]#_BOF Topic_#: _If a reminder is removed on the device (or vice versa) should the reminder be +removed from the event on the server?_ + +Task reminders are also interesting since most desktop calendar applications will allow you to +setup a reminder based on when you should start working on the task or based on the due date +where is most mobile devices either don't support Task reminders or only support one reminder. +Implementations should attempt map task reminders accordingly. + +=== Special Characters + +The following illustrates some of the special characters that can be used to test when dealing with +test cases for special characters: + +Accented Characters:: çèéêëìíîïàáâãäåõöôóòùúûüñý +Euro Sign:: €€€€€ +Numbers:: ½¼ +Omega Characters:: ƒ†‡¶£¤¥§© +Special Characters:: ~`!@#$%^&()_+=-{}|\][:"';<>?/., +New Line character:: (↵) + +=== Multi-Byte Characters + +Characters from East Asian languages such as Chinese, Japanese and Korean (CJK) cannot be +represented using 8-bit text like many European languages. CJK character sets typically use +multi-byte variable-length encodings such as UTF-8. + +The following illustrates some of the multi-byte characters that can be used to test when dealing +with test cases for multi-byte characters: + +Chinese Characters: + +* U+5317 U+4EAC Beijing + +Japanese Characters: + +* U+3042 Hiragana Letter A +* U+3044 Hiragana Letter I +* U+3046 Hiragana Letter U +* U+3048 Hiragana Letter E +* U+304A Hiragana Letter O + +Korean Characters: + +* U+1100 Latin characters k/g +* U+1105 Latin characters r/l + +Implementations should use UTF-8 encoding form as a default character set as recommended by +iCalendar to guarantee correct display of multi-byte characters (such as CJK languages). +However, mobile devices may wish to use specific character sets for the market the device is +being sold within (e.g. Many Japanese phones use Shift-JIS exclusively). Regardless of the +implementation however users never want to see "%^($%^^^##@???" + +=== All Day Events + +An 'all-day event' is a scheduled activity covering an entire day or a block of days. These types of +events are also known as 'day events' or 'memo' events. + +A common use of all-day events is to represent a vacation and some products support a special +type of all-day event just for holidays. Anniversary events, an annually repeating all-day event, +are also very common provided in Calendar & Scheduling products. + +==== Representation of All-Day Events in vCalendar/iCalendar + +The <> specification, which is widely adopted on mobile devices, does not describe a +standard representation of all day events. + +The OMA data synchronisation group has published a Minimum Interoperability Profile <> +which aims to provide guidance on how to interpret some ambiguous areas of the vCalendar 1.0 +specification. + +It recommends that all-day events should be represented using the same date for `DTSTART` and +`DTEND`, with a time of 00:00:00 for `DTSTART` and 24:00:00 for `DTEND`. 24 hour events that +begin at midnight should be represented using `DTSTART` and `DTEND` time of 00:00:00 and +`DTEND` set to one day after the event. However, a time value of 24:00:00 is illegal syntax in +iCalendar; the valid range for the hour value is 0 through 23. + +The iCalendar specification states that the `DTEND` property is exclusive (i.e. the date specified in +the `DTEND` is not included in the event duration). An event that lasts all day on June 19^th^ 2007 +should be represented as: + +[source%unnumbered] +---- +DTSTART;VALUE=DATE:20070619 +DTSTART;VALUE=DATE:20070620 +---- + +Most major Calendar implementations follow this guidance. For example, Microsoft Outlook: + +[source%unnumbered] +---- +BEGIN:VCALENDAR +PRODID:-//Microsoft Corporation//Outlook 9.0 MIMEDIR//EN +VERSION:2.0 +METHOD:PUBLISH +BEGIN:VEVENT +ORGANIZER:MAILTO:< omitted > +DTSTART;VALUE=DATE:20070402 +DTEND;VALUE=DATE:20070403 +LOCATION:London office +TRANSP:OPAQUE +SEQUENCE:0 +UID:040000008200E00074C5B7101A82E00800000000E0F088CC1875C7010000000000 + 000000100000008863E35F4A64624397C17A75BF6F4C4A +DTSTAMP:20070402T101937Z +SUMMARY:MS all day event\, time +PRIORITY:5 +CLASS:PUBLIC +END:VEVENT +END:VCALENDAR +---- + +For example, Google(TM): + +[source%unnumbered] +---- +BEGIN:VCALENDAR +PRODID:-//Google Inc//Google Calendar 70.9054//EN +VERSION:2.0 +CALSCALE:GREGORIAN +METHOD:REQUEST +BEGIN:VEVENT +DTSTART;VALUE=DATE:20070404 +DTEND;VALUE=DATE:20070405 +< additional properties omitted for readability > +STATUS:CONFIRMED +SUMMARY:Birthday +TRANSP:TRANSPARENT +END:VEVENT +END:VCALENDAR +---- + +==== Do All Day Events have a duration? + +The biggest issue with day events has always been do they have duration and how should they +be presented using iCalendar? iCalendar certainly is robust enough to support the concept but it +does not explicitly dictate how to represent a day event. + +Christmas is the 25^th^ of December regardless of were you are in the world. It can be represented +as an all day event on the 25^th^. If a user is attending a conference in Hong Kong from Monday to +Friday then for the user's boss in North America the user is actually starting to attend some time +on Sunday. Which is right? + +The reality is that some systems support one way or the other or in some cases both then add +into the mix a mobile device that itself does its own thing and you have a dreadful mess. + +[underline]#_BOF Topic_#: _What form of iCALENDAR should be passed back and forth to ensure these +concepts are correctly handled?_ + +==== Multi-Day Day Events + +Some servers support multi-day All Day events and treat them as entries that spans across a few +days. For devices that support multi-day All day events, the entry will be displayed in the same +manner as it is on the server. + +Unfortunately many devices that support All Day Events do not support them across multiple +days. For such cases the server has to do something appropriate. Refusing to send such day +events is one solution or perhaps the entry is displayed on the device as a one day event, but the +string "~(x)" is appended to the title field, where x is the number of days that entry spans across. +For example: If the device does not support multi-day events, then creating one on the server +with the title "Multi-Day Event" that spans across 5 days will be displayed on the device as a one +day Day Event with the title "Multi-Day Event ~(5)". When testing multi-day day events it is +important to understand what the device can support and what the server does to compensate. + +=== Repeating Events and Recurrence Rules + +The biggest problem in the area of repeating meetings is devices that claim they can support +repeating meetings but which in reality can only support a very small subset of the repeating +capabilities that iCalendar provides for. + +For devices that simply don't claim any sort of repeating support server-side implementations +should expand all repeating events and send simple single instance events for all instances within +the synchronization range. The fact that they are repeating should be maintained server-side and +any modification done on the device side should not affect this. This means that users can't deal +with such entries as being repeating on the device but they at least always known when an +instance is occurring. + +It becomes much more complicated when the mobile device does claim support for repeating +entries but does not fully support the concept. Often devices will support deleted exceptions but +not modified exceptions or only support a small subset of recurrence rules. Whenever a server +cannot reliably know what sort of support the device is claiming it should fallback to the method +described above for devices with no support + +Ideally, there should be a minimum level of support that mobile devices must have to claim they +support repeating entries. + +[underline]#_BOF Topic_#: _What is this minimum level of support?_ + +A server should fallback to splitting up instances for anything, which falls outside of this minimum +implementation. + +=== Scheduling + +Ideally any mobile calendar solution should allow a mobile user to perform any sort of operation +on their mobile device that they would expect to be able to do from their desktop. Most mobile +calendar clients however are still very PIM centric. Basic mobile scheduling capabilities are +beginning to emerge however. At a minimum mobile devices should be able to display +information about who the attendees of a meeting are, should allow users to accept or decline +invitations from their mobile device, and should allow users to initiate invitations for their mobile +device. + +=== Time Zones and Daylight Savings + +In order to correctly display an event and interoperate with major calendar applications, it is +necessary for mobile calendar solutions to provide support for time zones. Unfortunately, most +mobile calendar solutions do not provide full support for time zones currently and are therefore +unable to correctly display events in all situations. + +The following different classes of device time zone support have been identified: + +Full Time zone support + +* has time zone configuration option +* stores all events as local time, UTC or local time with time zone rule (as appropriate) +* transfers recurring events in local time with a time zone definition +* supports day events independent of time zone changes (aka "floating" time) +* when the time zone is changed on the device, all events shift in the device calendar +(excluding day events) +* switches to and from daylight savings do not effect the display of events + +Type 1 Partial time zone support + +* has time zone configuration option +* stores all events in UTC +* day events are stored as events starting at midnight with no duration +* when the time zone is changed on the device, all events shift, including day events which +initially display at midnight (until the time zone was changed) +the synchronization server requires the user's default calendar server time zone to +correctly synchronize day events to this device (so that they hopefully end up at midnight) + +Type 2 Partial time zone support + +* has time zone configuration option +* accepts UTC, but actually stores them in local time +* supports day events independent of time zone changes +* when the time zone is changed on the device, events are not shifted in the device +calendar + +No Timezone support + +* the device may have an option for setting the time zone, but the information is not used +by the device calendar application or the synchronization application +* all events are stored in local time +* day events may or may not be supported correctly +* when the time zone is changed on the device, events are not shifted in the device +calendar + +The timezone and daylight savings test cases described in this test suite assume that full time +zone support has been correctly implemented. Other implementations are simply considered +broken. + +=== Task Completion + +How should a task (to-do) be marked as completed? + +iCalendar defines three properties to indicate that a task is completed. `STATUS` describes the +overall status for the task, `PERCENT-COMPLETE` allows a delegate to communicate the +percentage completion of the task to the organizer and `COMPLETED` indicates the date/time that +the to-do was actually completed. An example of how a completed task can be expressed using +these properties is shown below: + +[source%unnumbered] +---- +STATUS:COMPLETED +PERCENT-COMPLETE:100 +COMPLETED:20070101T100000Z +---- + +Unfortunately, iCalendar does not prescribe a single way to mark a task as completed. Device-side +clients may support any combination of these properties. A server must be able to send a +device a completed task using the format it is expecting and be able to recognize how a device +client indicates a completed task. + +=== Contact Mappings + +vCard as a data format supports an endless number of combinations. This makes it very difficult +to guarantee that both sides can support each others representations. Despite its flexibility +however it does not support a way to enumerate multiple properties of the same type. + +=== Addresses + +Address formats differ greatly from country to country. When an address is represented as just a +text field it is easy to pass back and forth but often servers will store address information in +separate fields (e.g. Street, City, Country, Postal Code) therefore when working with a device that +expects things all in one label this information must be merged together. If it is then modified on +the device it is important that server side the representation remains intact. +Address formatting for majority of Asian countries will typically require more than one address +field. Some software implementation allows for two fields (e.g. Address1 and Address2) to allow +the extra information to be entered and rendered where as others provide a single Address field. +It may be helpful to provide guidelines on how to handle these occurrences which are extremely +common for Asian addresses. + +[example] +==== +The Yamasa Institute + +Address 1: 1-2-1 Hanehigashi-machi + +Address 2: AichiPrefecture + +City: OkazakiCity + +Country: JAPAN + +Zip Code: 444-0832 +==== + +[example] +==== +Samsung Seoul (Head Office) + +Address 1: SAMSUNGMainBuilding + +Address 2: 250-2 ga,Taepyung-roChung-gu + +City: Seoul + +Country: Korea +==== + +=== Phone numbers + +13336669999, +13336669999, 1 (333) 666-999, all of these are valid and some servers store the +country code, area code, and actual number separately. + +While this format generally works, there are instances where simple concatenation of country +code, area code, and actual number may not work correctly. For instance, a phone number in +Tokyo, Japan(e.g. 03-3580-3377) may not be dialled correctly by using +810335803377. The +area code (03) must be translated to (3) so that the mobile device omits the extra (0) and dials ++81335803377. These types of area codes are quite common for many Asian countries. It would +be ideal if software applications can interpret these type of numbers and automatically convert the +phone numbers accordingly. Also, the display of the phone numbers should be rendered +according to where the end-user is. (e.g. If the user is in Japan, the number 03-3580-3377 should +be used, but if the user is outside of Japan +81335803377 should be displayed). + +[[appendix-B]] +[appendix] +== Sample iCalendar and vCard Streams + +The Calendaring & Scheduling Consortium plans to collect sample iCalendar and vCard +contributions for each of the Calendar, Task, and Contact test cases. These will be made +available from the Consortium's _CalConnect Interoperability Testing Resources_ page: + +http://www.calconnect.org/ioptesting.shtml + +[[appendix-C]] +[appendix] +== Open Issues & Known Omissions + +There are currently no test cases defined for the following areas: + +. Calendar test cases do not include attachments +. Day Event test cases are not considered complete. Issues such as time transparency for +all-day events. For example, should all-day events block time (free/busy handling)? Is the +meaning preserved between device & server? A consensus within the industry needs to +be reached before these tests can be considered complete. +. Recurrence tests are not considered complete: Frequencies less than a day (secondly, +minutely, hourly), various until/count/interval combinations, various `BYXXX` repeat +patterns, `WKST`, limited coverage of combinations of repeat patterns, limited coverage of +exception combinations and repeat modification/deletion. If iCalendar test data is +supplied, verify that recurrence property parameters can be specified in any order. A +consensus within the industry on what the minimal level of support should be on a mobile +device is required to complete a concrete set of tests. +. Minimal Alarms/Meeting reminders and the handling of alarms on the device are provided +but a proper consensus on how to have reminders specified that make sense for the +environment they are going off in needs to be reached. +. Tests covering meetings that start, end, or cross over the shift between standard and +daylight savings are not covered. Consensus on what should be the expected behaviour +is needed. +. Various scheduling operations such as delegation, meeting cancellation, and meeting +reschedules are not covered. Once Scheduling capabilities are more prevalent on mobile +devices additional test cases should be added. +. Repeating Tasks or Task Assignments are not covered. When such support becomes +more widespread on mobile devices additional test cases should be added. +. Character Encoding IOP issues. For example: Shift JIS support & confusion with +encoding Yen symbol/backslash characters, base64/quoted printable encodings, line +folding, UTF-8 support + +[bibliography] +== References + +* [[[rfc4791,RFC 4791]]] + +* [[[calgloss,CC/R 1102]]] + +* [[[rfc2445,IETF RFC 2445]]] + +* [[[oma,OMA DS]]], Open Mobile Alliance Data Synchronization V1.1.2, Open Mobile Alliance, 10 July 2006 http://www.openmobilealliance.org/release_program/ds_v12.html + +* [[[miniop, CC/S 0601]]] + +* [[[rfc3283,IETF RFC 3283]]] + +* [[[ical, CC/Adv 0611]]] + +* [[[vcal,vCalendar 1.0]]], vCalendar The Electronic Calendaring and Scheduling Exchange Format Version 1.0, Versit Consortium, September 18 1996 http://www.imc.org/pdi/vcal-10.txt + +* [[[vcard21,vCard 2.1]]], vCard The Electronic Business Card Version 2.1, Versit Consortium, September 18 1996 http://www.imc.org/pdi/vcard-21.txt + +* [[[rfc2426,RFC 2426]]] + +* [[[vobj,vObject]]], OMA vObject Minimum Interoperability Profile Version 1.0, Open Mobile Alliance, 18 January 2005 +http://www.openmobilealliance.org/release_program/vObject_v10.html + +* [[[wiki,hidden(Wikipedia)]]], https://www.wikipedia.org/ diff --git a/sources/cc-0707-edst-reflections-v1.1/document.adoc b/sources/cc-0707-edst-reflections-v1.1/document.adoc new file mode 100644 index 0000000..594f65f --- /dev/null +++ b/sources/cc-0707-edst-reflections-v1.1/document.adoc @@ -0,0 +1,326 @@ += CalConnect EDST Reflections and Recommendations +:docnumber: 0707 +:copyright-year: 2007 +:language: en +:doctype: advisory +:edition: 1.1 +:status: published +:revdate: 2007-10-04 +:published-date: 2007-10-04 +:technical-committee: DST ADHOC +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Mike Mize +:affiliation: California State University Fresno +:role: editor +:fullname_2: Gary Schwartz +:affiliation_2: Rensselaer Polytechnic Institute +:role_2: editor + +.Foreword +The Calendaring and Scheduling Consortium ("`CalConnect`") is a global +non-profit organization with the aim to facilitate interoperability of +collaborative technologies and tools through open standards. + +CalConnect works closely with international and regional partners, +of which the full list is available on our website +(https://www.calconnect.org/about/liaisons-and-relationships). + +The procedures used to develop this document and those intended for its +further maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different +types of CalConnect documents should be noted. This document was drafted in +accordance with the editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be +held responsible for identifying any or all such patent rights. Details +of any patent rights identified during the development of the document +will be provided in the Introduction. + +//// +TODO: re-enable when we finish the IPR policy +and/or on the CalConnect list of patent +declarations received (see www.calconnect.com/patents). +//// + +Any trade name used in this document is information given for the +convenience of users and does not constitute an endorsement. + +This document was prepared by Technical Committee +_{technical-committee}_. + +This document reviews the impact of implementation of +Extended Daylight Savings Time, which moved the beginning of +DST forward to March 11 in 2007, on the information +technology industry and in particular calendaring and +scheduling systems, and recommendations for what the +industry should do about timezones going forward. + +This document is a follow-on to the advisories and compendium +of fixes which CalConnect collected and published prior to +March 11, 2007. + +== Introduction + +The U.S. Energy Policy Act of 2005 (EPACT 2005), signed by President Bush on August 8, +2005, among its many, many provisions, amends the Uniform Time Act of 1966 by changing the +start and end dates of daylight saving time (DST) in the US. DST begins three weeks earlier and +ends one week later, effective in 2007. DST now begins the second week of March and ends the +first week in November (March 11 and November 4 in 2007). Other areas, including Canada and +Bermuda, also choose to follow the new rules. + +CalConnect, the Calendaring and Scheduling Consortium, has been interested and active in +timezone and DST issues almost since its inception in December 2004. + +In June 2005, CalConnect issued a press release, "EDST Change Untimely" and a "DST +Advisory Notice", both of which "...suggested a simple delay of the effective date (at that point +set to March 2006) of the pending legislation to insure that calendar and scheduling vendors and +consumers have ample time to prepare for any changes." + +In October 2005, CalConnect conducted a timezone survey and issued the "Report on +TIMEZONE Questionnaire Results". + +In May 2006, representatives of CalConnect met with consultants for the Japanese government +which was studying a return to DST. DST has not been observed in Japan since 1952. + +In February 2007, CalConnect issued the press release, "CalConnect Gives Guidance to IT Staff +on Impact of DST Change", published "Extended Daylight Saving Time - Review and +Considerations", and created the "Extended Daylight Saving Time Links, Advisories and +Changes" web page to assist system administrators in tracking vendor updates and DST-related +news and information. + +In August 2007, CalConnect reactivated its TIMZONE Technical Committee, which was +originally convened in June 2005. + +CalConnect's "Extended Daylight Saving Time Review and Considerations" promised a future +"Lessons Learned and Recommendations for the Future" document based on real-world +experiences over the transition time in March to the new DST rules". This document fulfills that +promise. + +== Background + +The U.S. Energy Policy Act of 2005 amends the Uniform Time Act of 1966 by changing the +start and end dates of daylight saving time starting in 2007 as noted previously. + +The Uniform Time Act codified daylight saving time (DST) observance within the U.S. Prior to +the act, each state set its own policy for DST observance, and in some cases, which parts of the +state would be affected. The Act originally set the start of DST to be the last Sunday in April, +and was amended in 1986 (effective in 1987) to be the first Sunday in April. + +Whereas this is the first modification to the DST rules in the United States in 20 years, this is not +the only recent change to DST around the globe. Western Australia, Brazil, and the state of +Indiana, among others, also made their own adjustments to DST start and/or end dates within the +last year or so. The things that distinguish the EPACT 2005 changes from the other changes are: + +. The aforementioned more regional DST changes were problematic and difficult in a +number of ways, but the impact of these difficulties was relatively small globally. +. The scope of the EPACT 2005 change is substantially larger, affecting virtually the entire +United States, the third most populous nation in the world, as well Canada and Bermuda. +. The role that the United States plays in international commerce and IT development +makes this change very significant across the globe. +. In the words of Thomas Friedman, "the world is flat", with geo-political borders +becoming less relevant with respect to trade and commerce. Virtually, everyone is doing +business with everyone else. Agreeing globally on dates and times is now essential. +. Mobile devices are pervasive and indispensable today, as are enterprise and web-based +calendaring systems connecting people across time zones, and organizational and +political boundaries Twenty years ago, when the Uniform Time Act was amended in +1986, these things didn't exist or they were an inconsequential novelty. Clearly that is not +the case today. +. Computer systems, networks, applications and other electronic devices used by banks, the +government and industry are dependent on correct date and time information and are far +more widely used than they were when the last change was made in 1986. +. EPACT 2005 requires the Department of Energy to report to the US Congress on the +impact of the DST change on energy usage and/or conservation by the end of 2007. +Congress may revert back to the 1986 DST dates if they choose. There is conflicting +research as to whether daylight saving results in a net energy saving. + +CalConnect's October 2005 "Report on TIMEZONE Questionnaire Results, observed "... a +number of products convert local time information with a supplied timezone into UTC (the +'standard' time reference) as a simplification. As a result of this, timezone information is +effectively lost. Such products will need to determine how to do any adjustment of the UTC +times based on the proposed DST changes." + +CalConnect's February 2007 publication, "Extended Daylight Saving Time - Review and +Considerations" predicted "The impact of the DST changes should be significantly smaller than +Year 2000 (Y2K) but is still a concern for those involved in preparing for the change. Many +systems will be corrected simply by applying automatic updates from the system vendor in +advance of the March 11th deadline. The result of having out of date rules is also smaller, with +systems being off by an hour instead of a hundred years (or failing completely). On the other +hand, there may be significant impact on computer support organizations, especially in cases +where meetings in a calendar system need to be corrected manually." + +== Real-world experiences + +The impact of the earlier DST start date was noticeable but the magnitude of the impact was +generally felt more by larger enterprises than small businesses or home computer users. +Problems were experienced in a number of areas: + +. Small devices or systems did not correctly ascertain and/or display their local time +correctly, usually, but not always, being off by an hour. +. Some already entered/stored dates/times, such as those in a calendaring system, were no +longer correct, again, in most cases being off by an hour. +. Some already entered/stored all day events, were no longer correct, now spanning more +than a single day. +. Synchronization between devices/systems, such as a smart phone and a calendaring +system, resulted in previously correctly stored events now having incorrect times and/or +dates. +. Some users "manually" corrected already entered/stored events which later became +incorrect after software updates were applied which automatically "re-corrected" these +same events. +. A major utility in one of the Western US states, which could not update all of its +electrical meters in time and accepted that there would be some minor accounting +discrepancies for the extended DST period. +. Some enterprise systems could not be automatically remediated with software patches, +requiring end users to "manually" adjust dates/times which were now incorrect. +. In some cases, when reviewing remediated systems for correct results, users mistook +correct time/dates for incorrect values and changed them yet again. + +While most vendors recognized the seriousness of the problem and responded responsibly by +producing patches, conversion tools and workarounds, some problems persisted, and others +actually resulted from these remediation efforts: + +. Some fixes were not available in time for IT staffs to deploy enterprise-wide before the +DST period began. +. Some initial patches were faulty, requiring later "fixes" to the initial fix. +. The sequencing of patches, both chronologically as well as with respect to the application +of other patches, was not well understood or communicated in some cases. +. Some vendors did a better job than others communicating with their customers about +which systems required remediation and how to affect that remediation. + +IT staffs also encountered difficulties, including: + +. Help desks being flooded with end user questions and problem reports. +. Being able to locate and obtain information and updates for all their products and +devices. +. Providing information and instructions to their user communities. +. Finding adequate resources to do all the required remediation. +. Identifying all the devices and systems requiring remediation. +. Remediating systems in the proper sequences and at the correct times. +. Remediating locally developed applications and/or systems. +. Deciding what to do about end-of-life or otherwise no longer supported systems for +which no remediation was available. +. Inadequate coordination and cooperation between units in larger organizations. + +Generally speaking, the media treated the issue without much hype or hysteria, underplaying the +significance if anything, unlike the confusion generated with the Y2K preparations. There were +few "news of the weird" stories generated by the earlier DST start. + +In most cases, remediation of systems as well as any "manual" corrections required, were +accomplished shortly after March 11, 2007. There were virtually no reports of additional +problems on April 1, 2007 the date which DST would have begun under the 1986 rules. + +Many IT staff and end users resorted to Google searches for vendor and more general +information on the DST changes. Although CalConnect did provide a web page, "Extended +Daylight Saving Time Links, Advisories and Changes", there were very few web sites which +served as authoritative clearinghouses of DST information. + +DST-related issues seemed to gain the most traction and awareness within user groups and +professional organizations very close the March 11th date, leaving insufficient time in many +cases for the necessary tasks. + +== Lessons Learned + +The actions required to mitigate problems resulting from EPACT 2005 pointed out a number of +areas where changes needed to be made both in application development and administrative +practice: + +* Date and time information needs to be stored as completely as possible with as few +assumptions about the context as possible. In some cases, incomplete date and time +representation made reliable data conversion impossible. +* Systems and devices need to accommodate timezone and DST changes more easily, +automatically, and correctly. +* Conversion tools, patches and documentation need to be easily accessible. +* Conversion tools, patches and documentation need to be available in a timely manner so +adequate testing can be performed. In many cases, the remediation started too late. +* The interaction between patches, as well as the sequencing of patches, needs to be +understood and clearly communicated. +* System Administrators need to be more familiar with the systems they support and +interactions between those systems. This includes locally developed applications and +systems, and applications elsewhere within the organization. +* Mitigation and remediation need to take place as early as possible using robust tools. +* Relevant and complete information needs to be made available in a timely fashion by +vendors to their customers, and from IT staff to the people and organizations they +support. The information needs to be clear and appropriate for each audience. +* End users need to have a better understanding of the tools they use to perform their jobs. +Knowing what to look for and expect will help when troubleshooting problems, as well +as make them more productive users of these systems. Many users do not use an external +source of authoritative time information and some do not even configure their desktop +computers to the correct tie zone and/or DST settings. Concomitantly, vendors need to +make these things easier to do and to validate. +* Authoritative clearinghouses for situations such as this DST change can be very valuable +but do not always exist, nor do they necessarily materialize in a timely fashion. + +CalConnect's role as a promoter of calendaring and scheduling standards put the consortium in a +unique position. By publishing web pages with both informational articles and links to resources +on publicly-accessible websites, the consortium was able to act as a clearinghouse of DST-related +resources. The consortium also put out informational press releases to both industry and +general news providers. + +However, CalConnect could have made a greater contribution. The consortium was very active +and visible in the last 6 months of 2005, but did not keep the DST-related issues and concerns in +front of the media, the IT profession, or the public again until February 2007. In retrospect, +raising IT awareness throughout calendar year 2006 would have been very useful. + +== Recommendations for the Future + +The next DST transition in November 2007 is not expected to cause as many problems as was +seen in March 2007, because the remediation already done for March should cover most future +transitions with these new rules. However, it is still possible that some calendaring events and +systems were not correctly or completely updated, so administrators and users should again +check all events due to occur between October 28th and November 4th 2007. These checks +should be done sooner rather than later to avoid the last minute rush to do fixes that we +experienced in March 2007. It is also important to confirm that DST updates have been applied +to systems that were restored to potentially pre-update states or were placed in service after +March 2007. Such systems represent increased risk in environments that do not have strong +patching practices. + +As was noted before, there is still some chance that the DST rules will be "rolled-back" to their +previous definitions if the U.S. Congress determines there was positive effect on energy usage or +conservation. Even if that does not happen, there is no guarantee that it will be another 20 years +before the next U.S. changes are mandated, for whatever reasons. As many other countries, +update their DST rules more frequently than the U.S., it's clear that there needs to be a better +way to manage changes to DST rules. + +To that end, CalConnect's TC-TIMEZONE is developing a recommendations document for a +standard time zone registry that will provide a central, definitive repository of timezone and DST +rules. This ad-hoc committee concurs that setting up such a timezone registry is important, and +should be acted upon as soon as possible. + +The benefits of such a registry are clear - vendors adopting this registry as a source for the +timezone and DST rules can build updating procedures into their products so that future changes +to rules are automatically handled by update processes similar to those already in place. This +avoids the need for each vendor to distribute their own set of patches, and significantly lessens +the support impact that system administrators have in applying those patches. + +There are several hurdles that need to be overcome before such a registry could be viable, and +TC-TIMEZONE's work will attempt to address all of those. In addition, TC-TIMEZONE will +define protocols for a timezone service that can be used as a means to carry out the automatic +update process being proposed. This service would provide access to the timezone registry data +as well as providing other useful features, such as a mechanism for quickly mapping between +earlier timezone identifiers and the new standard form used in the registry. The service could +provide a list of periods covering the date ranges where a timezone or DST rule change will +impact existing data, providing a fast way to evaluate the changes needed to when an update +needs to be applied. + +For significant issues such as timezones, CalConnect should take a more proactive approach +including using its public mailing list for system administrators, +http://lists.calconnect.org/mailman/listinfo/caladmin-l, to provide regular updates on timezone +changes and timezone processing. CalConnect might also consider providing a RSS feed of news +related to calendaring and scheduling. + +== Conclusions + +Timezone processing is intellectually simple but becomes challenging in the context of today's +complex, multi-layered, multi-vendor software environments. It becomes more difficult yet when +we factor in timezone changes and the necessity to maintain interoperability across system, +organizational, and political boundaries. + +Whereas we have made significant progress in identifying and understanding timezone +processing in this context, we have not made enough progress to implementing timezone +processing or accommodating changes to timezones. + +CalConnect believes that establishing an authoritative timezone registry service is the most +important step we can take to provide modern, maintainable timezone processing. diff --git a/sources/cc-0707-edst-reflections-v1/document.adoc b/sources/cc-0707-edst-reflections-v1/document.adoc new file mode 100644 index 0000000..9f9cb8c --- /dev/null +++ b/sources/cc-0707-edst-reflections-v1/document.adoc @@ -0,0 +1,323 @@ += CalConnect EDST Reflections and Recommendations +:docnumber: 0707 +:copyright-year: 2007 +:language: en +:doctype: advisory +:edition: 1 +:status: published +:revdate: 2007-09-14 +:published-date: 2007-09-14 +:technical-committee: DST ADHOC +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Mike Mize +:affiliation: California State University Fresno +:role: editor +:fullname_2: Gary Schwartz +:affiliation_2: Rensselaer Polytechnic Institute +:role_2: editor + +.Foreword +The Calendaring and Scheduling Consortium ("`CalConnect`") is a global +non-profit organization with the aim to facilitate interoperability of +collaborative technologies and tools through open standards. + +CalConnect works closely with international and regional partners, +of which the full list is available on our website +(https://www.calconnect.org/about/liaisons-and-relationships). + +The procedures used to develop this document and those intended for its +further maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different +types of CalConnect documents should be noted. This document was drafted in +accordance with the editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be +held responsible for identifying any or all such patent rights. Details +of any patent rights identified during the development of the document +will be provided in the Introduction. + +//// +TODO: re-enable when we finish the IPR policy +and/or on the CalConnect list of patent +declarations received (see www.calconnect.com/patents). +//// + +Any trade name used in this document is information given for the +convenience of users and does not constitute an endorsement. + +This document was prepared by Technical Committee +_{technical-committee}_. + +This document reviews the impact of implementation of +Extended Daylight Savings Time, which moved the beginning of +DST forward to March 11 in 2007, on the information +technology industry and in particular calendaring and +scheduling systems, and recommendations for what the +industry should do about timezones going forward. + +This document is a follow-on to the advisories and compendium +of fixes which CalConnect collected and published prior to +March 11, 2007. + +== Introduction + +The U.S. Energy Policy Act of 2005 (EPACT 2005), signed by President Bush on August 8, +2005, among its many, many provisions, amends the Uniform Time Act of 1966 by changing the +start and end dates of daylight saving time (DST) in the US. DST begins three weeks earlier and +ends one week later, effective in 2007. DST now begins the second week of March and ends the +first week in November (March 11 and November 4 in 2007). Other areas, including Canada and +Bermuda, also choose to follow the new rules. + +CalConnect, the Calendaring and Scheduling Consortium, has been interested and active in +timezone and DST issues almost since its inception in December 2004. + +In June 2005, CalConnect issued a press release, "EDST Change Untimely" and a "DST +Advisory Notice", both of which "...suggested a simple delay of the effective date (at that point +set to March 2006) of the pending legislation to insure that calendar and scheduling vendors and +consumers have ample time to prepare for any changes." + +In October 2005, CalConnect conducted a timezone survey and issued the "Report on +TIMEZONE Questionnaire Results". + +In May 2006, representatives of CalConnect met with consultants for the Japanese government +which was studying a return to DST. DST has not been observed in Japan since 1952. + +In February 2007, CalConnect issued the press release, "CalConnect Gives Guidance to IT Staff +on Impact of DST Change", published "Extended Daylight Saving Time - Review and +Considerations", and created the "Extended Daylight Saving Time Links, Advisories and +Changes" web page to assist system administrators in tracking vendor updates and DST-related +news and information. + +In August 2007, CalConnect reactivated its `TIMZONE` Technical Committee, which was +originally convened in June 2005. + +CalConnect's "Extended Daylight Saving Time Review and Considerations" promised a future +"Lessons Learned and Recommendations for the Future" document based on real-world +experiences over the transition time in March to the new DST rules". This document fulfills that +promise. + +== Background + +The U.S. Energy Policy Act of 2005 amends the Uniform Time Act of 1966 by changing the +start and end dates of daylight saving time starting in 2007 as noted previously. + +The Uniform Time Act codified daylight saving time (DST) observance within the U.S. Prior to +the act, each state set its own policy for DST observance, and in some cases, which parts of the +state would be affected. The Act originally set the start of DST to be the last Sunday in April, +and was amended in 1986 (effective in 1987) to be the first Sunday in April. + +Whereas this is the first modification to the DST rules in the United States in 20 years, this is not +the only recent change to DST around the globe. Western Australia, Brazil, and the state of +Indiana, among others, also made their own adjustments to DST start and/or end dates within the +last year or so. The things that distinguish the EPACT 2005 changes from the other changes are: + +. The aforementioned more regional DST changes were problematic and difficult in a +number of ways, but the impact of these difficulties was relatively small globally. +. The scope of the EPACT 2005 change is substantially larger, affecting virtually the entire +United States, the third most populous nation in the world, as well Canada and Bermuda. +. The role that the United States plays in international commerce and IT development +makes this change very significant across the globe. +. In the words of Thomas Friedman, "the world is flat", with geo-political borders +becoming less relevant with respect to trade and commerce. Virtually, everyone is doing +business with everyone else. Agreeing globally on dates and times is now essential. +. Mobile devices are pervasive and indispensable today, as are enterprise and web-based +calendaring systems connecting people across time zones, and organizational and +political boundaries Twenty years ago, when the Uniform Time Act was amended in +1986, these things didn't exist or they were an inconsequential novelty. Clearly that is not +the case today. +. Computer systems, networks, applications and other electronic devices used by banks, the +government and industry are dependent on correct date and time information and are far +more widely used than they were when the last change was made in 1986. +. EPACT 2005 requires the Department of Energy to report to the US Congress on the +impact of the DST change on energy usage and/or conservation by the end of 2007. +Congress may revert back to the 1986 DST dates if they choose. There is conflicting +research as to whether daylight saving results in a net energy saving. + +CalConnect's October 2005 "Report on TIMEZONE Questionnaire Results, observed "... a +number of products convert local time information with a supplied timezone into UTC (the +'standard' time reference) as a simplification. As a result of this, timezone information is +effectively lost. Such products will need to determine how to do any adjustment of the UTC +times based on the proposed DST changes." + +CalConnect's February 2007 publication, "Extended Daylight Saving Time - Review and +Considerations" predicted "The impact of the DST changes should be significantly smaller than +Year 2000 (Y2K) but is still a concern for those involved in preparing for the change. Many +systems will be corrected simply by applying automatic updates from the system vendor in +advance of the March 11th deadline. The result of having out of date rules is also smaller, with +systems being off by an hour instead of a hundred years (or failing completely). On the other +hand, there may be significant impact on computer support organizations, especially in cases +where meetings in a calendar system need to be corrected manually." + +== Real-world experiences + +The impact of the earlier DST start date was noticeable but the magnitude of the impact was +generally felt more by larger enterprises than small businesses or home computer users. +Problems were experienced in a number of areas: + +. Small devices or systems did not correctly ascertain and/or display their local time +correctly, usually, but not always, being off by an hour. +. Some already entered/stored dates/times, such as those in a calendaring system, were no +longer correct, again, in most cases being off by an hour. +. Some already entered/stored all day events, were no longer correct, now spanning more +than a single day. +. Synchronization between devices/systems, such as a smart phone and a calendaring +system, resulted in previously correctly stored events now having incorrect times and/or +dates. +. Some users "manually" corrected already entered/stored events which later became +incorrect after software updates were applied which automatically "re-corrected" these +same events. +. A major utility in one of the Western US states, which could not update all of its +electrical meters in time and accepted that there would be some minor accounting +discrepancies for the extended DST period. +. Some enterprise systems could not be automatically remediated with software patches, +requiring end users to "manually" adjust dates/times which were now incorrect. +. In some cases, when reviewing remediated systems for correct results, users mistook +correct time/dates for incorrect values and changed them yet again. + +While most vendors recognized the seriousness of the problem and responded responsibly by +producing patches, conversion tools and workarounds, some problems persisted, and others +actually resulted from these remediation efforts: + +. Some fixes were not available in time for IT staffs to deploy enterprise-wide before the +DST period began. +. Some initial patches were faulty, requiring later "fixes" to the initial fix. +. The sequencing of patches, both chronologically as well as with respect to the application +of other patches, was not well understood or communicated in some cases. +. Some vendors did a better job than others communicating with their customers about +which systems required remediation and how to affect that remediation. + +IT staffs also encountered difficulties, including: + +. Help desks being flooded with end user questions and problem reports. +. Being able to locate and obtain information and updates for all their products and +devices. +. Providing information and instructions to their user communities. +. Finding adequate resources to do all the required remediation. +. Identifying all the devices and systems requiring remediation. +. Remediating systems in the proper sequences and at the correct times. +. Remediating locally developed applications and/or systems. +. Deciding what to do about end-of-life or otherwise no longer supported systems for +which no remediation was available. +. Inadequate coordination and cooperation between units in larger organizations. + +Generally speaking, the media treated the issue without much hype or hysteria, underplaying the +significance if anything, unlike the confusion generated with the Y2K preparations. There were +few "news of the weird" stories generated by the earlier DST start. + +In most cases, remediation of systems as well as any "manual" corrections required, were +accomplished shortly after March 11, 2007. There were virtually no reports of additional +problems on April 1, 2007 the date which DST would have begun under the 1986 rules. + +Many IT staff and end users resorted to Google searches for vendor and more general +information on the DST changes. Although CalConnect did provide a web page, "Extended +Daylight Saving Time Links, Advisories and Changes", there were very few web sites which +served as authoritative clearinghouses of DST information. + +DST-related issues seemed to gain the most traction and awareness within user groups and +professional organizations very close the March 11th date, leaving insufficient time in many +cases for the necessary tasks. + +== Lessons Learned + +The actions required to mitigate problems resulting from EPACT 2005 pointed out a number of +areas where changes needed to be made both in application development and administrative +practice: + +* Date and time information needs to be stored as completely as possible with as few +assumptions about the context as possible. In some cases, incomplete date and time +representation made reliable data conversion impossible. +* Systems and devices need to accommodate timezone and DST changes more easily, +automatically, and correctly. +* Conversion tools, patches and documentation need to be easily accessible. +* Conversion tools, patches and documentation need to be available in a timely manner so +adequate testing can be performed. In many cases, the remediation started too late. +* The interaction between patches, as well as the sequencing of patches, needs to be +understood and clearly communicated. +* System Administrators need to be more familiar with the systems they support and +interactions between those systems. This includes locally developed applications and +systems, and applications elsewhere within the organization. +* Mitigation and remediation need to take place as early as possible using robust tools. +* Relevant and complete information needs to be made available in a timely fashion by +vendors to their customers, and from IT staff to the people and organizations they +support. The information needs to be clear and appropriate for each audience. +* End users need to have a better understanding of the tools they use to perform their jobs. +Knowing what to look for and expect will help when troubleshooting problems, as well +as make them more productive users of these systems. Many users do not use an external +source of authoritative time information and some do not even configure their desktop +computers to the correct tie zone and/or DST settings. Concomitantly, vendors need to +make these things easier to do and to validate. +* Authoritative clearinghouses for situations such as this DST change can be very valuable +but do not always exist, nor do they necessarily materialize in a timely fashion. + +CalConnect's role as a promoter of calendaring and scheduling standards put the consortium in a +unique position. By publishing web pages with both informational articles and links to resources +on publicly-accessible websites, the consortium was able to act as a clearinghouse of DST-related +resources. The consortium also put out informational press releases to both industry and +general news providers. + +However, CalConnect could have made a greater contribution. The consortium was very active +and visible in the last 6 months of 2005, but did not keep the DST-related issues and concerns in +front of the media, the IT profession, or the public again until February 2007. In retrospect, +raising IT awareness throughout calendar year 2006 would have been very useful. + +== Recommendations for the Future + +The next DST transition in November 2007 is not expected to cause as many problems as was +seen in March 2007, simply because the remediation already done covers all future transitions +with these new rules. However, it is still possible that some calendaring events and systems were +not correctly or completely updated, so administrators and users should again check all events +due to occur between October 28th and November 4th 2007, and these checks should be done +sooner rather than later to avoid the last minute rush to do fixes that we experienced in March +2007. + +As was noted before, there is still some chance that the DST rules will be "rolled-back" to their +previous definitions if the U.S. Congress determines there was positive effect on energy usage or +conservation. Even if that does not happen, there is no guarantee that it will be another 20 years +before the next U.S. changes are mandated, for whatever reasons. As many other countries, +update their DST rules more frequently than the U.S., it's clear that there needs to be a better +way to manage changes to DST rules. + +To that end, CalConnect's TC-TIMEZONE is developing a recommendations document for a +standard time zone registry that will provide a central, definitive repository of timezone and DST +rules. This ad-hoc committee concurs that setting up such a timezone registry is important, and +should be acted upon as soon as possible. + +The benefits of such a registry are clear - vendors adopting this registry as a source for the +timezone and DST rules can build updating procedures into their products so that future changes +to rules are automatically handled by update processes similar to those already in place. This +avoids the need for each vendor to distribute their own set of patches, and significantly lessens +the support impact that system administrators have in applying those patches. + +There are several hurdles that need to be overcome before such a registry could be viable, and +TC-TIMEZONE's work will attempt to address all of those. In addition, TC-TIMEZONE will +define protocols for a timezone service that can be used as a means to carry out the automatic +update process being proposed. This service would provide access to the timezone registry data +as well as providing other useful features, such as a mechanism for quickly mapping between +earlier timezone identifiers and the new standard form used in the registry. The service could +provide a list of periods covering the date ranges where a timezone or DST rule change will +impact existing data, providing a fast way to evaluate the changes needed to when an update +needs to be applied. + +For significant issues such as timezones, CalConnect should take a more proactive approach +including using its public mailing list for system administrators, +http://lists.calconnect.org/mailman/listinfo/caladmin-l, to provide regular updates on timezone +changes and timezone processing. CalConnect might also consider providing a RSS feed of news +related to calendaring and scheduling. + +== Conclusions + +Timezone processing is intellectually simple but becomes challenging in the context of today's +complex, multi-layered, multi-vendor software environments. It becomes more difficult yet when +we factor in timezone changes and the necessity to maintain interoperability across system, +organizational, and political boundaries. + +Whereas we have made significant progress in identifying and understanding timezone +processing in this context, we have not made enough progress to implementing timezone +processing or accommodating changes to timezones. + +CalConnect believes that establishing an authoritative timezone registry service is the most +important step we can take to provide modern, maintainable timezone processing. diff --git a/sources/cc-0708-dst-review/document.adoc b/sources/cc-0708-dst-review/document.adoc new file mode 100644 index 0000000..5d01af6 --- /dev/null +++ b/sources/cc-0708-dst-review/document.adoc @@ -0,0 +1,175 @@ += Extended Daylight Savings Time Review and Considerations +:docnumber: 0708 +:title-main-en: A Review of the Potential Impact of Daylight Saving Time Changes in 2007 -- A Reference for Users and Systems Administrators +:copyright-year: 2007 +:language: en +:doctype: report +:edition: 1 +:status: published +:revdate: 2007-02-15 +:published-date: 2007-02-15 +:technical-committee: DST ADHOC +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Joseph Jackson +:role: author +:affiliation: Carnegie Mellon University + +== Introduction + +The year 2007 brings with it a change in Daylight Saving Time (DST) rules. A provision of +the Energy Policy Act of 2005 changed DST to begin three weeks earlier and end one +week later, effective in 2007. Starting this year, DST will begin the second week of March +and end the first week in November (March 11 and November 4 in 2007). This is the first +modification to the DST rules in the United States in 20 years. Other areas that follow US +DST rules, including Canada and Bermuda but not Mexico, are similarly affected. + +The time of day that we begin and end observing Daylight Saving Time has not changed; in +the United States DST still begins at 2:00 am standard time in the spring, when clocks are +set forward to 3:00 am, and ends at 2:00 am daylight saving time in the fall, when clocks +are set back to 1:00 am. + +This document outlines the impact of the DST change on computer systems and devices. +The goal is to raise awareness for users and in particular system administrators so they +understand the potential impact of the DST changes and can take request or take action to +avoid problems related to the change. There are two major recommendations: + +* Apply system patches to implement the new DST starting and ending dates +* Consider whether corrections are needed to systems that store date/time values, +such as calendar software or spreadsheets + +The sections below go into more detail on each issue. A companion document contains a +collection of links to vendor web pages where DST updates are discussed and patches are +offered. + +The change in DST rules will remind some of the Year 2000 (Y2K) problems in programs +that referred to a year using two digits. The impact of the DST changes should be +significantly smaller but is still a concern for those involved in preparing for the change. +Many systems will be corrected simply by applying automatic updates from the system +vendor in advance of the March 11th deadline. The result of having out of date rules is also +smaller, with systems being off by an hour instead of a hundred years (or failing +completely). On the other hand, there may be significant impact on computer support +organizations, especially in cases where meetings in a calendar system need to be +corrected manually. + +== System Clock Updates + +Issue:: Systems or devices that include a date/time clock that adjusts ahead and back +automatically for Daylight Saving Time use rules to decide when to switch from Standard +Time to Daylight Saving Time. These rules need to be updated, where possible. + +Recommendation:: If you maintain computer devices or systems with DST-aware clocks, +locate and apply any updates related to the new DST rules. This applies to personal +computers, servers, handheld computing devices, phones, and embedded devices such as +automatic door lock systems. + +Impact:: Systems that aren't updated will have their clocks set one hour slow during the four +weeks covered by the extended DST period. In addition to the clock display being wrong, it +could cause confusion in cases where the time is reflected externally. Here are a few +examples: + +* Outgoing mail messages will be given an incorrect time stamp and incoming +messages may have their time stamps incorrectly interpreted. +* Systems using older versions of Kerberos authentication may have problems if users +have manually adjusted their system clock to compensate for the incorrect DST rules. +UTC time stamps are involved in the original versions of the protocol, requiring clocks +to be synchronized to within a few minutes. +* Processes that run at a preset time, such as unlocking a door or sending a data file to +another computer for processing, may happen an hour later than expected. + +== Network Time Protocol (NTP) + +Issue:: Most recent operating systems include support for the Network Time Protocol +(NTP), meaning they can synchronize the local clock to a time server over the network. For +example, Apple and Microsoft both provide NTP servers on the Internet that their systems +can use. Note, however, that time zone information is not updated through NTP. Time is +synchronized in terms of Coordinated Universal Time (UTC) so time zones don't factor into +NTP at all. + +Recommendation:: If a computer hasn't been updated with the new DST starting and +ending dates, users may be tempted to manually set the clock to compensate. This won't +be effective for very long if the computer is synchronizing its time to a time server, since the +clock will soon revert back to the way it was. If the new DST rules can't be applied by a +software update, a better work-around is to change the time zone setting, not the time. +Choosing the time zone to your east will normally achieve the desired result and will remain +correct even if your clock is being synchronized over the network. After the extended DST +weeks are over, the time zone will need to be put back to the normal setting. + +== Stored date/time values + +Issue:: Many computer systems need to represent future dates and times. A calendar +system where you can schedule meetings and other events is a good example. Depending +on how the system stores the date/time values, there may be a need to make corrections to +accommodate the new DST rules. ++ +-- +In particular, if the system stores the date and time as a combined value that is relative to +Universal Time (UTC), then the data in the system may be off by an hour for the parts of +the year that used to be in standard time but are now in daylight saving time. An example +may help explain why changes are needed: + +[example] +==== +Let's say you're in the Eastern time zone. If you entered a repeating meeting for +9:00 am every Monday, the system would store it as 14:00 UTC for weeks +outside of DST and 13:00 UTC for weeks inside DST. The system takes care of +the translation to UTC for you, so you might not even be aware that it's +happening. If the old rules were in effect when you entered the weekly meeting, +it would use the 14:00 UTC values for late March dates. Under the 2007 DST +rules, those need to be stored as 13:00 UTC in order to show up at 9:00 am +Eastern. The recorded events in your system need to be adjusted back one +hour. +==== +-- + +Recommendation:: For third-party software, contact the vendor to find out if the product is +affected by the DST change. Systems that store date/times relative to the local time zone +are not likely to be impacted but products that support multiple time zones will often require +remediation. For solutions developed in-house, consider the places where date and time +values are stored as one field in a format relative to UTC. + +Impact:: Systems that store date/time values relative to UTC will display incorrect times +within the three weeks in spring and one week in fall that are now part of DST. In particular, +the time shown will be one hour later than intended. This will affect events not only in 2007, +but in any future year as well. ++ +-- +Some calendar systems store day-long events internally as midnight to midnight records. +These may get shifted by one hour during the new DST weeks, causing the events to +extend into the day after they were intended to finish. + +Other unexpected behavior may occur with calendar systems that synchronize events +between two or more types of devices, such as a computer and a smart phone. The exact +symptoms will depend on how each devices stores date/time values and how those values +are represented by the synchronization software. +-- + +== Companion Document + +The companion document to this review, Extended Daylight Savings Time Links, Advisories +and Changes, offers a collection of links to vendor web pages where DST updates are +discussed and patches are offered. + +== Future Documents + +It is the intent of The Calendaring and Scheduling Consortium to publish a "Lessons +Learned and Recommendations for the Future" document based on real-world experiences +over the transition time in March to the new DST rules. The document should be available +in late spring or early summer. + +== Credits + +Joseph Jackson, Author + +Computing Services + +Carnegie Mellon University + +Chair, DST Ad Hoc Working Group, The Calendaring and Scheduling Consortium + +//// +== Copyright Statement + +This document is (C)2007, The Calendaring and Scheduling Consortium. Permission is +granted to viewers to quote or republish this document in whole or in part so long as credit +is given to the Consortium, a link is provided to the Consortium website, and the quoted or +republished material is not modified in any way. +//// diff --git a/sources/cc-0709-dst-links/document.adoc b/sources/cc-0709-dst-links/document.adoc new file mode 100644 index 0000000..18f0ddd --- /dev/null +++ b/sources/cc-0709-dst-links/document.adoc @@ -0,0 +1,422 @@ += Extended Daylight Savings Time Links, Advisories and Changes +:docnumber: 0709 +:title-main-en: Links to Advisory and Vendor Material on the Daylight Saving Time Changes in 2007 -- A Reference for Users and Systems Administrators +:copyright-year: 2007 +:language: en +:doctype: advisory +:edition: 1 +:status: published +:revdate: 2007-10-06 +:published-date: 2007-10-06 +:technical-committee: DST ADHOC +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + +.Foreword + +The links below are not exhaustive and may become out of date as vendors update the +available information. If you have references to official documentation for vendors not listed +below or notice a problem with one of the links, please send your updates to DST Referrals and +we will attempt to include them as soon as possible. + +[CAUTION,type=disclaimer] +==== +This document is provided for informational purposes only and does not represent +an endorsement or statement of support by The Calendaring and Scheduling Consortium for +any of the products mentioned. The omission of any product or products represents only a lack +of information rather than any bias against or deprecation of that product or products. The +Consortium is not responsible for any results or consequences of any sort as a result of +following any advice or performing any actions recommended in this material. +==== + +== Daylight Saving Time Information and History + +* http://en.wikipedia.org/wiki/Daylight_saving_time[Daylight Saving Time from Wikipedia, the free encyclopedia.] + +* http://webexhibits.org/daylightsaving/index.html[About Daylight Saving Time - History, rationale, laws & dates.] + +* http://tf.nist.gov/timefreq/general/dst.htm[How the DST change impacts NIST Time Services, including WWVB radio broadcast and their Internet Time Service] + +* CalConnect EDST Reflections and Recommendations: ++ +-- +Reflections on how well the transition to EDST happened on March 11, together with +recommendations for the transition on November 4 and future years, and longer-term +recommendations for timezone management in general. +-- + +== CalConnect Daylight Saving Time Documents and Resources + +The following pages and documents on Daylight Saving Time and Extended DST have +been published by CalConnect: + +* CalConnect EDST Reflections and Recommendations: ++ +-- +Post March 2007 discussion of how well the transition to EDST went; recommendations for +November 4 and long-term recommendations for timezone management. +-- +* Extended Daylight Saving Time Review and Considerations: ++ +-- +Introductory discussion of Extended DST and the implications for the software changes and +patches required. +-- +* Extended Daylight Saving Time Links, Advisories and Changes: ++ +-- +This document; a compilation of links about DST and EDST, advisory notices, necessary +changes and patches offered by software vendors and others. +-- +* Extended Daylight Saving Time Advisory Notice: ++ +-- +The original advisory notice issued by CalConnect in June 2005 in response to the legislation +creating EDST. +-- + +== Vendor Information + +In each entry below, the URL of the link is provided, along with the official title of that web page +as provided by the vendor. Comments by CalConnect providing the context for the material on +the page are provided in italics immediately after the title of the page. + +=== Apache and Tomcat + +http://blog.covalent.net/roller/covalent/entry/2[US Daylight Saving Time Change 2007 Effects on Apache and Tomcat] + +_Covalent Technologies advisories for users of Apache and Tomcat_ + +=== Apple + +http://docs.info.apple.com/article.html?artnum=305056[About Daylight Saving Time changes in 2007] + +_This document itemizes several updates from Apple for the very latest DST changes. Updates +for Mac OS X 10.3, 10.4, their Java environments, and WebObjects will be offered via Software +Update or direct download. Information on Classic and Mac OS 9 is also provided in the +document. Note that the US DST changes were included in Mac OS X 10.4.5 and later, but +further changes for Alberta, Canada and other parts of the world are included in these updates. +The unofficial patches for 10.3 are no longer necessary since Apple is now offering them with +this set of updates._ + +=== Avaya +http://support.avaya.com/japple/css/japple?PAGE=OpenPage&temp.template.name=Daylight[2007 Daylight Saving Time Changes] + +_Comprehensive listing of fixes for Avaya's IP telephony product line_ + +=== Bedework + +http://www.bedework.org/bedework/update.do?artcenterkey=69[Bedework and the Energy Policy Act of 2005] + +_Bedework is an open-source institutional calendar system_ + +=== Blackberry + +http://www.blackberry.com/select/dst2007/[Daylight Saving Time 2007] + +_Impact of DST changes on Blackberry devices and BlackBerry Enterprise Server_ + +http://www.blackberry.com/DST2007/patch/index2.shtml[DST 2007 Patches for BlackBerry Devices] + +_This page explains the download process for BlackBerry handhelds_ + +=== Cisco + +http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a00807ca437.shtml[U.S. Daylight Saving Time (DST) Changes for 2007] + +_Comprehensive information on actions required for Cisco products_ + +=== Citrix + +http://support.citrix.com/article/CTX111734&searchID=39611352[Daylight-saving Time Changes in 2007] + +_Describes the EDST changes and the products that require updates_ + +=== Debian GNU/Linux + +http://www.debian.org/News/2007/20070218[Debian GNU/Linux 3.1 updated] + +_The change log for 3.1r5 indicates that the time zone rules were updated to "2006p-1", including +new rules for the United States and West Australia_ + +=== Enterasys + +http://secure.enterasys.com/services/support/daylight_savings.html[Enterasys Technical Notification Regarding Changes to US Daylight Savings Time Observance] + +_Summary of changes to DST, identifies Enterasys products and required actions_ + +=== Good Technology Inc. + +_See <>._ + +=== Google + +http://www.google.com/support/calendar/bin/answer.py?answer=61026&topic=8580[Are my events in Google Calendar affected by the Daylight Savings Time change in 2007?] + +_Advisory for users of Google Calendar_ + +http://www.google.com/support/calendar/bin/answer.py?answer=55677[Known Issues & Feature Updates] + +_More general issues and feature updates for Google Calendar_ + +=== Hitachi Data Systems + +http://www.hds.com/pdf/hds_dst_impact.pdf[Extended Daylight Saving Time Product Impact Alert] + +_Notification of DST impact on hardware and software products from HDS and their partners_ + +=== HP + +http://h10072.www1.hp.com/dst[U.S. 2007 Daylight Saving Time] + +_Revised and more complete information on HP systems and related software_ + +=== IBM + +http://www.ibm.com/support/alerts/us/en/daylightsavingstimealert.html[IBM-wide product alerts] + +_Update information is organized by categories of products_ + +=== Juniper + +http://kb.juniper.net/KB9358[2007 Daylight Savings Changes and Support for Juniper Products] + +_A listing of technical bulletins that address the DST issue in Juniper products_ + +=== Kerberos from MIT + +http://confab.mit.edu/confluence/display/ISDA/Kerberos-2007-DST[Kerberos-2007-DST] + +_Comments for KDC administrators regarding the time synchronization requirements and +features in Kerberos as implemented by MIT_ + +=== Kerio Technologies + +http://support.kerio.com/kb/454[Does KMS Support Daylight Saving Time for 2007] + +_Statement of compliance for Kerio Mailserver 6.3.0 and higher; links for underlying +OS changes which must be done manually_ + +=== Microsoft + +http://www.microsoft.com/time[Daylight Saving Time Help and Support Center] + +_Comprehensive document regarding the DST issue with pointers to other knowledge base +articles and patches_ + +http://support.microsoft.com/gp/dst_prodlist[List of Microsoft products affected by daylight saving time and time zone changes] + +_Comprehensive index of Microsoft products and links to latest updates for Microsoft Windows +and other products, including the current version of the Microsoft Office Time Zone Data Update +Tool_ + +http://www.windowsmobile.com/daylightsaving/[Daylight Saving Time 2007 Update] + +_Updates for handheld devices (PDAs) running Windows +Mobile. See also <> if your handheld is made by Palm._ + +http://blogs.msdn.com/macmojo/archive/2007/01/10/the-times-they-are-a-changin.aspx[The Office for Mac Team Blog entry] + +=== Microsoft-Related (Third Party) + +http://blogs.technet.com/amir/archive/2007/01/31/dst-2007-changes-entourage-2004-for-mac.aspx[DST 2007 Changes & Entourage 2004 for Mac] + +_Not an official support document, but useful information posted on Amir's Exchange Clients Blog_ + +http://www.intelliadmin.com/blog/2007/01/unofficial-windows-2000-daylight.html[IntelliAdmin: Unofficial Windows 2000 Daylight Saving Time Patch] + +_Microsoft is not providing an update to Windows 2000 for extended DST but has outlined a +multi-step procedure which involves updating the registry. IntelliAdmin created this unofficial +utility program to automate the procedure recommended by Microsoft._ + +http://www.sharpebusinesssolutions.com/dst2007.htm[DST Update Tool for Windows from NT4 through Server 2003 and XP] + +_A global update solution from Sharpe Business Solutions for most versions of windows from NT +4 and Win2KPRO through WinXP. This is a product._ + +http://solprovider.com/articles/win98timezones[Fixing Windows 98 TimeZones for the New 2007 Daylight Saving Time Rules] + +_An unofficial fix from SolProvider for extended DST for Windows 98 and a companion way to set +the system back to the old rules (in case Congress changes its mind because the expected +benefits from the change don't actually occur)._ + +http://blogs.technet.com/hied_west_blog/archive/2007/02/20/dst-2007-update-step-by-step-support-webcast-training.aspx[DST 2007 Update: "Step by Step" Support Webcast Training] + +_Another Microsoft blog with references to several helpful official and unofficial DST resources_ + +[[motorola]] +=== Motorola Good Technology Group + +http://www.good.com/faq/17882.html[Daylight Savings Time Adjustment 2007] + +_Provides detailed information on addressing DST in Good's products and on other DST-related +issues_ + +=== Mulberry + +http://www.mulberrymail.com[The Mulberry email and calendar client has recently been updated to a new version v4.0.8 to address the upcoming Extended Daylight Saving Time changes.] + +_Mulberry will attempt to automatically upgrade existing timezones to the new rules when run. +Anyone using the calendaring features of Mulberry should upgrade to this new release right +away._ + +=== Nokia + +http://europe.nokia.com/A4143002[Product Support and Software - Europe] + +_DST updaters are listed in the "Latest Software" for several Nokia phones. This is for European +customers._ + +http://www.nokiausa.com/support/software/softwareupdate/1,8838,,00.html[Phone Software Update (USA)] + +_Windows software to download updates from Nokia and apply them to a phone. For United +States customers._ + +=== Notify Technology Corp + +http://notifylink.notify.net/download/DST%202007%20Adjustments.pdf[2007 Daylight Saving Time Changes: Transition for NotifyLink Users] + +_Instructions for NotifyLink fixes and suggestions for calendar server and mobile device patches +to apply_ + +=== Novell + +http://www.novell.com/coolsolutions/feature/18566.html[Daylight Saving Time Change Impacts GroupWise Appointments] + +_Automated Tool to Address Daylight Saving Time Impact on GroupWise Appointments_ + +http://www.novell.com/support/search.do?cmd=displayKC&sliceId=%3Cbr%3ESAL_Public&externalId=3397648[Netware Servers] + +_This link was not working on 4 October_ + +=== Oracle + +http://www.oracle.com/support/daylight-savings.html[Daylight Savings Time Alert for Oracle Customers] + +_This is an open page and does not require a MetaLink account to access it_ + +=== Packeteer + +http://packeteer.custhelp.com/cgi-bin/packeteer.cfg/php/enduser/std_adp.php?p_faqid=1178&p_created=1169227986&p_sid=1WoDpILi&p_accessibility=0&p_redirect=&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9NDImcF9wcm9kcz0mcF9jYXRzPSZwX3B2PSZwX2N2PSZwX3BhZ2U9MSZwX3NlYXJjaF90ZXh0PWRheWxpZ2h0&p_li=&p_topview=1[Daylight Saving Time Change in 2007] + +_Update and configuration instructions for Packeteer products_ + +[[palm]] +=== Palm + +http://www.palm.com/us/support/downloads/dst.html[Daylight Saving Time Updates] + +_Updates for both Palm and Windows Mobile handheld devices from Palm_ + +=== PeopleCube + +http://peoplecube.com/news/20061218.cfm[PeopleCube Announces New Version of Meeting Maker] + +_Meeting Maker 8.6 includes support for new DST regulations_ + +http://www.peoplecube.com/news/20061016.cfm[PeopleCube Announces New Version of Resource Scheduler] + +_Resource Scheduler 7.7 includes new DST rules_ + +=== PeopleSoft + +ftp://ftp.peoplesoft.com/incoming/GSC/DST/PeopleTools_DST.pdf[PeopleTools Daylight Saving Time Required Modifications] + +_Advisory for PeopleTools Products_ + +ftp://ftp.peoplesoft.com/incoming/GSC/DST/PeopleTools%20Vendor%20Daylight%20Saving%20Time%20Information.pdf[PeopleTools Vendor Daylight Saving Time Required Modifications] + +_Advisory for Third Party (Vendor) Applications_ + +=== Polycom + +http://www.polycom.com/common/documents/support/downloads/network/readimanager_se200_daylight_savings_time_patch_release_notes.pdf[ReadiManager SE200 Patch Release Notes] + +_Patch instructions for the ReadiManager SE200 embedded Microsoft OS_ + +=== Psion Teklogix + +http://www.psionteklogix.com/public.aspx?s=us&p=DST[Daylight Savings Time Changes and Support Information] + +_Updates for Psion Teklogix industrial mobile devices_ + +=== Red Hat + +http://kbase.redhat.com/faq/FAQ_80_7909.shtm[Red Hat Knowledgebase Article ID 7909] + +_DST updates available for Red Hat Enterprise Linux 2, 3, 4, and related links_ + +=== Snap Server by Adaptec + +http://www.snapserver.com/Landing/0702_Daylight/Index.shtml[Ensure Your Snap Server is Ready for Daylight Saving Time] + +_Guidance for users of Adaptec's line of Snap Server Network Attached Storage and SAN +Devices_ + +=== Sun + +http://www.sun.com/bigadmin/hubs/dst/[DST: Daylight Saving Time Changes (2007)] + +_A central index of DST change information for Sun products, both software and hardware_ + +http://java.sun.com/developer/technicalArticles/Intl/USDST/[Overview and Mitigation of the USA2007DST Issue for the Java SE platform and Solaris OS] + +_A listing of which Java run time environments have updated DST rules_ + +http://java.sun.com/developer/technicalArticles/Intl/tzupdatertool.html[Sun Java SE JDK tzupdater Tool] + +_A tool for updating time zone data in JDK and JRE version 1.4 and later_ + +=== Symantec + +http://service1.symantec.com/SUPPORT/tsgeninfo.nsf/docid/2007011911191539?Open&src=w[Symantec enterprise products and daylight saving time] + +_This page provides links to documents for each Symantec product indicating whether each +product is affected by the change to daylight saving time, and if so, how._ + +=== Trumba + +http://www.trumba.com/help/trumbafaq.html#dst[Trumba Connect Frequently Asked Questions] + +_DST changes will be applied behind the scenes by Trumba_ + +=== VMWare + +http://kb.vmware.com/kb/8695824[2007 U.S. Daylight-Saving Time Extension] + +_Updates for ESX Server 2.x and 3.0.x_ + +=== Xerox + +http://www.xerox.com/go/xrx/portal/STServlet?projectID=ST_DST&pageID=DST_Landing&Xcntry=USA&Xlang=en_US[Updating Xerox Products for Daylight Saving Time] + +_Links to instructions for updating Xerox products_ + +== Companion Document + +The companion page to this one, Extended Daylight Saving Time Review and Considerations, +provides a review of the Daylight Saving Time changes and the potential impact of this change +on computer systems and devices. It is intended as a review and reference for users and in +particular for systems administrators who may need to make necessary updates to their +systems. + +== Future Documents and Proposals + +CalConnect plans to update this page as information becomes available prior to November +4th. Following November 4 an update to CalConnect EDST Reflections and Recommendations +may be prepared to take into account additional information from the November transition. + +CalConnect has also initiated work in TC TIMEZONE, one of its Technical Committees, on +proposals for a formal, universal Timezone Registry and a companion Timezone Service +protocol, intended to make the management of timezones (and related phenomena such as +DST) substantially easier in the future. + +//// +== Copyright Statement + +This document is (C)2007, The Calendaring and Scheduling Consortium. Permission is granted to +viewers to quote or republish this document in whole or in part so long as credit is given to the +Consortium, a link is provided to the Consortium website, and the quoted or republished +material is not modified in any way. +//// diff --git a/sources/cc-0710-report-ioptest/document.adoc b/sources/cc-0710-report-ioptest/document.adoc new file mode 100644 index 0000000..1ec0709 --- /dev/null +++ b/sources/cc-0710-report-ioptest/document.adoc @@ -0,0 +1,664 @@ += September 2007 CalConnect Interoperability Test Report +:docnumber: 0710 +:copyright-year: 2007 +:language: en +:doctype: administrative +:edition: 2 +:status: published +:revdate: 2007-12-14 +:published-date: 2007-12-14 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Patricia Egen +:role: author +:fullname_2: Tony Becker +:role_2: author +:fullname_3: Cyrus Daboo +:role_3: author +:fullname_4: Mike Douglass +:role_4: author +:fullname_5: Tomas Hnetila +:role_5: author +:fullname_6: Bill Le +:role_6: author +:fullname_7: Brian Moseley +:role_7: author +:fullname_8: Clint Talbert +:role_8: author + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Introduction + +This document contains notes and results from the September 2007 calendar interoperability event, +sponsored by MIT, held in Boston, MA. The basic purpose of the event was to test CALDAV Free Busy +and Scheduling and iCalendar iMIP and iTIP events. + +The chart below shows the attendees, their organization and the products they were testing. + +=== Attendees + +[%unnumbered,options=header] +|=== +| Attendees | Organization | Products | Version +| Cyrus Daboo | Apple | Apple Client and CalDAV server | 9A527 +| Bill Le | IBM | IBM Notes and Domino calendar clients | 8.01 +| Frank Pavelski | IBM | | +| Tomas Hnetila | Kerio | Kerio CalDAV server and client | +| Stepan Potys | Kerio | | +| Tony Becker | Marware | Marware Calendar, Project X | 1.2 +| Philipp Kewisch | Mozilla | Sunbird and Lightning Calendar clients | 0.7 +| Client Talbert | Mozilla | | +| Kervin Pierre | Open Connector + +Groupware | | +| Simon Vaillancourt | Oracle | Oracle CalDAV Server | +| Mikeal Rogers | OSAF | Cosmo CalDAV server and Chandler Client | 0.7.0.1 +| Brian Moseley | OSAF | | +| Michael Douglass | RPI | bedework CalDAV Server | +|=== + +== General Comments + +The following are notes from the testing event. Vendors are flagged as A, B, C, etc. to keep the details +private, but to reflect the kinds of problems noted during testing. + +The following table is the testing script used for CalDAV testing. Comments below will make reference to +the numbers corresponding to this table. + +[cols="a,a"] +.CalDAV Testing Scenarios +|=== +h| 1. h| Event creation. +| 1.1. | Create new single-instance meeting titled "Meeting 1.1" with the location "Durham". +| 1.2. | Create new meeting titled "Meeting 1.2" recurring every Monday from 10:00 AM to 11:00 AM for 4 weeks. +| 1.3. | Create new single-instance meeting titled "Meeting 1.3" with 2 other attendees. +| 1.4. | Create new single-instance meeting titled "Meeting 1.4" with an alarm set to trigger 15 minutes prior to the schedule time of the meeting. +h| 2. h| Event modification +| 2.1. | Modify the title of meeting "Meeting 1.1" to "Meeting 1.1bis". +| 2.2. | Modify the location of the meeting "Meeting 1.1bis" to "Seattle bis". +| 2.3. | Reschedule meeting "Meeting 1.1bis" to the next day. +| 2.4. | Add an attendee to "Meeting 1.1bis". +| 2.5. | Add an alarm to "Meeting 1.1bis". +| 2.6. | Modify the title of the 1st instance of the recurring meeting created in 1.2. +| 2.7. | Modify the participation status of the 1st attendee in meeting 1.3 to `DECLINED`. +| 2.8. | Cancel the 4th instance of the recurring meeting created in 1.2. +| 2.9. | One client changes "Meeting 1.1bis" to a different time, second client 'refreshes' its display to see the modification. +h| 3. h| Event retrieval +| 3.1. | calendar-query `REPORT` +| 3.1.1. | No filtering (match everything) +| 3.1.1.1. | Query all components and return all data. (tests `` and ``) +| 3.1.1.2. | Query all components and return ETag WebDAV property and all data. (tests `+` and ``) +| 3.1.1.3. | Query all components and return just entire `VEVENT` components. (tests ``, `+`) +| 3.1.1.4. | Query all components and return `VEVENT` components with only `DTSTART`, `DTEND/DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `+`, `++`) +| 3.1.2. | time-range filtering +| 3.1.2.1. | Query all components within a one day time-range and return all data. Make sure that there is a recurring event that starts prior to the chosen time-range but has one non-overridden instance within the time-range. (tests ``, `+`) +| 3.1.2.2. | Query all components within a one week time-range and return just entire `VEVENT` components. Make sure that there is a recurring event that starts prior to the chosen time-range but has one overridden instance within the time-range. (tests ``, `+`) +| 3.1.3. | component based filtering +| 3.1.3.1. | Query all components that contain an embedded `VALARM` component. (tests ``, `+`) +| 3.1.3.2. | Query all components that contain an embedded `VALARM` component whose trigger falls within a specific time-range. (tests ``, `+++`) +| 3.1.4. | property based filtering +| 3.1.4.1. | Query all components that contain any `ORGANIZER` property. (tests ``, `++`) +| 3.1.4.2. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-insensitively. (tests ``, `+++`) +| 3.1.4.3. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-senstively. (tests ``, `+++`) +| 3.1.5. | parameter based filtering +| 3.1.5.1. | Query all components that contain a `DTSTART` property with a `TZID` parameter. (tests ``, `++++`) +| 3.1.5.2. | Query all components that contain an `ATTENDEE` property with `PARTSTAT=NEEDS-ACTION` parameter. (tests ``, `++++`) +| 3.2. | calendar-multiget `REPORT` +| 3.2.1. | Query a specific href and return all data. (tests ``) +| 3.2.2. | Query multiple hrefs (some of which do not exist) and return all data. (tests ``) +| 3.2.3. | Query a specific href and return ETag WebDAV property and all data. (tests `+`) +| 3.2.4. | Query multiple hrefs (some of which do not exist) and return ETag WebDAV property and all data. (tests `+`) +| 3.2.5. | Query a specific href and return `VEVENT` components with only `DTSTART`, `DTEND/DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) +| 3.2.6. | Query multiple hrefs (some of which do not exist) and return `VEVENT` components with only `DTSTART`, `DTEND/DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) + +h| 4. h| Event deletion +| 4.1. | Delete a single non-recurring meeting. +| 4.2. | Delete a single recurring meeting with no overridden instances. +| 4.3. | Delete a single recurring meeting with overridden instances. +| 4.4. | Delete a non-overridden instance of a recurring meeting. +| 4.5. | Delete an overridden instance of a recurring meeting. + +h| 5. h| Access Control +| 5.1. | View access control details on current user's main calendar. +| 5.2. | Change access control details on current user's main calendar to add another user with read-only access. Verify that other user can view the calendar but not change it. +| 5.3. | Change access control details on current user's main calendar to add another user with read-write access. Verify that other user can view the calendar and change it. Verify that changes done by one user are seen by the other. +| 5.4. | Remove another user's access to the current user's main calendar and verify they can no longer access the calendar. + +h| 6. h| Calendar Management +| 6.1 | Browse the list of calendars on the server, including the current user's personal calendars. +| 6.2 | Create a new calendar in the current user's personal calendar space. +| 6.3 | Create a regular collection in the current user's personal calendar space. +| 6.4 | Create a new calendar inside the collection created in 6.3. +| 6.5 | Delete the calendar created in 6.2. +| 6.6 | Delete the collection created in 6.3. + +h| 7. h| Free Busy Reports +| Setup | Create a new calendar and populate it with the following for one week: + +Event on Monday, 9 am - 11 am, recurs every day for five times + +Event on Monday, 12 pm - 1 pm, status tentative + +Event on Monday, 2 pm - 3 pm, status cancelled + +Event on Tuesday, 11 am - 12 pm + +Event on Tuesday, 2 pm - 4 pm, recurs every day for four times + +Event on Tuesday, 3 pm - 5 pm + +Event on Wednesday, 11 am - 12 pm, status tentative + +Event on Wednesday, 3 pm - 5 pm, status tentative + +Event on Thursday, 11 am - 12 pm, status cancelled + +Event on Thursday, 3 pm - 5 pm, status cancelled +| 7.1 | Run a free-busy report for the entire week. +| 7.1.1 | Verify two `FREEBUSY` periods for Monday, the second is `BUSY-TENTATIVE`. +| 7.1.2 | Verify two `FREEBUSY` periods for Tuesday. +| 7.1.3 | Verify four `FREEBUSY` periods for Wednesday, second and fourth are `BUSY-TENTATIVE` and one hour long. +| 7.1.4 | Verify two `FREEBUSY` periods for Thursday. +| 7.1.5 | Verify two `FREEBUSY` periods for Friday. + +h| 8. h| Scheduling +| Setup | Three user accounts user1 (role Organizer), user2 (role Attendee), user3 (role Attendee) provisioned with suitable principal properties for calendar home, inbox, outbox and user addresses. +| 8.1 | Organizer (user1) sends non-recurring message invite for Monday at 9am (1 hour) to each attendee. Verify that each attendee Inbox receives a copy of the invite. +| 8.2 | Attendee (user2) accepts invite and sends back reply. Verify that reply is placed in Organizer Inbox. +| 8.3 | Organizer (user1) updates invite with user2 accept state and resends invite. Verify that each attendee Inbox receives a copy of the new invite. +| 8.4 | Attendee (user3) accepts updated invite and sends back reply. Verify that reply is placed in Organizer Inbox. +| 8.5 | Organizer (user1) updates invite with user3 accept state and resends invite. Verify that each attendee Inbox receives a copy of the new invite. +| 8.6 | Organizer (user1) cancels the invite. Verify that each attendee Inbox receives the cancellation. +|=== + +=== Vendor A Testing + +Vendor A testing found some minor issues. Client testing focused on interoperability with other servers. + +In some cases we were not able to get past the account setup stage, in others we were able to test +access and scheduling features. The account setup problem was debugged and a working copy with a fix +was then used to test further. + +Overall the interoperability event was very useful to us (as it always is) and we are looking forward to the +next one. + +=== Vendor B Testing + +The following is a summary of Vendor B's testing. + +==== Vendor 1 testing + +Issues found: + +* vendor deletes meeting response from various clients, because there isn't a correct `SEQUENCE` +number +* One vendor doesn't recognize meeting requests caused by TIMEZONE definition -- see example: ++ +-- +[example] +==== +[source%unnumbered] +---- +BEGIN:VTIMEZONE +TZID:US/Eastern +* BEGIN:STANDARD +* TZOFFSETFROM:-0400 +* TZOFFSETTO:-0500 +* DTSTART:19551030T020000 +* RRULE:FREQ=YEARLY;UNTIL=20061029T060000Z;BYMONTH=10;BYDAY=-1SU +* TZNAME:EST +* END:STANDARD +BEGIN:DAYLIGHT +TZOFFSETFROM:-0500 +TZOFFSETTO:-0400 +DTSTART:20070311T020000 +RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU +TZNAME:EDT +END:DAYLIGHT +BEGIN:STANDARD +TZOFFSETFROM:-0400 +TZOFFSETTO:-0500 +DTSTART:20071104T020000 +RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU +TZNAME:EST +END:STANDARD +END:VTIMEZONE +---- +==== +-- +* Meeting request from one vendor is silently deleted from CalDAV scheduling `INBOX` by another +vendor probably caused by a bug in that vendors application +* iMIP meeting request from one client is not visible in CalDAV `INBOX` +* One client Error message "Request error - Calendar not found" appears when user creates new +calendar +* Calendar is successfully created on the server, but the error message appears +* One client's provides incorrect free/busy (organizer and attendee are swapped) +* Free/Busy - Problem with case sensitive `MAILTO` - FIXED + +Test result: + +* 1.1 Ok +* 1.2 Ok +* 1.3 Ok +* 1.4 Ok +* 2.1 Ok +* 2.2 Ok +* 2.3 Ok +* 2.4 Ok +* 2.5 Ok +* 2.6 stored on the server, but some apps aren't able to display this exception +* 2.7 Ok +* 2.8 Ok +* 2.9 Ok +* 3.* Not tested +* 4.1 Ok +* 4.2 Ok +* 4.3 Ok +* 4.4 Ok +* 4.5 Ok +* 5.* Not tested +* 6.1 Ok +* 6.2 There is a problem when one application creates calendar on a CalDAV. Calendar is created, but +other app reports - "Request error - Calendar not found". +* 6.3 N/A - app doesn't support it +* 6.4 N/A - app doesn't support it +* 6.5 Ok +* 6.6 N/A - app doesn't support it +* 7.* Not tested +* 8.1 Ok +* 8.2 Mostly Ok, problem with replies from several apps because incorrect `SEQUENCE` in reply +* 8.3 Ok +* 8.4 Ok +* 8.5 Mostly Ok, the same problem as 8.2 +* 8.6 Ok + +==== Vendor 2 testing + +Issues: + +* Why app asks for non-existing URL `PROPFIND` `/calendars/iopmit`. +`test.nnnnn.com/user2/Calendar/null ?` +* One CalDAV server returns HTTP/1.1 401 Unauthorized instead of HTTP/1.1 404 Not found for +non-existing URL. - FIXED +* Although one app doesn't support CalDAV Free/Busy it shows Free/Busy dialog. It may be +confusing for users. +* Creating event by dragging in calendar and Editing event by double-click don't work correctly. +** A message "Item Changed on server" appears. +** New event appears not only as event but also as `TODO` in one app +*** `REPORT` filter doesn't work correctly + +Test result: + +* 1.1 Ok +* 1.2 Meeting is correctly created on the server - other clients displays it correctly, but one client shows only +two recurrences instead of 4 +* 1.3 `ORGANIZER` is missing in .ics file on the server +* 1.4 Ok +* 2.* NOTE: Don't use double click for editing event. It doesn't work correctly +* 2.1 Ok +* 2.2 Ok +* 2.3 Bug in a client GUI. Event is correctly changed on the server, bud client doesn't show it until reload. +* 2.4 Ok +* 2.5 Ok +* 2.6 N/A -- one client doesn't support such exceptions +* 2.7 N/A +* 2.8 Ok +* 2.9 Ok +* 3.* Not tested +* 4.1 Ok +* 4.2 Ok +* 4.3 Ok +* 4.4 Ok +* 4.5 Ok +* 5.* Not tested +* 6.* client doesn't support calendar collections. +* 7.* Not tested +* 8.* client doesn't support CalDAV scheduling. + + +==== Vendor 3 testing + +Issues: + +* `MKCALENDAR` is missing in `OPTIONS` +* `MKCOL` always returns 207 Multistatus. It should return 201 Created if no propertyupdate xml +body is present in `MKCOL` request +* Calendar is read-only when I subscribe it. Is is bug? + +==== Vendor 4 testing + +Issues: + +* CalDAV scheduling doesn't work at all, because server doesn't support principal search report. + +Test result: + +* 1.1 Ok +* 1.2 Ok +* 1.3 Ok +* 1.4 Ok +* 2.1 Ok +* 2.2 Ok +* 2.3 Ok +* 2.4 Ok +* 2.5 Ok +* 2.6 N/A +* 2.7 Ok +* 2.8 Ok +* 2.9 Ok +* 3.* Not tested +* 4.1 Ok +* 4.2 Ok +* 4.3 Ok +* 4.4 Ok +* 4.5 Ok +* 5.* Not tested +* 6.1 Ok +* 6.2 Ok +* 6.3 Created, but server returned incorrect response 207 Multi status +* 6.4 Ok +* 6.5 Ok +* 6.6 Ok +* 7.* Not tested +* 8.* Scheduling doesn't work at all.......... + +==== Vendor 5 testing + +Issues: + +* One server renames calendar when calendar name and display name are different. It causes +incompatibility with one client. When the calendar renaming is disabled in the server, publishing calendars +from the client works fine. Calendar renaming also causes a problem with another client. + +==== General Comments + +CalConnect IOP is effective way how to test compatibility. + +=== Vendor C Testing + +This vendor focused on testing iCalendar, iMIP and iTIP objects. They used our standard testing +scenario and the results of each event are shown below. + +[cols="1a,1a,1a,1a,5a",options=header] +.Testing Scenario Table +|=== +4+| Task | Result + +4+| A: Non-repeating cases: | +4+| 1: User A ``PUBLISH``es an event | Was able to `PUBLISH` and process an event to/from all vendors +4+| 2: User A invites Users B, C, D & E to a meeting: | +| 3+| A: ``ATTACH``ments: | +| | 2+| 1: 0 | Was able to send all vendors a single without attachments. One vendor accepted, but then vendor's user became chair and sent out 20 rescheduled notice. +| | 2+| 2: 1 | Was able to send all vendors a single with one attachment (bmp). +| | 2+| 3: 1+ | Was able to send all vendors a single with two attachment +| 3+| B: ``ALTREP``s of: | +| | 2+| 1: `DESCRIPTION` | Was able to send all vendors a single with AltReps of text in the description field. +| | 2+| 2: `COMMENT` | Was able to send all vendors a single with AltReps of text in the comments dialog. +| | 2+| 4: `LOCATION` | Was able to send all vendors a single with AltReps of text in the location field. +| 3+| C: Including `ALARMS` | +| | 2+| 1: `AUDIO` only | Was able to send all vendors a single with audio alarm. +| | 2+| 2: `DISPLAY` only | Was able to send all vendors a single with display alarm +| | 2+| 3: `EMAIL` only | Was able to send all vendors a single with email alarm. +| 3+| F: `ATTENDEE` property parameters: | +| | 2+| 1: `CUTYPE`: | +| | | | A: `INDIVIDUAL` (Default) | Was able to send to vendors individually +| | | | B: `GROUP` | Was able to send to `GROUP` of vendors +| | | | C: `RESOURCE` | +| | | | D: `ROOM` | Was able to send all vendors a single Invite with an RnR. +| | 2+| 3: `ROLE`: | +| | | | A: `CHAIR` | Was able to send a single Invite with Chair role to all vendors. +| | | | B: `REQ-PARTICIPANT` (Default) | Was able to send a single Invite with `REQ-PARTICIPANT` role to all vendors. +| | | | C: `OPT-PARTICIPANT` | Was able to send a single Invite with `OPT-PARTICIPANT` role to all vendors. +| | 2+| 4: `PARTSTAT`: | +| | | | A: `NEEDS-ACTION` (Default) | Was able to send a single Invite with `NEEDS-ACTION`. +| | | | B: `ACCEPTED` | Was able to send an `ACCEPTED` out +| | | | C: `DECLINED` | Was able to send a `DECLINED` out +| | | | D: `TENTATIVE` | Was able to send a `TENTATIVE` out +| | 2+| 5: `RSVP` | +| | | | A: `TRUE` | Was able to send with `RSVP=TRUE` +| | | | B: `FALSE` (Default) | Was able to send with `RSVP=FALSE` +| | 2+| 8: `SENT-BY` | +| | | | B: 1 | Was able to send a single event with `SENT-BY`. +| | 2+| 9: CN | +| | | | B: 1 | Was able to send with a CN. +4+| 3: User B Accepts the invitation: | Sent two vendors a single. Two vendors can accept. +| 3+| A: but then Declines the invitation | One of the vendor declines. The other vendor mentioned that iTips does not work for him yet, so he cannot accept then decline +4+| 4: User C Declines the invitation: | +| 3+| A: but then Accepts the invitation: | One vendor accepts. The other vendor mentioned that iTips does not work for him yet, so he cannot decline then accept +4+| 6: User E Delegates to User G: + +A: User G Accepts the invitation: + +B: User G Declines the invitation: + +C: User G requests a Refresh of the invitation: + +D: User G Counters with a new meeting time: + +E: User G Delegates to User I: | Couldn't test this scenario since it requires at least two other vendors which support delegation. +4+| 7: User A reschedules the meeting: Repeat permutations of 1-6 below as necessary. | +4+| B: Repeating cases: + +(Repeat A. subcases but expand for instance manipulation including entire set, 1 instance, `THISANDPRIOR` & `THISANDFUTURE` ranges + +Tests should include the following permutations: + +``RDATE``s only + +``RRULE``s only + +``RDATE``s and ``RRULE``s + +``RDATE``s & ``EXDATE``s only + +``RRULE``s & ``EXDATE``s only + +``RDATE``s & ``EXRULE``s only + +``RRULE``s & ``EXRULE``s only + +``RDATE``s, ``EXDATE``s & ``EXRULE``s + +``RRULE``s, ``EXDATE``s & ``EXRULE``s + +``RDATE``s, ``RRULE``s & ``EXDATE``s + +``RDATE``s, ``RRULE``s & ``EXRULE``s + +``RDATE``s, ``RRULE``s, ``EXDATE``s & ``EXRULE``s + +) | Was able to send everyone a standard repeating. + +Vendors `REPLIED` with no problem. + +Was able to send a resch on time of the whole repeating meeting + +Was able to send a reschedule on dates of one instance, thisandprior, thisandfuture instances. One vendor replied with no problem, but we receive error when open the accepted notice + +Was able to send a confirm to a single meeting with comments. + +Was able to send a cancellation to everyone. + +Was able to send a weekly repeating meeting (every other week for 7 weeks). Vendors replied with no problem +|=== + +==== General comments/problems + +Overall here are problems found at this interoperability event test: + +. One vendor accepted our invite, but vendor became chair of the meeting and sent out at least 20 +rescheduled notices. +. There is an iCalendar invite from one vendor came in with a complicated `RRULE`, and we lost +one instance when processing it. +. One vendor user accepted our invite with an image, but the image lost when come to our Inbox +. One vendor accepted our multiple reschedule events, and we receive error when opening one of +those accepted notice +. One vendor received error when trying to process our task invite. This is a long time, known +issue. + +=== Vendor D Testing + +The following are this vendor's testing notes. Scheduling and free/busy testing with CalDAV servers was +ignored during this testing. + +Of the ICS files, we actually only fail to parse 2 of them. The issues there stem from our parsers requiring +a `DTSTART` when there is a `DTEND` and not expecting a "timeless" `VEVENT` (we handle timeless +``VTODO``s just fine). + +We tested the items on the sheet, we also tested ``VTODO`` handling on the CalDAV servers. + +In general, we didn't find any issues with the CalDAV servers, but we found plenty of issues where we +have some mis-steps. + +Below are notes from items found during the testing. + +==== Vendor 1 CalDAV testing + +* Inline editing of title - get a 422 error -- another vendor works with this + +==== Vendor 2 CalDAV testing + +* Giant Attendee list has very poor performance (300 attendees) +* CalDAV Todo oddities 396116 +* ``XPROP``s in the alarms when you click on `DISMISS` and when you click on `SNOOZE`. + +==== Vendor 3 CalDAV testing + +* Edit by drag does not send the update to the server if you type in a new title - same issue as +another server? Another vendor works with this +* Sending a `\null` when talking to the CalDAV provider. Why are we doing this? Are we trying +to construct a URI and hitting a null JavaScript object? +* With one server, once we hit this editing weirdness, we continually get the "Submit Change" or +"Discard Changes" dialog popping up. +** If you click "Submit changes" you get nowhere - you stay in the same state. +** If you click "Discard Changes" the changes are resubmitted and the change goes through. +** Could those buttons be miswired? - not verified that this is not the case, but we are not +updating the UI with the new result, and are not really updating the UI if the "submit +anyway" fails. +** The "reload" from the discard seems to refresh the items on the calendar whereas the +"submit anyway" doesn't. +* When working with this server, we are creating ``VTODO``'s in the UI for each event. We do not +export these, and we do not bring them down from the server. Somehow they simply appear in +the `TODO` UI. + +==== General iCalendar ICS testing + +* Bug fixed - application doesn't handle timezone definitions without a `TZNAME` specified in it +* If something has a `DTSTART` and `DURATION`, our application puts a `DTEND` on it before +sending it up to the CalDAV/ICS server. This is wrong! +* Not able to change attendee `PARTSTAT` through the event dialog for a specific attendee +* Import of an ICS into a storage calendar (like home) is not refreshing the month view +* Cannot import items that are indented in ICS files (entire file has 3 spaces to the left, for instance, +and indented lines have another extra space). +* 4.2.2.ics fails - no start/end on vevent + +[options=header,cols="<,^,^,^,^,^,<",headerrows=2] +.Vendor D CalDAV Scenario Testing Results +|=== +| 5+| CalDAV Servers | Comments +| Item # | Srv1 | Srv2 | Srv3 | Srv4 | Srv5 | + +| 1.1. | P | P | P | P | P | +| 1.2. | P | P | | P | P | Creating calendar with one server, the URL must be properly cased. If it is incorrectly cased, we fail to create the calendar claiming that the resource is DAV but not CalDAV +| 1.3. | P | P | P | P | P | +| 1.4. | P | P | P | P | P | +| 2.1. | P & F | P | P | P | P & F | Issues with editing inline on two servers, but editing with opened dialog is ok. One server update failed due to problematic `DURATION` handling on client side. +| 2.2. | P | P | P | P | F due to 2.1 | +| 2.3. | P | P | P | P | P | +| 2.4. | P | P | P | P | P | +| 2.5. | P | P | P | P | P | +| 2.6. | P | P | P | P | P | +| 2.7. | N | N | N | N | N | (not accessible through UI) -- the attendee would have to respond with a Decline response. +| 2.8. | P | P | P | P | P | +| 2.9. | P | P | P | P | P | +| 3.1. | | | | | | +| 3.1.1. | P | P | P | P | P | +| 3.1.1.1. | | | | | | +| 3.1.1.2. | P | P | P | P | P | +| 3.1.1.3. | P | P | P | P | P | +| 3.1.1.4. | | | | | | +| 3.1.2. | | | | | | +| 3.1.2.1. | P | P | P | P | P | +| 3.1.2.2. | P | P | P | P | P | +| 3.1.3. | | | | | | +| 3.1.3.1. | | | | | | +| 3.1.3.2. | | | | | | +| 3.1.4. | | | | | | +| 3.1.4.1. | | | | | | +| 3.1.4.2. | | | | | | +| 3.1.4.3. | | | | | | +| 3.1.5. | | | | | | +| 3.1.5.1. | | | | | | +| 3.1.5.2. | | | | | | +| 3.2. | | | | | | +| 3.2.1. | P | P | P | P | P | +| 3.2.2. | P | P | P | P | P | +| 3.2.3. | P | P | P | P | P | +| 3.2.4. | | | | | | +| 3.2.5. | | | | | | +| 3.2.6. | | | | | | +| 4.1. | P | P | P | P | P | +| 4.2. | P | P | P | P | P | +| 4.3. | P | P | P | P | P | +| 4.4. | P | P | P | P | P | +| 4.5. | P | P | P | P | P | +|=== + +==== General comments + +Thanks for a very useful and well-run session. + +=== Vendor E Testing + +We did limited testing with one client, only a half hour or so, but everything looked good. + +Another client was tested heavily against one server all week. No issues were ever reported to me. It's +possible that the these folks will have client errors to report. + +One client was not really tested. There's a bug in the client that keeps it from accepting absolute URLs in +`DAV` responses. I spent most of Monday working on our application but by the time that was available to +test, other vendors had no time to test. + +=== Vendor F Testing + +For the first time, server to server functionality was tested between 3 vendors and many issues were fixed +in time for a demo at the end of the interop. + +Floating event issues were discovered when doing tests with one vendor. + +Overall it was a very interesting interop mostly due to the new server to server functionality. There should +put extra effort put into inviting more CalDAV client implementors in the upcoming interop events. + +=== Vendor G Testing + +Several clients and servers were tested. Some do not support floating time or do not fall back to `TZ` on +calendar collection. + +Another server doesn't support "setting" properties on new collections, no inbox? + +One server created, but can't propfind (they move collection just after creation) - was fixed and then the +server worked. + +One server had no issued and worked right off. + +==== General comments + +New scheduling was untested and new Free/Busy was untested. + +=== Vendor H Testing + +This vendor focused on free/busy and scheduling CalDAV testing. These are their notes. + +Monday - mostly fixing bugs we encountered between two vendors' servers. By the end of the day that +seemed to work OK. + +Tuesday - spent more time working with another vendor server. + +Wednesday we discovered a few more problems. + +The end result was we had working scheduling between one client and one server and server to server +between three CalDAV server. + +Some of the problems we ran into were mostly in the form of data returned. + +One plugin is unable to process some forms of valid `freebusy`. + +There was very little time for testing against any other clients. + +=== Summary + +We continue to have good results testing CalDAV clients and servers. General comments again are that +it is always good to have interops in person. + +We need to get more vendors in to test iCalendar, iMIP and iTIP objects, particularly with respect to +changes to the specification that came out of the CALSIFY working group at the IETF. + +The Free/Busy testing and demos are starting to gain headway. We hope to do more intensive testing at +future interoperability events as more clients and servers support the specifications. + +Respectfully submitted, + +Pat Egen. + +Interoperability Event Manager diff --git a/sources/cc-0711-report-roundtable-8/document.adoc b/sources/cc-0711-report-roundtable-8/document.adoc new file mode 100644 index 0000000..f0a02c3 --- /dev/null +++ b/sources/cc-0711-report-roundtable-8/document.adoc @@ -0,0 +1,168 @@ += Report on Roundtable VIII, 29 January - 2 February 2007 +:docnumber: 0711 +:copyright-year: 2006 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2007-02-02 +:published-date: 2007-02-02 +:technical-committee: CALCONNECT +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Introduction + +Roundtable VIII took place January 29 to February 2, 2007, hosted by Novell in Provo, Utah. The +event was attended by 30 representatives to the IOP testing and/or the Roundtable, including +representatives from two observers (organizations attending a Roundtable to see if they wish to +join). + +Monday noon through Wednesday noon, January 29-31, was a dedicated CalConnect +Interoperability Test Event where participating organizations performed interoperability testing +between their calendaring and scheduling implementations. Wednesday afternoon, all day +Thursday, and Friday morning comprised the Roundtable. The majority of this time was dedicated +to technical committee sessions, BOFs, and informal discussions and networking, with an allhands +Plenary meeting as the last item on Friday morning. The Technical Committee sessions +were organized sequentially, to allow all attendees who wished to be involved in the discussions of +a Technical Committee the opportunity to do so. + +== Update on Technical Committees and Initiatives + +=== Work Products + +Since Roundtable VII, TC USECASE has published the _Calendaring and +Scheduling Glossary of Terms_ and TC MOBILE has published _The Benefits of iCalendar for the +Mobile Industry_. + +=== TC CALDAV + +TC CALDAV and TC FREEBUSY jointly worked on the availability discussions +which contributed to the `VAVAILABILITY` specification recently submitted to the IETF by its +authors. The TC is in the final stages of work on the _CalDAV Scheduling Requirements_ paper +which should be published in February. Following completion of the paper, the TC plans work on +several topics including client metadata, external attachments, scheduled event updates, +synchronization support and polling improvements. TC CALDAV intends to complete its work by +Roundtable IX in May 2007, after which the TC will be shut down and TC REALTIME +reactivated. + +=== TC EVENTPUB + +TC EVENTPUB developed use cases and requirements for the `VVENUE` +iCalendar extension, which has been submitted to the IETF as an individual submission by its +authors. The TC is about to begin work on two new initiatives, event sharing and a possible event +sharing protocol for event servers, and localization and a possible `VLOCALIZE` iCalendar +extension. + +=== TC FREEBUSY + +The TC has completed its original scope of work with the completion of the +report to The Open Group. Following the Roundtable it will begin work on `FREEBUSY` URLs +and is exploring another initiative. + +=== TC IOPTEST + +TC IOPTEST conducted the IOP test event and is continuing to work with TC +MOBILE on the development of a Mobile Interoperability Test Suite and planning for a Mobile +Interoperability Test Event. The TC is planning to initiate monthly Jabber-based remote IOP test +events as an adjunct to the formal IOP test events conducted with the Roundtables. + +=== TC MOBILE + +The TC has completed and published _The Benefits of iCalendar for the Mobile +Industry_ and is working on the development of a Mobile Interoperability Test Suite in conjunction +with TC IOPTEST. Planning has begun for a Mobile Interoperability Test Event targeted to the +mobile device industry. Timing and location are not yet determined but late 3rd or 4th quarter in +Europe or the U.K. seem most likely at this time. The TC is also working on recurrence +simplification for mobile devices as input to the IETF CALSIFY effort. + +=== TC REALTIME + +The TC will be reactivated following the completion of the work in TC +CALDAV, which will free up some necessary resources; the Consortium's intent is to reactivate at +the May 2007 Roundtable. The TC anticipates focusing on three major discussion areas: +addressing, discovery, and authentication/authorization/access control, all of which are needed to +enable general server-server `freebusy` lookup and event scheduling. + +=== TC USECASE + +The TC has published the Calendaring and Scheduling Glossary of Terms and has +begun work on a paper defining usecases for the minimum interoperable subset for tasks (``VTODO``s). +The TC has also undertaken a study of recurrence features in mobile device support for TC +MOBILE, and is considering a work item on usecases for resource management. + +=== Daylight Saving Time Ad Hoc + +The DST Ad Hoc Group has developed and published on the +Consortium Website two documents having to do with the imminent DST change: _Extended +Daylight Saving Time Review and Considerations_ and _Extended Daylight Saving Time Links_, +_Advisories and Changes_. In early summer the group plans to develop and publish a "Lessons +Learned" from user experiences during March as a reference and guide to the change back to +standard time in November. + +=== vCard Ad Hoc Group + +There is still interest initiating work in the contacts/vCard area but it waits +on the availability of resources from existing or new members. + +=== CalConnect Interoperability Test Event + +Participants in the IOP test event +included Apple, Eventful, Kerio, Marware, Novell, Oracle, OSAF, and Bedework (Rensselaer +Polytechnic Institute). Results from the event will be posted at Past IOP Reports shortly. + +=== BOFS + +For the first time, the Roundtable was able to provide time for BOFS, and three were held, +on localization, the `freebusy` URL, and DST conversions. The Consortium plans to continue to +provide schedule time for BOFS in the future, together with informal networking amongst those +not interested in the BOFS. + +=== New Initiatives + +Work will be undertaken in existing TCS on new initiatives including +localization, the `FREEBUSY` URL proposal, event sharing, and other possible items which could +result in the establishment of new TCs once the subjects have been fleshed out and the work +scoped. + +== Future Meetings + +* ROUNDTABLE IX: May 7-11, Seattle, Washington, hosted by Boeing Aircraft Company. +* ROUNDTABLE X: September 17-21, Cambridge, Massachusetts, hosted by M.I.T. (location and +host tentative). +* ROUNDTABLE XI: February 4-8, 2008, location and host TBD +* ROUNDTABLE XII: June 2-6, 2008, Madison, Wisconsin, hosted by the University of +Wisconsin (date, location and host tentative). + +The format of CalConnect week will remain the same for these events: + +* Monday noon through Wednesday noon, IOP Test Event +* Wednesday noon through Friday noon, Roundtable (TC sessions, BOFs, networking, Plenary). diff --git a/sources/cc-0712-report-roundtable-9/document.adoc b/sources/cc-0712-report-roundtable-9/document.adoc new file mode 100644 index 0000000..4777a21 --- /dev/null +++ b/sources/cc-0712-report-roundtable-9/document.adoc @@ -0,0 +1,145 @@ += Report on Roundtable IX, May 7-11 2007 +:docnumber: 0712 +:copyright-year: 2007 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2007-05-11 +:published-date: 2007-05-11 +:technical-committee: CALCONNECT +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Introduction + +Roundtable IX and the accompanying IOP test event took place May 7-11, 2007, hosted by Boeing +in Seattle, Washington. The event was attended by 43 representatives from 31 organizations, +including representatives from three observers (organizations attending a Roundtable to see if they +wish to join). + +Monday noon through Wednesday noon, May 7-9, was a dedicated CalConnect Interoperability +Test Event where 6 participating organizations performed interoperability testing between their +calendaring and scheduling implementations. Wednesday afternoon, all day Thursday, and Friday +morning comprised the Roundtable. The majority of this time was dedicated to technical +committee sessions, BOFs, and informal discussions and networking, with an all-hands Plenary +meeting as the last item on Friday morning. The Technical Committee sessions were organized +sequentially, to allow all attendees who wished to be involved in the discussions of a Technical +Committee the opportunity to do so. + +== Update on Technical Committees and Initiatives + +=== Work Products + +Since Roundtable VIII, TC USECASE has published the Minimum +Interoperable Subset Use Cases for Tasks (VTODO), and the DST Ad Hoc committee regularly +updated the Extended Daylight Savings Time Information pages to provide information on the +early shift to Daylight Savings Time. The Consortium also implemented a public Calendar +Administrators Discussion List, and a new website. + +=== TC CALDAV + +The TC is in the final stages of work on the _CalDAV Scheduling Requirements_ +paper which should be published in June. The TC also has several extensions which have been +proposed for investigation, but expects to complete its work by Roundtable X in September. + +=== TC EVENTPUB + +TC EVENTPUB reviewed VVENUE and discussions on localization, and the +current status of work on the "eventmap" event sharing proposal. + +=== TC FREEBUSY + +TC FREEBUSY reviewed previous work including the status of the Boeing +Federated Free/Busy project, and has begun work on the FREEBUSY URL proposal. + +=== TC IOPTEST + +TC IOPTEST initiated monthly Jabber IOP test events as an adjunct to the full +IOP test events held with Roundtables. The TC reported on the IOP test event just completed, and +is continuing to work with TC MOBILE on the development of a Mobile Interoperability Test +Suite and planning for a Mobile Interoperability Test Event. + +=== TC MOBILE + +TC MOBILE reviewed the current draft of its Mobile Interoperability Test Suite, +and continues to develop it. The TC plans a Mobile Interoperability Test Event targeted to the +mobile industry in 4Q07 or 1Q08, probably in the U.K. or Europe. The TC is also working on +recurrence simplification for mobile devices as input to the IETF CALSIFY effort. + +=== TC REALTIME + +The TC will be reactivated in June and expects to begin work with the +consideration of Anonymous Free/Busy, in conjunction with TC FREEBUSY. + +=== TC USECASE + +The TC has published the Min-IOP (Minimum Interoperable Subset) Use Cases +for Tasks (VTODO) and has begun work on considering Use Cases for Resources. The TC has +also undertaken a study of recurrence features in mobile device support for TC MOBILE. + +=== Daylight Saving Time Ad Hoc + +The DST Ad Hoc reported on its work leading up th the DST +conversion in March, and plans to prepare a "lessons learned" document. The document will cover +preparations, lessons learned, planning for November, and longer-term recommendations. + +=== CalConnect Interoperability Test Event + +Participants in the IOP test event +included Apple, Marware, OSAF, Bedework (Rensselaer Polytechnic Institute) Sun Microsystems +(Lightning), and Synchronica. Results from the event will be posted at Past IOP Reports as soon +as they are collated and prepared. + +=== BOFS + +BOF topics included SSE (Simple Sharing Extensions), XML for iCalendar representation, +vCard initiatives, and the DST follow-on work. + +=== New Initiatives + +The Consortium plans to initiate work on a follow-on activity to TC +TIMEZONE in the area of a timezone registry and service protocol; XML for iCalendar +representation; and a possible vCard/Content Workshop in September to help define the problems +and potential solutions. + +== Future Meetings + +* ROUNDTABLE X: September 17-21, Cambridge, Massachusetts, hosted by M.I.T. (location and +host tentative). +* ROUNDTABLE XI: February 4-8, 2008, location and host TBD +* ROUNDTABLE XII: June 2-6, 2008, Madison, Wisconsin, hosted by the University of +Wisconsin (date, location and host tentative). + +The format of CalConnect week will remain the same for these events: + +* Monday noon through Wednesday noon, IOP Test Event +* Wednesday noon through Friday noon, Roundtable (TC sessions, BOFs, networking, Plenary). diff --git a/sources/cc-0713-report-roundtable-10/document.adoc b/sources/cc-0713-report-roundtable-10/document.adoc new file mode 100644 index 0000000..6807a9c --- /dev/null +++ b/sources/cc-0713-report-roundtable-10/document.adoc @@ -0,0 +1,171 @@ += Report on Roundtable X, September 19-21 2007 +:docnumber: 0713 +:copyright-year: 2007 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2007-09-21 +:published-date: 2007-09-21 +:technical-committee: CALCONNECT +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Introduction + +Roundtable X and the accompanying IOP Test Event took place September 17-21, hosted by The +Massachusetts Institute of Technology, in Cambridge, Massachusetts. The event was attended by +43 representatives from 31 organizations, including representatives from three observers +(organizations attending a Roundtable to see if they wish to join). + +The CalConnect Interoperability Test Event (C.I.T.E.) was held immediately prior to the +Roundtable, running Monday noon through Wednesday noon, September 17-19. Nine (9) +organizations participated in this event, performing interoperability testing between their +calendaring and scheduling implementations. A report on the IOP Test Event will be published as +soon as possible. + +In conjunction with this Roundtable, CalConnect hosted a one-day open vCard Workshop on +Tuesday, September 18th. The vCard Workshop was attended by about 20 people. A report on the +workshop together with presentations and other materials may be found at vCard Workshop +Report. + +Roundtable X, attended by 43 representatives from 35 organizations, including 4 observers ran +Wednesday afternoon, all day Thursday, and Friday morning. Wednesday afternoon began with a +Technology Preview demonstrating live interoperability in the areas of CalDAV Scheduling, +Server-Server, and Free/Busy URL between multiple dissimilar clients and servers. The majority +of the Roundtable was dedicated to technical committee sessions, BOFs, and informal discussions +and networking, with an all-hands Plenary meeting as the last item on Friday morning. The +Technical Committee sessions were organized sequentially, without competing parallel sessions, to +allow all attendees who wished to be involved in the discussions of a Technical Committee the +opportunity to do so. + +== Update on Technical Committees and Initiatives + +Work Products since Roundtable IX: + +* TC CALDAV has published CalDAV Scheduling Requirements. +* TC MOBILE has published the Mobile Calendar Interoperability Test Suite. +* The DST Ad Hoc Committee has published CalConnect EDST Reflections and +Recommendations, reviewing how the industry dealt with the early DST conversions in +March, and with recommendations both for the November 4 reversion from Daylight +Savings Time, and for the future of DST and timezone management. + +=== TC CALDAV + +TC CALDAV reported on its work to date including its recently-published +CalDAV Scheduling Requirements paper. Discussions covered new and continuing work in +several areas of potential extensions to the CalDAV specification, including Roles, Access +Control, Alarm Management and other scheduling extensions. + +=== TC EVENTPUB + +TC EVENTPUB reviewed the current state of the `VVENUE` proposal, +generating a great deal of discussion concerning possible intersections between `VVENUE` and the +potential work on vCard. The TC also reviewed the current status of work on the "eventmap" +event sharing proposal. + +=== TC FREEBUSY + +TC FREEBUSY reviewed work since the last Roundtable, especially work on +Free/Busy URL and in preparing for the Technology Previews of CalDAV Scheduling, serverserver, +and Free/Busy URL. Going forward the TC will continue work on Free/Busy URL and on +Free/Busy discussions with external entities. + +=== TC IOPTEST + +TC IOPTEST reported on the IOP test event just completed, and discussed early +plans to implement an issue-tracking mechanism and to work with TC MOBILE on planning for a +Mobile Interoperability Test Event. + +=== TC MOBILE + +TC MOBILE presented and reviewed its recently-published Mobile Calendar +Interoperability Test Suite, and discussed plans for an initial Mobile Interoperability Test Event, +including liaison activities with the OMA/DS group. The TC may also participate in establishing +interoperability testing for vCard if the Consortium goes forward in this area, as vCard is already +reflected in the Mobile IOP test suite. + +=== TC REALTIME + +TC REALTIME has been reactivated since Roundtable IX, and has been +meeting alternately with TC FREEBUSY to work on the `VAVAILABILITY` proposal and the +Technology Previews at this Roundtable. Going forward the TC will work on the `REALTIME` +messaging protocol, Discovery, and Authentication and Authorization. + +=== TC TIMEZONE + +TC TIMEZONE was reactivated to consider the DST Ad Hoc recommendations and work on a +formal Timezone Registry proposal and a proposal for a Timezone Service Protocol. The TC +presented the conceptual work to date for the registry and service proposals. + +=== TC USECASE + +The TC presented its in-progress work on Resources generating a lengthy +discussion on the subject. The TC has also undertaken a study of recurrence features in mobile +device support for TC MOBILE. + +=== Daylight Saving Time Ad Hoc + +The DST Ad Hoc published CalConnect EDST Reflections and +Recommendations just prior to this Roundtable, and gave a short discussion of the paper and its +recommendations. The Ad Hoc will remain instantiated until it is apparent whether additional +information gathering and delivery will be needed in preparation for the November 4 reversion to +standard time. + +=== CalConnect Interoperability Test Event + +Participants in the IOP test event +included Apple, IBM, Kerio, Marware, Mozilla, Open Connector Groupware,OSAF, Oracle, and +RPI (Bedework), Results from the event will be posted at Past IOP Reports as soon as they are +collated and prepared. + +=== BOFS + +BOF topics included XML for iCalendar representation, `VVENUE` and `VALARM` follow + +=== New Initiatives + +* The Consortium plans to initiate a TC in the area of XML representation of iCalendar data; +a draft charter will be prepared shortly after the Roundtable. +* The Consortium will initiate a TC in the area of a vCard Revision if the resources can be +found. A draft charter will be circulated via the public vcard-workshop-l mailing list. + +== Future Meetings + +* ROUNDTABLE XI: February 4-8, 2008, at Sun Microsystems, San Francisco Bay Area, +California. +* ROUNDTABLE XII: June 2-6, 2008, at the University of Wisconsin, Madison, Wisconsin. +* ROUNDTABLE XIII: October 6-10, 2008, host and location to be determined. + +The format of the CalConnect week is: + +* Monday noon through Wednesday noon, C.I.T.E. (CalConnect Interoperability Test Event) +* Wednesday noon through Friday noon, Roundtable (TC sessions, BOFs, networking, Plenary). diff --git a/sources/cc-0714-report-vcard-workshop/document.adoc b/sources/cc-0714-report-vcard-workshop/document.adoc new file mode 100644 index 0000000..64792fb --- /dev/null +++ b/sources/cc-0714-report-vcard-workshop/document.adoc @@ -0,0 +1,185 @@ += Report on CalConnect vCard Workshop, September 18 2007 +:docnumber: 0714 +:copyright-year: 2007 +:language: en +:doctype: administrative +:edition: 1.1 +:status: published +:revdate: 2007-09-18 +:published-date: 2007-09-18 +:technical-committee: VCARD WKSP +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Introduction + +NOTE: Update 13-Nov-2007: The Draft Charter for the CalConnect vCard Technical Committee +has been added at the bottom of this web page. + +CalConnect sponsored a open one-day workshop on vCard and what to do about it. The +event was held September 18, 2007 at the Massachusetts Institute of Technology in +Cambridge, Massachusetts. Registered attendance was about 20, but a few others sat in +during some portion of the day. About 3/4 of the attendees were from CalConnect +members, although not always a CalConnect representative from that member. + +== Meeting Summary + +The preliminary agenda is available at Prelminary Workshop Agenda. The workshop began +with a welcome and introduction by Dave Thewlis, the Executive Director of CalConnect, +who gave a brief overview of CalConnect, its relationship with the IETF, and how +CalConnect got involved with vCard in the first place. (Summary: as soon as you start to do +calendaring you get involved in address books and vCard pops up.) CalConnect members +have expressed for some time that "something ought to be done about vCard" but +CalConnect has not to this point had the resources to do anything, nor clarity on what ought +to be done and what if anything should be undertaken by CalConnect. The goal of this +workshop therefore was to see if there was general agreement on what the problems were, +and what should be undertaken by the IETF. Then as an ancillary, what should additionally +be undertaken by another entity (such as CalConnect) and is CalConnect the right place. + +Cyrus Daboo of Apple provided an overview presentation of the problem and related +issues, which included a summarization of the 25 or so responses to the CalConnect +questionnaire on vCard issues. vCard Problems and Related Issues. This was followed by +a http://www.openmobilealliance.org/ftp/Public_documents/DS/DS_DO/2007/OMA-DS-DS_DO-2007-0002R01-INP_vCard_workshop.zip[presentation from the OMA DS] +discussing vCard and OMA DS (formerly SyncML) issues, +and a brief discussion on other related work or standards in other bodies. + +The group then conducted a considerable discussion of vCard problems, what needed to +be fixed, and what should be done if a vCard revision was undertaken. There was +considerable agreement that a new specification should have the name changed, possibly +to "iCard". The final list of identified items is at List of Desired Elements for a vCard +Revision + +A key point was that if a vCard revision happens, the resultant specification needs to be +significant enough and offer enough new things to make the business case for converting +to it to the many organizations which support vCard today (most of which haven't even +gone to vCard 3 yet). Related to that is that promotion, publicity, use cases and +requirements, and interoperability testing need to happen in parallel with the actual +specification revision. + +The workshop discussed briefly whether the right thing to do was to scrap vCard and +develop an entirely new specification, but the consensus was that while that might be the +"right" thing to do from a theoretical viewpoint, it was probably not practical. On the other +hand, as noted above we need to avoid simply tackling the easy bits because nobody will +adopt what amounts to a minor revision - after all they didn't do so the last time. + +Chris Newman, IETF Area Director, stated that the amount of interest (and concern) had +convinced him that the work should go forward in the IETF to revise vCard, and that he had +possible candidates for document editors and co-chairs for a working group, so he intended +to initiate the process of charter development. + +Discussion on what needed to be done to provide input to the working group included use +cases, requirements, results of interoperability testing to determine minimum interoperable +subsets, etc., in addition to ultimately promoting the resultant specification. The first part of +this needs to happen quickly, if possible no later than the March 2008 IETF meeting to +provide something for the working group to start with. Discussion of possible venues for the +work did not identify any significant alternatives to CalConnect presuming that CalConnect +can undertake the work. The topic of allowing non-member-representatives to participate in +the CalConnect work was discussed briefly without any final decisions; however +CalConnect is in the process of adopting mechanisms to allow external public review and +comment on selected work items and does have some other ways in which this could be +enabled on a case-by-case basis (primarily the ability to include identified "industry experts" +not from CalConnect members in the deliberations of a TC). + +From the CalConnect perspective, undertaking the work requires new resources; the +available technical resources are committed to existing Technical Committees. However, +several non-members have indicated that they are interested enough in the work to +consider joining CalConnect in order to participate. + +CalConnect will develop a draft charter for a vCard Technical Committee, which will identify +the scope of the work, expected work products and timelines, and will do so on the public +vcard-workshop-l mailing list which was set up to complement the vCard Workshop. This +will allow all interested parties, by joining that list if they are not already subscribed, to be +informed on what is being proposed and develop a clearer understanding of what their +commitment might be if they decide to participate in the work. CalConnect expects that the +development of this charter and solicitation of volunteers to help will take several weeks. +The CalConnect TC CHAIRS and Steering Committee will then make a final decision on +whether to undertake the work based on the availability of the necessary resources. + +== Other Notes + +CalConnect had planned to offer an Internet audio stream together with a jabber room to +allow comments and to ask questions. However although several people indicated interest, +repeated emails prior to the workshop didn't elicit anyone saying they would use the facility, +so we did not set it up. + +CalConnect thanks all of the participants in the workshop and everyone who worked to +make it a success. + +== Workshop Presentations and Materials + +* Workshop Preliminary Agenda +* Summary and Notes (text from this page) +* vCard Problems and Related Issues +* http://www.openmobilealliance.org/ftp/Public_documents/DS/DS_DO/2007/OMA-DS-DS_DO-2007-0002R01-INP_vCard_workshop.zip[OMA DS Presentation] +* List of Desired Elements for a vCard Revision + +== Draft Charter for CalConnect vCard Technical Committee (as of 05-Oct-2007) + +TC-VCard will provide support to the IETF vCard revision efforts by: + +. Determining specific problem areas in the current vCard specifications that need to be +fixed. As input the TC will start with issues documented in the vCard workshop. +. Looking at enhancements to the specifications to address current needs. +. Working on interoperability test cases to expose these problems and to provide a means +to verify when they are fixed in the updated specifications. +. Work on an XML-syntax for a 1-to-1 mapping with vCard. + +The technical committee will produce a recommendations document to the IETF describing +the suggested fixes and enhancements felt necessary. + +The technical committee will work with other CalConnect technical committees to +accomplish this work (e.g., TC-Mobile, TC-XML (proposed), TC-Eventpub (VVENUE +overlap), TC-Ioptest (interoperability testing). + +The technical committee will work on a "benefits" document to promote the new standard. It +will also help promote this amoungst vendors to try and encourage rapid deployment of the +new standard. + +Mirroring the consensus of the vCard workshop, this TC does not plan to examine a +wholesale replacement of vCard. + +Milestones: + +* Nov 2007 TC Setup +* Jan 2008 Interoperability test cases. +* Feb 2008 Interoperability event. +* Feb 2008 Draft of recommendations. +* Mar 2008 Initial presentation to IETF. +* Jun 2008 Interoperability event. +* Jun 2008 Publish recommendations. +* Jul 2008 Final presentation to IETF +* Oct 2008 Interoperability event. +* Oct 2008 Publish XML mapping document. +* Oct 2008 Publish benefits document. +* Oct 2008 Shutdown. + +NOTE: Comments and suggestions on this Draft Charter should be posted on the +vcard-workshop-l mailing list. diff --git a/sources/cc-0801-pres-preview-roundtable-11/document.adoc b/sources/cc-0801-pres-preview-roundtable-11/document.adoc new file mode 100644 index 0000000..12e99f9 --- /dev/null +++ b/sources/cc-0801-pres-preview-roundtable-11/document.adoc @@ -0,0 +1,419 @@ += CalConnect Technical Preview - Roundtable XI +:docnumber: 0801 +:copyright-year: 2008 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2008-02-06 +:published-date: 2008-02-06 +:technical-committee: CALCONNECT +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:imagesdir: images + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks +and Disclaimer of Warranty for External (Public) Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Note Well + +* This presentation is derived from the +Technology Preview material +* Names and some technical details +have been removed in accordance +with CalConnect rules involving in-progress +work +* This is a public document and may be +quoted and distributed in accordance +with CalConnect policies + +== Introduction + +CalConnect members have produced a +Technical Demonstration of key +calendaring and scheduling +technologies being developed by +CalConnect. + +This serves as a technology "preview" +only and does not in any way represent +final protocols or products that may or +may not ship. + +This is a follow-up to the demo at +Roundtable X (September 2007). + +Our goal is to solicit feedback from +members and invited guests on the +presentation itself as well as the +technologies being demonstrated. + +We also hope to show how CalConnect +is successfully achieving its goal of +improving calendaring and scheduling +standards. + +== Agenda + +Today we will demonstrate: + +* CalDAV Scheduling +* Realtime Internet Scheduling +* Internet `freebusy` lookups using +`freebusy` URLs + +Each presentation will consist of: + +* Introductory slides +* Live demonstration + +== Technologies + +CalDAV Scheduling: + +* The CalDAV access protocol +(RFC4791) is based on WebDAV and +iCalendar standards +* In the CalDAV scheduling +specification (still a draft), users on +the same server system only +schedule with each other +* There are several server and client +implementations available + +Realtime Internet Scheduling: + +* Allows scheduling between users on +different server systems (e.g. +between organizations) +* The protocol uses HTTP to transport +iCalendar scheduling messages +* We will be demonstrating the basic +exchange of scheduling messages +* The security and discovery pieces +are still to do (TC-REALTIME) + +Freebusy URL: + +* This is a way to do simple exchange +and publishing of `freebusy` +information +* TC-FREEBUSY is working on a +specification +* It uses simple HTTP `GET`/`PUT` +operations with discoverability + +== CalDAV Scheduling + +How it works: + +* Several users on one CalDAV server +(can be using different clients) +schedule with each other +* One user is the "Organizer", others +are "Attendees" + +One is the Organizer, others are Attendees. Each stores their calendars on the Server. + +[%unnumbered] +image::img01.png[] + +There are two parts to scheduling: + +. Freebusy lookup +. Sending invitations and receiving +replies + +Freebusy results are returned +immediately. + +Invitation replies are sent only after +users inspect and accept or decline. + +Each user has an "Outbox" and an +"Inbox". +The "Outbox" is used to trigger +`freebusy` lookup or send invites or +replies. +The "Inbox" is where invites or replies +are delivered. +Clients monitor the "Inbox" for +incoming scheduling messages. + +.Sequence of diagrams showing free-busy lookup +==== +[%unnumbered] +image::img02.png[] + +[%key] +1:: Organizer sends `freebusy` request to server +2:: Server calculates `freebusy` data for attendees +3:: Server returns aggregated `freebusy` data to organizer + +[%unnumbered] +image::img03.png[] + +[%key] +1:: Organizer sees `freebusy` for everyone +2:: Can adjust meeting time to avoid conflicts +==== + +.Sequence of diagrams showing invitations being sent out, replies returned. +==== +[%unnumbered] +image::img04.png[] + +[%key] +1:: Organizer sends invite request to server +2:: Server copies the request into attendees' Inbox +3:: Attendee checks the server +4:: Attendee retrieves the invite from the server + +[%unnumbered] +image::img05.png[] + +[%key] +1:: Attendee replies to the server +2:: Server copies the reply into organizer's Inbox +3:: Organizer checks the server +4:: Organizer retrieves the reply from the server +==== + +=== Demonstration #1 -- Simple meeting between two people + +.Demo Participants +image::img06.png[] + +=== Demonstration #2 -- Simple meeting between multiple people with different clients some CalDAV others using a CalDAV "connector" + +.Demo Participants +image::img07.png[] + +== Realtime Internet Scheduling -- How it works + +=== Basic Concept + +* Provides the ability for users on +different calendaring systems to +schedule meetings with each other +* Instantaneous `freebusy` lookups +* Invites, replies sent as "messages" +with delivery status immediately +returned + +.Organizer and Attendees on different systems +image::img08.png[] + +=== Can't this be done today? + +But I can do scheduling with my +colleagues today! + +True, but only people on the same +server as you, or via some other +communication process such as email +or telephone. + +.Sequence of diagrams showing `freebusy` +==== +[%unnumbered] +image::img09.png[] + +[%key] +1:: Organizer sends `freebusy` request to server +2:: Server forwards request to other attendee's servers +3:: Attendees' servers return `freebusy` +4:: Server returns aggregated `freebusy` data to organizer + +[%unnumbered] +image::img10.png[] + +[%key] +1:: Organizer sees `freebusy` for everyone +2:: Can adjust meeting time to avoid conflicts +==== + +.Sequence of diagrams showing invites and replies +==== +[%unnumbered] +image::img11.png[] + +[%key] +1:: Organizer sends invite request to server +2:: Server forwards request to other attendee's servers +3:: Organizer gets delivery status response +4:: Attendee checks the server +5:: Attendee retrieves the invite from the server + +[%unnumbered] +image::img12.png[] + +[%key] +1:: Attendee sends reply to server +2:: Server forwards reply to other organizer's server +3:: Attendee gets delivery status response +4:: Organizer checks the server +5:: Organizer retrieves the reply from the server +==== + +=== Demonstration -- Four calendar users in different domains + +.Realtime Demo Setup +image::img13.png[] + +== Freebusy URL + +=== What is Freebusy? + +A list of free and busy periods for a +particular calendar user or resource. +Primarily used for scheduling +resources or meetings with other +people. + +Time periods may be marked as + +* busy +* free +* busy unavailable ("out of office") +* busy-tentative + +=== Expressing Freebusy time + +* Most commonly as a RFC 2445 +`VFREEBUSY` object +** a request for `freebusy` time, +** a response to a request, or +** a published set of busy time + +=== Sharing Freebusy + +* CalDAV Scheduling +* iTIP/iMIP (email) +* iCalendar .ics file +* Freebusy URL (`FBURL`) + +=== Why FBURL? + +* Freebusy is "least common +denominator" (LCD) scheduling +* `FBURL` is LCD Freebusy (or could be) +* Easy +* Outlook supports a form of `FBURL` +* The market says `FBURL` is desirable +and useful +** ifreebusy.com, tungle.com, +timebridge.com, timetomeet.info, +doodle.ch +* Potentially bridge the divide between +enterprise calendaring and +** calendar/scheduling augmenters +** standalone calendaring clients (no +server) + +=== What we have done + +* Standardize/Normalize +* Parameters -URI template +* Error reporting within the HTTP +protocol +* Allow for non-authenticated or weakly +authenticated service +* Keep it simple (in its simplest form) +* Outlook compatibility +* Extend? +** Discovery +** Authentication +** Provisioning +** `VAVAILABILITY` +*** provide a grouping of available +time information over a specific +range of time. + +=== How it works + +* The "Read URL" is used to get `freebusy` +data for a user ++ +-- +http://www.example.com/freebusy/user1@example.com?start=20070901T000000-0800 + +http://www.example.com/freebusy/user1@example.com +-- +* returns `VFREEBUSY` object +* The "Publish URL" is used by a client to +upload `freebusy` data for a user ++ +-- +http://www.example.com/freebusy/user1@example.com + +http://www.example.com/freebusy?user=user1@example.com&token=xcsfdgetdh +-- + +=== What we will show you + +* Basic form `FBURL` +** lookups - no publishing +** Accessing multiple servers from the +same clients +** Comparison with server-server +lookups + +=== Demonstration #1 -- Several clients retrieving `freebusy` information + +.Freebusy Demo #1 Setup +image::img14.png[] + +=== Demonstration #2 -- Project management aided by `freebusy` information + +.Freebusy Demo #2 Setup +image::img15.png[] + +=== Wrap-up + +* We have demonstrated how progress +is being made with key scheduling +technologies +* As with a lot of CalConnect work this +is a very interactive process with +specifications and implementations +being worked on together +* This ultimately provides for a better +specification and interoperability + +=== CalDAV Scheduling + +* Work still needs to be done to fine tune +CalDAV scheduling +* Ongoing discussions in TC-CALDAV +center around moving most of the +scheduling message processing to the +server for better reliability +* Hope to complete this by mid-2008 + +=== Realtime Internet Scheduling + +* Demonstrated basic scheduling message +processing +* Key elements of Realtime Internet +Scheduling still need to be developed: +** Discovery (working on DNS-SD +implementation right now) +** Security - need input from security +experts as to what model(s) to use +* Hope to complete this by end of 2008 + +=== Freebusy URL + +* Freebusy is LCD scheduling +* Freebusy is soft-core calendaring +* It is what we settle for, not what we +want +* But...Free/Busy is very, very useful +* CalConnect will continue to develop +`FBURL` diff --git a/sources/cc-0801-pres-preview-roundtable-11/images/img01.png b/sources/cc-0801-pres-preview-roundtable-11/images/img01.png new file mode 100644 index 0000000..8818202 Binary files /dev/null and b/sources/cc-0801-pres-preview-roundtable-11/images/img01.png differ diff --git a/sources/cc-0801-pres-preview-roundtable-11/images/img02.png b/sources/cc-0801-pres-preview-roundtable-11/images/img02.png new file mode 100644 index 0000000..709e2cd Binary files /dev/null and b/sources/cc-0801-pres-preview-roundtable-11/images/img02.png differ diff --git a/sources/cc-0801-pres-preview-roundtable-11/images/img03.png b/sources/cc-0801-pres-preview-roundtable-11/images/img03.png new file mode 100644 index 0000000..2509e24 Binary files /dev/null and b/sources/cc-0801-pres-preview-roundtable-11/images/img03.png differ diff --git a/sources/cc-0801-pres-preview-roundtable-11/images/img04.png b/sources/cc-0801-pres-preview-roundtable-11/images/img04.png new file mode 100644 index 0000000..69e2461 Binary files /dev/null and b/sources/cc-0801-pres-preview-roundtable-11/images/img04.png differ diff --git a/sources/cc-0801-pres-preview-roundtable-11/images/img05.png b/sources/cc-0801-pres-preview-roundtable-11/images/img05.png new file mode 100644 index 0000000..fcf924d Binary files /dev/null and b/sources/cc-0801-pres-preview-roundtable-11/images/img05.png differ diff --git a/sources/cc-0801-pres-preview-roundtable-11/images/img06.png b/sources/cc-0801-pres-preview-roundtable-11/images/img06.png new file mode 100644 index 0000000..1e62187 Binary files /dev/null and b/sources/cc-0801-pres-preview-roundtable-11/images/img06.png differ diff --git a/sources/cc-0801-pres-preview-roundtable-11/images/img07.png b/sources/cc-0801-pres-preview-roundtable-11/images/img07.png new file mode 100644 index 0000000..81e37fb Binary files /dev/null and b/sources/cc-0801-pres-preview-roundtable-11/images/img07.png differ diff --git a/sources/cc-0801-pres-preview-roundtable-11/images/img08.png b/sources/cc-0801-pres-preview-roundtable-11/images/img08.png new file mode 100644 index 0000000..fd34906 Binary files /dev/null and b/sources/cc-0801-pres-preview-roundtable-11/images/img08.png differ diff --git a/sources/cc-0801-pres-preview-roundtable-11/images/img09.png b/sources/cc-0801-pres-preview-roundtable-11/images/img09.png new file mode 100644 index 0000000..06435f5 Binary files /dev/null and b/sources/cc-0801-pres-preview-roundtable-11/images/img09.png differ diff --git a/sources/cc-0801-pres-preview-roundtable-11/images/img10.png b/sources/cc-0801-pres-preview-roundtable-11/images/img10.png new file mode 100644 index 0000000..2d9ad5c Binary files /dev/null and b/sources/cc-0801-pres-preview-roundtable-11/images/img10.png differ diff --git a/sources/cc-0801-pres-preview-roundtable-11/images/img11.png b/sources/cc-0801-pres-preview-roundtable-11/images/img11.png new file mode 100644 index 0000000..3e67257 Binary files /dev/null and b/sources/cc-0801-pres-preview-roundtable-11/images/img11.png differ diff --git a/sources/cc-0801-pres-preview-roundtable-11/images/img12.png b/sources/cc-0801-pres-preview-roundtable-11/images/img12.png new file mode 100644 index 0000000..f1a9145 Binary files /dev/null and b/sources/cc-0801-pres-preview-roundtable-11/images/img12.png differ diff --git a/sources/cc-0801-pres-preview-roundtable-11/images/img13.png b/sources/cc-0801-pres-preview-roundtable-11/images/img13.png new file mode 100644 index 0000000..c6ffcaa Binary files /dev/null and b/sources/cc-0801-pres-preview-roundtable-11/images/img13.png differ diff --git a/sources/cc-0801-pres-preview-roundtable-11/images/img14.png b/sources/cc-0801-pres-preview-roundtable-11/images/img14.png new file mode 100644 index 0000000..2a071f8 Binary files /dev/null and b/sources/cc-0801-pres-preview-roundtable-11/images/img14.png differ diff --git a/sources/cc-0801-pres-preview-roundtable-11/images/img15.png b/sources/cc-0801-pres-preview-roundtable-11/images/img15.png new file mode 100644 index 0000000..dc49db6 Binary files /dev/null and b/sources/cc-0801-pres-preview-roundtable-11/images/img15.png differ diff --git a/sources/cc-0802-report-ioptest/document.adoc b/sources/cc-0802-report-ioptest/document.adoc new file mode 100644 index 0000000..46f529c --- /dev/null +++ b/sources/cc-0802-report-ioptest/document.adoc @@ -0,0 +1,405 @@ += February 2008 CalConnect Interoperability Test Report +:docnumber: 0802 +:copyright-year: 2008 +:language: en +:doctype: administrative +:edition: 2 +:status: published +:revdate: 2008-04-09 +:published-date: 2008-04-09 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Patricia Egen +:role: author +:fullname_2: Cyrus Daboo +:role_2: author +:fullname_3: Firdosh Ghyara +:role_3: author +:fullname_4: Gren Elliott +:role_4: author +:fullname_5: Michael Douglass +:role_5: author +:fullname_6: Mu Zhang +:role_6: author +:fullname_7: Simon Vaillancourt +:role_7: author +:fullname_8: Tomas Hnetila +:role_8: author +:fullname_9: Tony Becker +:role_9: author + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Participants + +.Participants +[options=header,cols="a,a,a,a"] +|=== +| Organization | Event Attended | Participants | Products Tested +| Apple | Regular | Cyrus Daboo (iCal Server) + +Wilfredo Sanchez (iCal Server) + +Scott Adler (iCal Client) + +Matt Shephard (iCal Client) + +Haley Allen (iCal Client) | iCal version 3.0.2 (1236) +| Kerio Technologies | Both + +Both | Tomas Hnetila + +Otakar Leopold | Kerio MailServer 6.5.0, a special build with CalDAV Realtime S2S Kerio Outlook Connector 6.5.0 (KOFF) +| Marware | Regular | Tony Becker | Project X 1.3.2 (6043) +| Microsoft | Regular | Firdosh Ghyara (Exchange) + +Mu Zhang (Entourage) | Entourage 2008 + +Exchange 2007 +| Oracle | Regular + +Mobile | Simon Vaillancourt + +Mike Zhou | +| RPI/Bedework | Regular | Mike Douglass | +| Scalix | Regular | Florian von Kurnatowski + +Gren Elliot | +| Sony Ericsson | Mobile | David Colter | +| Sun Microsystems | Regular | May Ma + +Erwin Rehme + +Yao Lu + +Yu Chen + +Robert Chien | +| Zimbra Yahoo | Regular | John Holder + +Hitaine Patel | +| CalConnect Reps | | | +| Interop Manager + +Interop Assistant + +Logistics | Regular + +Mobile + +Both +| Pat Egen + +Don Egen + +Dave Thewlis | Pat Egen "unofficially" tested Lotus Notes as part of the event +|=== + +== Introduction + +Participants of the testing event used predetermined test scenarios. Rather than post the full scenarios in +this document, they can be found on the CalConnect website at the following URL: +http://www.calconnect.org/ioptesting.shtml. The documents used in this testing event were the +CalConnect CalDAV Matrix for Draft 08 and the iCalendar Testing Matrix. Summaries and specific +findings and issues found are noted in this document. + +== Comments and Findings + +=== CALDAV testing + +==== Server vendor comments + +===== Server 1 + +The Interop went very well; it was nice to see so many vendors present at the event. As products get +more mature the issues found are more interesting and having a chance to discuss design +implementation details with other vendors is a great opportunity to improve our products. + +===== Server 2 + +This server vendor was mostly focused on `REALTIME` Server-to-Sever Scheduling. + +* Very difficult to do all tests. +* One client's recurrent event exception - deleted instance +** `EXDATE` is without time zone +** causes incompatibility with other clients +* Another client app - recurrent event exception - an instance moved to different time +** time is missing in `RECURRENCE-ID` => other clients are not able to recognize the +instance +** causes incompatibility with other apps +* Meeting requests/responses from a client are not recognized as iMIP messages +* One client had an issue with meeting requests on delegated accounts +* One client shows organizer twice in attendee list for meeting requests +* One client doesn't send update for declined meetings when location is changed +** not possible to setup delegation without Open Directory +** puts invitation to calendar without asking or noticing user when attendee address doesn't +match +* iCalendar and iTIP interoperability problem (upper case `MAILTO:`) +* One CalDAV client requires full permissions to other people calendars +** not possible to set permissions for others to create calendars +* An iCalendar client has free/busy incompatibility - returns free/busy in XML format by default. +Also had an issue with meeting ++ +-- +Realtime Server-to-Server scheduling + +** found & fixed bug RealTime scheduling +*** missing `DAV:href in ` +*** NOT YET fixed - incorrect Originator: address when sending meeting response +*** two spaces before HTTP version causes problem with another server (`POST` +`/pubcaldav/rtsvc HTTP/1.1`) - fixed in URL configuration +*** saw a minor issue in one server when timezone definition contains +comma/spaces (generated by a client in European timezone) +-- + +===== Server 3 + +We started discovering some extra bugs on Wednesday morning, mostly in the `freebusy` URI stuff. We did +quite a bit of testing with another CalDAV client. After determining the client doesn't support (valid) +absolute URLs in DAV responses we changed our server to return relative urls. They tested and ran into a +problem which prevented testing scheduling. We didn't have time to deal with that. Since the interop this +has been fixed and now works. + +Realtime server-server problems were generally small - problems with invalid certs from one client and +handling of authentication by another CalDAV server. + +One server had a problem with invalid HTTP which was resolved. + +===== Server 4 + +A CalDAV client tested against our server using the CalDAV Draft 8 scenarios provided the following +results. Please refer to the CalDAV document located on the CalConnect server as noted in the +Introduction section. + +Section 1 -- Event Creation:: All items passed. +Section 4 -- Event Deletion:: All items passed except 4.5 which failed. +Section 5 -- Access control:: N/A +Section 6 -- Calendar Management:: +6.1::: passed +6.2::: failed +6.3 -- 6.6::: N/.A +Section 7 -- Free Busy Reports:: +Setup::: Passed +7.1::: N/A -- Free busy sched works +7.1.1::: N/A +7.1.2::: Passed +7.1.3::: N/A +7.1.4::: Passed +7.1.5::: Passed +Section 8 -- Scheduling:: +Setup::: Passed +8.1 through 8.2::: Passed +8.3::: N/A +8.4::: Passed +8.5::: N/A +8.6::: Passed + +[EDITOR] +Scheduling is new in CalDAV Draft 8. We are starting to see clients +doing scheduling with servers. This is the first interop where we see scheduling actually being testing on +servers and clients. + +==== CalDAV Client Testing + +===== CalDAV Client 1 + +The following are general things noted with our client testing. + +* network communication stopped after receiving a 50x errors. +* did not treat calendar user addresses as case insensitive (e.g. `MAILTO` versus mailto). +* did not send updates for declined meetings when the location is changed +* did not handle authentication with a username and no password specified for a CalDAV account. +* did not handle absolute URLs for the calendar home set. +* did not handle retrieving events with inline attachments. +* did not gracefully handle CalDAV servers that did not support CalDAV scheduling. +* did not allow users to setup delegate access without Open Directory support. +* sent ``POST``s for an overridden event using a `RECURRENCE-ID` with different a time zone then +the `DTSTART` of the master event. + +The following is a list of server issues that encountered during testing: + +* Invitations were not put into the attendee's inbox. +* One CalDAV client tried to set an ACL on a new calendar and received a 501 error. +* Deleting calendar returned a 409 not a valid resource. +* Free busy worked on the first calendar but not on additional calendars. +* Principal URLs don't work as attendees. Only email addresses worked. +* Free busy worked on the first calendar but not on additional calendars. +* Principal URLs don't work as attendees. Only email addresses worked. +* did not receive any notifications for invitations or replies because no iTIP messages were placed +in the inbox. +* Re-inviting an attendee to an event did not change the attendee's `PARTSTAT` to `NEEDS-ACTION`. +* Server removed `X-WR-iTIPALREADYSENT` from the `VEVENT` when client does a `PUT`. +* not including a `METHOD` on iTIP messages placed in the `INBOX`. It appears that when doing a +`PROPFIND` on the inbox, returns ICS data from a calendar instead. +* A server failed to delete an overridden instance of a recurring meeting. +* When creating a new calendar, server did not maintain the displayname or calendar-color on the +calendar. +* not including a `METHOD` on iTIP messages placed in the `INBOX`. +* Deleting the fourth instance of a recurring meeting (Test 2.8) failed because server modified the +time of the `EXDATE`. +* Client tried to modify recurring events and overridden events but occasionally received a "304 not +modified". +* A server failed to create new calendars. +* Client tried to delete events but occasionally received 500 errors. +* Free busy didn't work for recurring events. +* client tried to create a new calendar but received a 503 error. +* A server modified/removed the organizer property on a `PUT`. +* Modifications to events immediately after creating them often resulted in the server not properly +persisting the change. This made it difficult to proceed with the more advanced tests such as +overriding recurring events. +* Scheduling and `FREE/BUSY` wasn't supported on some servers. + +===== CalDAV Client 2 + +* error message "Account information not found. Request encountered an unexpected error +(domain (null) code 0)" +* doesn't return Free/Busy data in correct format - probably we don't use correct URL +* error message when creating `TODO`: +** Request Error +** Request for "New To Do" in "Calendar" in account "xxxxx" failed. +** The server responded with "HTTP/1.1 415 UnsupportedMediaType" to operation +CalDAVWriteEntityQueueableOperation. +** Scheduling not implemented + +===== CalDAV Client 3 + +The following are testing comments. + +* The client works with several CalDAV servers. +* Doesn't work with several other servers because of one having no `MKCALENDAR`, one having a +bug with del/ mk calendar timing, which is being fixed), and with one that has a Character set +issue - my bug. +* My things to be fixed: +** Character set - from above +** Get inbox from properties - server venders have different schemes +* Overall things: +** Handling "floating" events, all-day, `freebusy`, etc. +* Overall Client things: +** Self signed or expired certificates. Most servers are "Beta" at best. +** We clients need to be able to deal with "bad" certificate errors. +** 207 response is "multipart" - must look deeper into body of response +*** could be all good/bad/mixed if asking for multiple properties. +* Overall Server things: +** Handling dates - there are a `LOT` of syntax options. For FreeBusy URL we were unable +to find a syntax that all servers were happy with. + +==== iCalendar Testing + +During iCalendar, iMIP and iTIP testing the following items were identified. + +===== iCalendar Client 1 + +* The results noted are the behaviors that were observed when a message is sent/received. +** General -- these apply for all vendor testing scenarios +*** Requesting a refresh of an invitation is not supported +*** Countering an invitation is not supported +*** Declining a counter is not supported +*** Delegate concept is different. +*** cancels don't work with one application +*** Attachments not going through +*** Accept invitation is not being processed properly. There is some problem +converting response messages. +*** Declining an invitation -- same as above +*** User C declines invitation - Responses fail iCalendar conversion +*** User C accepts invitation - Responses from one vendor fail iCalendar +conversion + +====== iTIP Testing + +* All items in the iTIP testing scenarios passed with the following notes: +** 4.1.1 create single event. Pass - Ran scenario by manually dropping a MIME file in +the pickup folder of the transport log. +** 4.1.5 Create an event using the Value parameter - day events always have a +timezone associated with it. +** `RSVP` responses to requests: client allows `RSVP` per email message and not per +attendee. Other mail servers do not have any indication to show how whether a +`RSVP` is required. One server sets the req and opt part as req participants - - this is a +bug. +** 4.2.4 Countering an Event -- counter is not supported in one server +** 4.2.5 Delegating an Event -- the concept of delegates is different than that of +RFC2445. +** 4.3 -- Publishing busy time -- not supported +** 4.4.6 -- Add new instance to a recurring event: adding a single instance is not +supported. The complete recurrence rule needs to be updated. +** 4.4.7 -- Add a new series of instances to a recurring event: Adding is not allowed. +You can change the recurrence object completely. `REFRESH` is not supported. +** 4.4.8 Counter an instance of a recurring event: Not supported +** 4.7.2 Bad Recurrence-ID: If an invalid iCalender is received server fails the +conversion of iCalendar and creates a simple IPM. Note message with the iCalendar +body as an attachment. + +===== iCalender Client 2 + +The client went through a number of the iMip tests between their client and another iCalendar client. The +following issues were spotted during that and also during client testing originated by other companies. + +*** An original All day event sent in a UK timezone ended up with time shifted to a specific California +timezone. +*** iCalendar sent on behalf of another user did not correctly specify this in the `ORGANIZER`, +although the MIME Sender: and From: headers were correct. +*** Canceled messages from other server ended up with 2 iCAL "`STATUS:CANCELED`" entries (not +in the original) +*** Meeting acceptances and cancelled meetings from a server caused problems with incoming +internet gateway. +*** An initial meeting request will often have a sequence number of 1, which another client considers +to be an update. +*** Sequence numbers in Exceptions were not being updated when changes were made to them. +*** One client discovered an issue where a cache of information for appointments was not being +updated when changes were made. This showed up when 2 clients were accessing the same +calendar, which may be quite a useful testing methodology as iCalendar. App's own caching +behaviour hides this bug in the originating client. +*** Thanks for all your work + +===== iCalendar Client 3 + +Using the test scenarios provided, we did the client to client testing with several CalDAV server webmail +clients and iCalendar clients to check compatibility. The testing generally covers basic calendar +scenarios including: + +. Invite for Single event, Recurring event, all day event, hourly event, multiday event. +. Update single event, series and occurrences in series by changing subject, location, time, date +and attendee. +. Cancel single event, series, occurrences in series +. Meetings with Org and Attendee in different time zones +. Calendar responses tracking + +===== Testing results + +Most tests passed. We are happy to see our application is compatible with most iCalendar formats +generated by other applications. + +General issues are: + +* Sequence number: +** Some CalDAV server/clients assume sequence number starts with 1 instead of 0. We +will show a different banner for such case. +** One client doesn't have this entry in iCalendar. They said using `SEQUENCE` is optional +for organizer according to RFC 2446. +* New issues found in our application +** Dragging event in Month view will cause a wrong Recurrence-ID generated if the series is +not in the same time zone as OS'. It doesn't repro with other views. + +Detailed test results: + +* One client doesn't support modified occurrence and negative exceptions well so far. So +most testing is done in single event. +* Sequence issue mentioned above +* We have a known issue: `EXDATE` doesn't have time zone information +* Another client said they support WebDAV but we couldn't connect to it. Most likely they +don't support it fully. They will do more investigation. +** The exception doesn't seem to relate to series much except in deletion. Opening +or updating such occurrence doesn't trigger the "for series or for this one" dialog. +Important change made to the series(like start/end time or recurring mode) +doesn't overwrite the exceptions. This is a different behavior from other clients. +* Another client had Sequence inconsistency - single event or recurring series' sequence +starts from 1 and increases for updates. But exception's in the series starts at 0 and +never increases. +* Recurring All day event from our application is not recognized as "All day" in their +application. It is shown as a 0 duration event happening each day. Same event synced to +another client is displayed correctly and it doesn't repro with single all day event in the +tested application. +* One CalDAV server uses `RDATE` which we do not support. The event can be displayed +correctly but the time zone is not recognized. +* One client had issues with modifying an occurrence in a recurring series that uses a +different time zone than calendar time zone. They generate a wrong Recurrence-ID +sometimes. They have the same sequence issue noted above. + +Overall this is a very interesting and useful InterOP event! Thanks for organizing it! + +== Summary + +This was one of our largest interoperability testing events. Several items were uncovered and generally it +was very successful. As usual, it would be nice to have more time. We will be investigating the concept +of ongoing, interim testing via the internet to public servers. This will improve the ability to test more +applications during our onsite testing events. + +Thank you to all the participants and their willingness to take time out of busy schedules to help +CalConnect forward the usage of calendaring standards. + +Respectfully submitted by Pat Egen, CalConnect Interop Manager. diff --git a/sources/cc-0803-report-ioptest/document.adoc b/sources/cc-0803-report-ioptest/document.adoc new file mode 100644 index 0000000..f903aad --- /dev/null +++ b/sources/cc-0803-report-ioptest/document.adoc @@ -0,0 +1,355 @@ += February 2008 CalConnect Mobile Interoperability Test Report +:docnumber: 0803 +:copyright-year: 2008 +:language: en +:doctype: administrative +:edition: 2 +:status: published +:revdate: 2008-04-09 +:published-date: 2008-04-09 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Patricia Egen +:role: author +:fullname_2: Mike Zhou +:role_2: author +:fullname_3: Tomas Hnetila +:role_3: author +:fullname_4: David Coulter +:role_4: author + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Introduction + +This was the first Mobile Calendar Interoperability testing event held by CalConnect. There was a +predetermined set of objects to test. It was determined early one that the testing document was quite +comprehensive and would never be completed in the two days we had for interop testing. Therefore, the +testing parties elected to choose several items from each testing group for interoperability testing. You +can find the full test suite at the following url: http://www.calconnect.org/ioptesting.shtml + +Two servers and one phone device were tested. For purposes of anonymity, the names of the vendors +are not referenced in this document. + +== Server 1 - Test Results with device vendor + +*Part I -- Calendar Tests* + +=== Events - Server to Device + +==== Create an Event with a Reminder + +OK except for: + +* Server to client alarm issue: Server created an alarm on device side regardless if server +event has an alarm. This is the default behavior by design and alarms can be turned off +by changing server configurations. +* Truncation issue: On device modify the location only. When sync'd back to server, the +location was restored with the long original value. The un-modified title was truncated on +server. Seems to be a bug on server. Need more investigation. + +==== Access Level and Priority + +Device does not support priority. + +==== Special Characters From Server + +OK + +==== Multi-Byte Characters From Server + +OK + +==== Deletion + +OK + +=== Events - Device to Server + +`X-PHONEOWNER` issue in device vCalendar: + +Device in some cases put `X-PHONEOWNER` as one parameter of the attendee indicating that the +attendee is the phone owner. `X-PHONEOWNER` doesn't have a value and this breaks the server parser. +Server should handle this. + +[source%unnumbered] +---- +VCALENDAR +VERSION:1.0 +BEGIN:VEVENT +UID:20080204T191415Z-405000-H2_Board +SUMMARY;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:Special=20chars=20=C6=92 +DESCRIPTION;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:=C2=A2=20=C2=A6=20& +DTSTART:20080204T191200Z +DTEND:20080204T194200Z +X-EPOCAGENDAENTRYTYPE:APPOINTMENT +CLASS:PUBLIC +LOCATION;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:=C2=A9 +SEQUENCE:-1 +X-METHOD:NONE +ATTENDEE;ROLE=ORGANIZER;STATUS=NEEDS ACTION;RSVP=NO;EXPECT=FYI;XPHONEOWNER: +name@server.com +LAST-MODIFIED:20080204T191415Z +PRIORITY:0 +STATUS:CONFIRMED +X-MOBILEOS-LUID:11 +END:VEVENT +END:VCALENDAR +---- + +[source%unnumbered] +---- +Exception=vendor.ocs.tm.icalendar.exception.ICalParseException: '=' expected after "XPHONEOWNER"(Parameter=X-PHONEOWNER)(Parameter in comp=VEVENT.prop=ATTENDEE) +at vendor.ocs.protocols.oma.ds.connector.calendar.VCalParser.parseSubComponent(VCalParser.java:232) +at vendor.ocs.protocols.oma.ds.connector.calendar.VCalParser.parseSubComponent(VCalParser.java:203) +at vendor.ocs.protocols.oma.ds.connector.calendar.VCalParser.parseComponent(VCalParser.java:148) +at vendor.ocs.protocols.oma.ds.connector.calendar.CalendarUtil.stringToVCalendar(CalendarUtil.java:225) +at vendor.ocs.protocols.oma.ds.connector.calendar.EventsStore.initIncomingEvent(EventsStore.java:1399) +at vendor.ocs.protocols.oma.ds.connector.calendar.EventsStore.addData(EventsStore.java:2259) +at vendor.ocs.protocols.oma.ds.connector.calendar.EventsStoreConnector.applyClientDataOperationById(EventsStoreConnector.java:201) +at vendor.ocs.protocols.oma.ds.connector.calendar.CalendarStoreConnector.applyClientDataOperationById(CalendarStoreConnector.java:129) +at vendor.ocs.protocols.oma.ds.protocol.executor.AddExecutor.execute(AddExecutor.java:312) +at vendor.ocs.protocols.oma.ds.protocol.executor.CmdExecutor.executeSubCommands(CmdExecutor.java:81) +at vendor.ocs.protocols.oma.ds.protocol.executor.SyncExecutor.execute(SyncExecutor.java:214) +at vendor.ocs.protocols.oma.ds.protocol.DsProtocolHandler.processMessage(DsProtocolHandler.java:720) +at vendor.ocs.protocols.oma.RequestProcessor.processRequest(RequestProcessor.java:334) +at vendor.ocs.protocols.oma.transport.servlet.OmaServlet.doPost(OmaServlet.java:103) +at javax.servlet.http.HttpServlet.service(HttpServlet.java:763) +at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) +at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:64) +at vendor.security.jazn.oc4j.JAZNFilter$1.run(JAZNFilter.java:396) +at java.security.AccessController.doPrivileged(Native Method) +at javax.security.auth.Subject.doAs(Subject.java:396) +at vendor.security.jazn.oc4j.JAZNFilter.doFilter(JAZNFilter.java:415) +at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:621) +at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:368) +at com.evermind.server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:866) +at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:448) +at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:302) +at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:190) +at vendor.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260) +at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303) +at java.lang.Thread.run(Thread.java:595) +Caused by: vendor.ocs.tm.icalendar.exception.ICalParseException: '=' expected after "XPHONEOWNER"( +Parameter=X-PHONEOWNER) +at vendor.ocs.protocols.oma.ds.connector.calendar.VCalParser.parseParameters(VCalParser.java:407) +at vendor.ocs.protocols.oma.ds.connector.calendar.VCalParser.parseSubComponent(VCalParser.java:230) +... 29 more +Caused by: vendor.ocs.tm.icalendar.exception.ICalParseException: '=' expected after "XPHONEOWNER"(Parameter=X-PHONEOWNER) +at vendor.ocs.protocols.oma.ds.connector.calendar.VCalParser.parseParameters(VCalParser.java:407) +at +vendor.ocs.protocols.oma.ds.connector.calendar.VCalParser.parseSubComponent(VCalParser.java:230) +... 29 more +Caused by: vendor.ocs.tm.icalendar.exception.ICalParseException: '=' expected after "XPHONEOWNER" +at vendor.ocs.protocols.oma.ds.connector.calendar.VCalParser.parseParameters(VCalParser.java:379) +... 30 more +---- + +==== Create an Event with a Reminder + +OK except for: + +* Client to Server alarm issue: Server didn't create an alarm on server side regardless if +device event has an alarm. Device did include alarm in the vCalendar, however importing +the vCalendar to a calendaring client supporting vcalendar didn't result in an alarm either. +Need more investigation. Following is the vCalendar from device. + +[source%unnumbered] +---- +VCALENDAR +VERSION:1.0 +BEGIN:VEVENT +UID:20080204T184223Z-263000-H2_Board +SUMMARY:CalConnect Day 2 +DESCRIPTION:The Mike and Dave Show! +DTSTART:20080205T160000Z +DTEND:20080206T020000Z +X-EPOCAGENDAENTRYTYPE:APPOINTMENT +CLASS:PUBLIC +LOCATION:Sun Microsystems +SEQUENCE:-1 +X-METHOD:NONE +AALARM;TYPE=X-EPOCSOUND:20080205T155000Z;;0;0x100048ac0x00000205 +LAST-MODIFIED:20080204T184223Z +PRIORITY:0 +STATUS:CONFIRMED +X-MOBILEOS-LUID:10 +END:VEVENT +END:VCALENDAR +---- + +==== Access Level and Priority + +* can only be done if device supports setting an access level or priority +* Device not supporting priority. + +==== Special Characters From Server + +OK + +==== Multi-Byte Characters From Server + +* Device can't display the multi-byte characters (no font, normal). Chars were sent back to server +correctly when modified. + +==== Deletion + +OK + +=== All Day Events - Server to Device + +==== Create all-day event in same time zone + +OK + +==== Create all-day event to device in different time zone + +OK + +==== Create a Single Instance All Day Event with Reminder + +OK except for truncation issue: + +* Sync server day event to device, title and location were truncated. Modify title on device and +sync, event remains same on server and device change is rolled back. Modify location on device, +changes are propagated to server but title is also truncated on server. Seems to be a bug on +server. Need more investigation. + +==== Create an anniversary all-day event + +Recurrence issue: Server only sends one instance of the event to device. This was because that +server splits the recurrence and only sends the instances within sync range to device. + +==== All-day event on last day of month & last day of year check + +OK + +==== Create a Single Instance Holiday with Reminder + +Not supported by device. + +==== Update an all-day event on server and synchronize back to mobile device in same time zone + +OK + +==== Update an all-day event on server and synchronize back to a device in different time zone + +OK + +==== Create a Single Instance Multi-day Day Event + +OK + +==== Remove Single Instance Meeting, Day Event, and Holiday + +OK + +=== All Day Events - Device to Server + +==== Create an all-day event and synchronize to a server in same time zone + +OK + +==== Create an all-day event and synchronize to a server in different time zone + +OK + +==== Create a Single Instance All Day Event with Reminder + +OK + +==== Create an anniversary all-day event + +OK + +==== Update an all-day event on mobile device and synchronize back to server in same time zone + +OK + +==== Update an all-day event on mobile device and synchronize back to a server in different time zone + +OK + +==== Create a Single Instance Multi-Day Day Event + +OK + +==== Remove Instance Meeting, Day Event, Holiday + +OK + +=== Repeating Entries + +This section was not tested extensively but the basics worked. The server splits the recurrence and only +sends the instances within sync range to device. + +=== Scheduling + +==== Create Entry as owner with Attendees from Server + +OK except for: + +* Owner email wrong: owner email was name@vendor.com, however it was shown as +name@othername.com. Seems to be server bug. +* Owner email was not first on the attendee list. Need to find out whether it is server or client +bug. +* Client doesn't support attendance status. Server should put the info into the meeting +description as is done for Windows Mobile Smartphone. + +== Server 2 and device Testing Comments + +=== Device vendor comments + +An attempt was made to interoperate between the device and our servers but this proved to not be very +fruitful at this event. The device vendor did advise the server vendor on the one defect found for their +server: Phone was in different time zone from server. Created a contact on the phone with a birthday, +adding birthday to the phone calendar. Synced to server. Contact on server had the birthday on the +correct day but the calendar on the server had the birthday on the wrong day, due to time zone +adjustment. + +Also, a mobile OS contacts (which was the area the device vendor was testing informally) do not match +up to other servers' format for contact data (e.g.a calendaring client supporting vCalendar) especially +where differentiations like Mobile (w) and Mobile (h) are concerned. + +=== Server 2 Testing Comments + +Mobile IOP test suite is very comprehensive. It is very difficult to do all tests. + +* week GSM signal at IOP place - difficult to test +* new device is disabled by default in our Server. It was necessary to enable it. +* DirectPUSH fails after couple of minutes with, it works fine with different device +** we don't know yet if it is client or server issue +* Birthday problem: +.. create new Contact with birthday and let device to create event in your calendar +.. synchronize it to server +.. open Calendar in client (EST) which is in different timezone than mobile device (GMT) +** Result: birthday is one day early +*** we are not sure, if it is correct or not +*** general question: how to present all day events in different timezones + +== Summary + +The first mobile interop testing was a success. We learned a couple of things. First, we need to ensure +we are located in a facility that has good cell coverage. The room we occupied had occasional issues +with cell phone coverage. The best approach would be to test rooms we will be utilizing prior to starting +the event so we can ensure we have adequate coverage. + +The other thing we determined was the test scenario document has too many items to test in two days. +We are not even sure we can test everything within three days. What was done this time was the +vendors chose to test specific items from each group in an effort to try to cover as much as possible. For +future testing, we may choose to break down the testing into specific areas. In other words, we may test +section one during one event, section two during the next event, and so on. Or we may determine which +items are the most critical to testing, and focus on them during the next events. This will be decided +before the next Mobile interoperability test event is held. + +Our thanks to the participating vendors. + +Respectfully submitted by Pat Egen, CalConnect Interop Manager. diff --git a/sources/cc-0804-report-ioptest/document.adoc b/sources/cc-0804-report-ioptest/document.adoc new file mode 100644 index 0000000..6b5cc4a --- /dev/null +++ b/sources/cc-0804-report-ioptest/document.adoc @@ -0,0 +1,246 @@ += June 2008 CalConnect Mobile Interoperability Test Report +:docnumber: 0804 +:copyright-year: 2008 +:language: en +:doctype: administrative +:edition: 1.3 +:status: published +:revdate: 2008-08-31 +:published-date: 2008-08-31 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Patricia Egen +:role: author +:fullname_2: Bruno Browning +:role_2: author +:fullname_3: Cyrus Daboo +:role_3: author +:fullname_4: Mike Douglass +:role_4: author +:fullname_5: Gren Elliot +:role_5: author +:fullname_6: John Holder +:role_6: author +:fullname_7: Florian von Kurnatowski +:role_7: author +:fullname_8: Emil Lundberg +:role_8: author +:fullname_9: Jong Yoon Lee +:role_9: author + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Participants + +.Participants +[options=header,cols="a,a,a"] +|=== +| Organization | Participants | Products Tested +| Apple | Cyrus Daboo | iCal Server and client - OS X 10.5.3 + +iCal client 3.03 +| Mozilla | Bruno Browning | Sunbird/Lightning 0.9pre + +Mozilla Calendar CVS pull (mid-May sometime) +| RPI/Bedework | Mike Douglass | Bedework server 3.5 +| Scalix | Florian von Kurnatowski + +Gren Elliot | 11.4.1 pre-release +| Zimbra Yahoo | John Holder + +Jong Yoon Lee | Zimbra Server pre 5.0.7 (nightly) +| Uppsala University, Sweden | Emil Lundberg - Observer | iCal 3.0.3 (1244) +| CalConnect Reps | | +| Interop Manager + +Logistics | Pat Egen + +Dave Thewlis | +|=== + +== Introduction + +Participants of the testing event used predetermined test scenarios. Rather than post the full scenarios in +this document, they can be found on the CalConnect website at the following URL: +http://www.calconnect.org/ioptesting.shtml. The documents used in this testing event was the CalConnect +CalDAV Matrix for Draft 08, in particular the scheduling section. This was one of the first interops where +we had clients that supported the scheduling portion of CALDAV. Summaries and specific findings and +issues found are noted in this document. + +== Participant Comments and Findings + +=== Vendor 1 + +This vendor stated they were pleased to take part in the CalConnect interoperability event. Their testing +focused on a server product with a client to ensure their scheduling support was working well and they +certainly made big strides there. Other server vendors were doing a lot of their own testing with a client +and they were able to help them out on a few issues. + +No major issues were found, though some follow-up is needed on specific client behaviors that other +vendors asked about. Now looking forward to the next event. + +=== Vendor 2 + +The vendor was mostly testing a client and their implementation of scheduling. + +Generally the baseline CalDAV stuff worked well with all the servers present for testing. They did see +some oddities interacting with recurring items on one server but otherwise all was good. + +CalDAV-sched was also working well after some bugs were fixed at the interop. This was tested most +thoroughly with another vendor offering but was able to send invitations successfully with two other +servers as well; they did not test those for `REPLY` creation or handling. + +CalDAV-sched (including `freebusy`) is not yet working with one of the vendors present. The tester felt the +chance to meet and interact with the other developers as well as their code was invaluable and has +continued to be a benefit since the event. The only ways they can think of to improve it would be to +increase some parameters: length of event, number of participants, and frequency of occurrence. +However, they realize that all of those are difficult. + +=== Vendor 3 + +The main value of the interop to this vendor was being in the same room as some of the other +developers. This was invaluable for learning about how to configure better logging and also in diagnosing +issues in both clients and our server. + +Their CalDAV Schedule support did not work at all with one of the clients and they spent a lot of time +diagnosing issues with that and fixing them. They didn't support principal-property-search reports, for +instance, which was a major blocker. + +When updating a calendar entry, the server was using the HTTP status code of Created, which is +incorrect for an update. The other vendor application was unhappy with this status code. It was creating +meetings without an `ORGANIZER` at one point and this resulted in the server creating corrupt +`ORGANIZER` fields in subsequent accesses. + +Initial testing yet another vendor showed that the test version of that vendor's application was not +recognizing our Meeting Requests at all. This was subsequently fixed by them. + +A lack of iMip support prevented IOP testing with two of the server applications at the event. + +=== Vendor 4 + +This was a relatively quiet CITE but useful nonetheless. + +One of the other vendors managed to find some CalDAV issues with our application. Those that were +bugs were fixed and retried. + +The one specific bug that might affect others is that our application wasn't always handling content-type +correctly when the character set was appended. + +Scheduling using another vendor seemed to work fine. + +This vendor also was pleased with the interop event. + +=== Vendor 5 + +During the interop testing, this vendor found four significant issues of mention. Their application +performed well in general testing against three other clients. + +We also took the time to test free busy interop as well as iCal compatibility with two vendors. Their +application performed well under these tests. + +We also discussed the need to validate the need to validate (in some capacity) the changes that are +pushed out on events that have multiple attendees. + +==== Issues Found + +. Creating a New Calendar, the event will throw 500 +** `Error: dav - error handling method PUT com.xxxx.xx.dav.DavException: cannot create` +** Summary: When creating a new collection, the server may not return the correct collection type. +. When Adding an Attendee to an Event on another Domain, `PERM_DENIED` +** `Error: calendar - Unable to process iCalendar attachment` +`com.xxxxxxx.common.service.ServiceException: permission denied: calendar invite not allowed from (Sender)` +** Summary: When creating an event via CalDAV, and adding an attendee that is not part of the +domain, the server will throw this error. No impact on delivery/event. +. MultiGet Problem with Calendars that have encoding\Characters that have encoding are escaped twice +** `Error: HTTP/1.1 404 Not Found` +** Summary: When using multiget clients and/or if user's have calendars that have names that have +characters that must be encoded, the calendar isn't visible. +. Validation of incoming iMIP messages and calendar `SPAM` +** Error: None, but impact is invalidated users can edit/change events; unscrupulous individuals can +add spam events to calendars, unchecked. + +=== A Neutral Observer + +It is common for us to have observers to the interop. This time the observer chose to actually do some +"neutral testing" on their own. These are their comments. + +This organization is interested in implementing a university-wide (and possibly inter-university) +calendaring service to complement the web, e-mail, and other services (IM also coming), so we are +interested in calendaring standards for two reasons: + +. Can we hope to implement open and common standards for calendaring usable by multiple clients +and/or are there third party vendors that can offer this capability, as well as interacting with proprietary +protocols? +. If so, we are (or should be) willing to contribute to the evolution of such standards, to the best of our +ability. + +Generally, the IOP event was a rewarding exercise, stressing our own test environment (iCal server) as +well as different vendors' servers and taking part in the discussions that followed. As discussed with the +Executive Director previously, we will consider joining either as an individual university. + +== Summary + +While the event was smaller than usual, this was our first event where we were able to test scheduling +with CALDAV clients. Several vendors tested client and server scheduling. + +Several items were uncovered and generally it was very successful. As usual, it would be nice to have +more time. + +We are continuing our work on a virtual testing environment to enable ongoing, interim testing via the +internet to public servers. This will improve the ability to test more applications during our onsite testing +events. + +Thank you to all the participants and their willingness to take time out of busy schedules to help +CalConnect forward the usage of calendaring standards. + +Respectfully submitted by Pat Egen, CalConnect Interop Manager. + +[appendix] +== Uppsala University, Sweden + +[cols="a,a,a,a,a,a,a,a",options=header,headerrows=2] +|=== +5+^| Servers 2.2+| .2+| Comments +| One | Two | Three | Four | Five + +| | | | | h| 1. h| Event creation. | +| P | | P | P | P | 1.1. | Create new single-instance meeting titled "Meeting 1.1" with the location "Durham". | +| P | | P | P | P | 1.2. | Create new meeting titled "Meeting 1.2" recurring every Monday from 10:00 AM to 11:00 AM for 4 weeks. | +| P* | | P | P** | P | 1.3. | Create new single-instance meeting titled "Meeting 1.3" with 2 other attendees. | * & ** No cuaddr to test with, used CalDAV1 & CalDAV2, got '?'. Could use iMIP, and update status though email. NB: for iMip, e-mail address of sender/organizer must match cuaddr (problem w/ many e-mail addresses configured on either client) +| P | | P | P | P | 1.4. | Create new single-instance meeting titled "Meeting 1.4" with an alarm set to trigger 15 minutes prior to the schedule time of the meeting. | +| | | | | h| 2. h| Event modification | +| P | | P | P | P | 2.1. | Modify the title of meeting "Meeting 1.1" to "Meeting 1.1bis". | +| P | | P | P | P | 2.2. | Modify the location of the meeting "Meeting 1.1bis" to "Seattle bis". | +| P | | P | P | P | 2.3. | Reschedule meeting "Meeting 1.1bis" to the next day. | +| P | | P | P | P | 2.4. | Add an attendee to "Meeting 1.1bis". | +| P | | P | P | P | 2.5. | Add an alarm to "Meeting 1.1bis". | +| P | | P | P | P | 2.6. | Modify the title of the 1st instance of the recurring meeting created in 1.2. | +| P | | P** | P | P | 2.7. | Modify the participation status of the 1st attendee in meeting 1.3 to `DECLINED`. | ** iMIP broken on test server. +| P | | P | P | P | 2.8. | Cancel the 4th instance of the recurring meeting created in 1.2. | +| P | | P | P | P | 2.9. | One client changes "Meeting 1.1bis" to a different time, second client 'refreshes' its display to see the modification. | +| | | | | h| 4. h| Event deletion | +| P | | P | P | P | 4.1. | Delete a single non-recurring meeting. | +| P | | P | P | P | 4.2. | Delete a single recurring meeting with no overridden instances. | +| P | | P | P | P | 4.3. | Delete a single recurring meeting with overridden instances. | Deleting all instances, even those that are already deleted. +| P | | P | P | P* | 4.4. | Delete a non-overridden instance of a recurring meeting. | The FIRST time (only) a single but repeated instance is deleted, it comes back! +| N | | N | N | N | 4.5. | Delete an overridden instance of a recurring meeting. | +| | | | | h| 5. h| Access Control | +| *N* | | *N* | *N* | N | 5.1. | View access control details on current user's main calendar. | +| *N* | | *N* | *N* | N | 5.2. | Change access control details on current user's main calendar to add another user with read-only access. Verify that other user can view the calendar but not change it. | +| *N* | | *N* | *N* | N | 5.3. | Change access control details on current user's main calendar to add another user with read-write access. Verify that other user can view the calendar and change it. Verify that changes done by one user are seen by the other. | +| *N* | | *N* | *N* | N | 5.4. | Remove another user's access to the current user's main calendar and verify they can no longer access the calendar. | +| | | | | h| 6 h| Calendar Management | +| N | | N | N | N | 6.1 | Browse the list of calendars on the server, including the current user's personal calendars. | +| P* | | P | P | P | 6.2 | Create a new calendar in the current user's personal calendar space. | * Can create calendar, but it not writable. Will do after restart of client. Bug fixed in server! +| N | | N | N | N | 6.3 | Create a regular collection in the current user's personal calendar space. | +| N | | N | N | N | 6.4 | Create a new calendar inside the collection created in 6.3. | +| P | | P | P | P | 6.5 | Delete the calendar created in 6.2. | +| N | | N | N | N | 6.6 | Delete the collection created in 6.3. | +|=== + +[%key] +P:: Pass +F:: Fail +N:: Not supported (by client) diff --git a/sources/cc-0805-mobile-recurrence-iop/document.adoc b/sources/cc-0805-mobile-recurrence-iop/document.adoc new file mode 100644 index 0000000..5bc5277 --- /dev/null +++ b/sources/cc-0805-mobile-recurrence-iop/document.adoc @@ -0,0 +1,269 @@ += Mobile Recurrence Interoperability Recommendations +:docnumber: 0805 +:copyright-year: 2008 +:language: en +:doctype: report +:edition: 1 +:status: published +:revdate: 2008-07-29 +:published-date: 2008-07-29 +:technical-committee: MOBILE +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Chris Dudding +:role: editor +:affiliation: Symbian Ltd +:fullname_2: Mark Paterson +:role_2: editor +:affiliation_2: Oracle Corporation + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +This document describes interoperability problems observed in the +implementation of recurring events in mobile devices and provides +recommendations for how these issues can be avoided. + +== Executive Summary + +The ability to share calendar information among different applications and +across network boundaries has become an important business need, as a +growing number of organizations look for ways to leverage their investments +in collaborative applications. + +The Mobile Technical Committee (TC-MOBILE) of the Calendaring & +Scheduling Consortium published the results of a mobile calendaring +questionnaire in July 2006. Of concern were answers related to calendar +synchronization. Synchronization was one of the main things users did, but it +was also singled out as one of the main things that did not work well yet. This +can be attributed, in a large part, to issues related to data object +interoperability. + +One of the main issues is that iCalendar has not been widely adopted within +certain application spaces. Although adopted by all major time management +solution vendors, there has been reluctance within the mobile industry to +migrate from vCalendar (iCalendar's predecessor) based solutions and to fully +embrace iCalendar. To help persuade mobile vendors the Mobile Technical +Committee (TC-MOBILE) of the Calendaring & Scheduling Consortium +recently published a white paper titled: The Benefits of iCalendar for the +Mobile Industry <>. + +Even with iCalendar based solutions however significant issues often exist +with recurring events. The Recurrence Technical Committee (TC-RECURR) +of the Calendaring & Scheduling Consortium published a full set of problems +and recommendations: iCalendar RECURRENCE PROBLEMS AND +RECOMMENDATIONS <>. + +The Mobile Calendar Interoperability Test Suite <> describes a test +suite to assess a mobile device's capability to synchronize calendar data with +a calendar store. The repeating events section of this test suite often reveals +the interoperability issues regarding these types of events. + +This white paper further explores issues related to recurring events that are +specific to the mobile space and recommends possible solutions for both +client and server vendors. + +== Problems with the implementation of Recurrences on Mobile Devices + +Although mobile calendar synchronization solutions have matured over the +past years, providing for the most part reliable mobile-side representations of +user's calendar information, severe problems can exist with synchronization of +repeating events. Often the calendar on the device does not accurately reflect +irregular or changing instances of repeating events on the server. This basic +mismatch can then turn into corruption of the server data if these irregularities +are sent back to the server for example in the case where an OMA Data +Synchronization slow sync might be triggered. + +There are several causes of mismatched device and server recurring events +that are directly related to the way in which devices support <> (in many +cases <>). + +* Some devices do not support either sending or receiving `RDATE` or +`EXDATE` although they support `RRULE`. +* Some devices support one or the other. +* Some devices don't support any of the three. + +For implementers that insist on continuing to use <> rather then <> there +is the issue that <> does not support the notion of making any changes to +an instance of a recurring event other than rescheduling the start time and +date; yet many events also change their `LOCATION`. The use of the <> +`RECURRENCE-ID` property would easily solve this issue but implementers +need to be willing to move to <>. + +Even if an implementation supports `RRULE` the actual set of rules that the +implementation can handle is normally far less then what is defined in <>. + +One large underlying problem surrounds the misinterpretation of the +`OPTIONAL` nature of some properties in <> and <>. This has lead to the +belief that supporting the full set of properties is not required, resulting in poor +interoperability between products that support different sub-sets of properties. + +In order to deal with these interoperability problems there needs to be a +proper understanding between client and server implementers on what should +be supported. The next section defines three levels of support. The two +sections following it provide recommendations on how both device +implementations and server implementations should deal with each level. + +== Recurrence Support Levels for Mobile Devices + +=== Level 0: Device provides no support for repeating events + +The easiest level of support for a mobile device to provide is not to support +repeating events at all. Although this restricts the usability of the mobile +calendar, clients that do not support repeating events are straightforward for +server implementations to react to accordingly. + +=== Level 1: Device can handle recurrence rules (i.e. supports `RRULE`) + +If a mobile device allows a user to create a repeating event then it should +support the following recurrence patterns: + +. Daily, Weekly, Monthly by date, Yearly +. Plus: Monthly by day +. Plus: Weekdays +. Plus: Repeating every n weeks + +These repeating events should be sent to the server using `RRULE` +accordingly and the client should be able to accept these same `RRULE`s +coming from the server. + +=== Level 2: Device can handle recurrence rules with exceptions and extra dates (i.e. supports `RRULE`, `RDATE`, `EXDATE` and `RECURRENCE-ID`) + +If a mobile device supports this level of support then users should be able to +create repeating events as defined as part of Level 1 and in addition be able +add exceptions and extra dates. + +These repeating events should be sent to the server using an appropriate +combination of `RRULE`, `RDATE`, `EXDATE` and `RECURRENCE-ID` properties +and the client should be able to accept these same combinations coming from +the server. + +== Recommendations for Synchronization Clients (Mobile Devices) + +[recommendation] +==== +The starting point for solving interoperability issues is +for all implementations to be based on <>. +==== + +[recommendation] +==== +The level of recurrence support supported by your +implementation should comply with one of the 3 levels defined in this paper +==== + +[recommendation] +==== +The client's calendar store should have Level 2 +recurrence support to achieve the best interoperability. + +Level 0: OMA DS based solutions should not indicate support for any <> +related recurrence properties within their device information object. + +Level 1: OMA DS based solutions should indicate support for the <> +`RRULE` property within their device information object and by doing so are +indicating they support all of the recurrence patterns defined as required for +this level of support. + +Level 2: OMA DS based solutions should indicate support for the <> +`RRULE`, `RDATE`, `EXDATE` and `RECURRENCE-ID` properties within their +device information object and by doing so are indicating they support all of the +recurrence patterns defined as required for this level of support as well as +support for modified and delete exceptions as well as support for extra dates. +==== + +By adhering to these recommendations server implementations can then +reliably react to these 3 levels of support as defined in the following section. +It is strongly encouraged that support for recurrence level 2 is provided in the +client's calendar store. This will ensure that the complex recurrences can +received and displayed, even if the mobile user interface restricts the creation +and modification of events to level 1 recurrences. + +== Recommendations for Synchronization Servers + +[recommendation] +==== +The starting point for solving interoperability issues is +for all implementations to be based on <>. +==== + +[recommendation] +==== +Your implementation must be able to react to the level +of recurrence support reported by the client implementation connecting to +your server as follows: + +Level 0: All repeating events should be expanded and single instance events +should be sent to the mobile device. This should not in any way affect the fact +that server side the event is considered recurring. The mobile limitation should +not degrade the level of support provided by the Calendar store. + +A full set of test cases designed to assess a server's ability to deal with a +mobile device claiming level 0 support can be found in <>. + +Level 1: The server should be able to support receiving the <> `RRULE` +property from device implementations. Repeating events created on the +server, which adheres to the patterns defined as required for level 1 support, +should be sent to the device as an `RRULE`. Any repeating event that is +created with a pattern more advanced then those defined for level 1 support +however should be expanded and single instance events should be sent to +the mobile device (as is defined for level 0 support). Finally events that get +edited on the server which were sent to the device using an `RRULE` which +now contain any form of exception or extra date should result in a delete +being sent to the device to remove the repeating event and the newly edited +event on the server should be expanded and single instance events should be +sent to the mobile device (as is defined for level 0 support). + +A full set of test cases designed to assess a server's ability to deal with a +mobile device claiming level 1 support can be found in <>. + +Level 2: Support should be as defined for Level 1 except that if a user edits a +repeating event on the device the server must be able to accept the +appropriate combination of `RRULE`, `RDATE`, `EXDATE` and `RECURRENCE-ID` +that will result and if such an edit is done server side it should send the +device the appropriate combination (rather than a delete and expanding the +edited meeting as defined for level 1). + +The server should not expand repeating events to single instance (non-repeating) +events. The `RDATE` property can be used represent advanced +recurrence patterns beyond what is defined in level 1 support. This will ensure +the instances are shown as a single recurrence set on the device. + +A full set of test cases designed to assess a server's ability to deal with a +mobile device claiming level 2 recurrence support can be found in +<>. +==== + +== Conclusion + +Significant interoperability issues often exist with recurring events. This is +damaging user confidence in mobile calendar synchronization solutions. The +support levels defined in this paper and the recommendations for both client +and server implementations, if adhered to, should go a long way to helping +address these interoperability issues. + +By reacting to the levels of support per these recommendations server +implementations can ensure that the user always sees an accurate +representation of repeating events on their mobile device. The fact that an +event is part of a recurrence may not make it to the mobile device in some +cases but users will always have an accurate representation of their day. + +[bibliography] +== References + +* [[[mobileical,CC/Adv 0611]]] + +* [[[recurissues,CC/R 0604]]] + +* [[[testsuite,CC/S 0706]]] + +* [[[ical,RFC 2445]]] + +* [[[vcal,vCal]]], "The Electronic Calendaring and Scheduling Exchange Format", Internet Mail Consortium, http://www.imc.org/pdi/vcal-10.txt + diff --git a/sources/cc-0806-pres-preview-roundtable-13/document.adoc b/sources/cc-0806-pres-preview-roundtable-13/document.adoc new file mode 100644 index 0000000..b061077 --- /dev/null +++ b/sources/cc-0806-pres-preview-roundtable-13/document.adoc @@ -0,0 +1,469 @@ += CalConnect Technical Preview - Roundtable XIII +:docnumber: 0806 +:copyright-year: 2008 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2008-10-08 +:published-date: 2008-10-08 +:technical-committee: CALCONNECT +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:imagesdir: images + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks +and Disclaimer of Warranty for External (Public) Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Note Well + +* This presentation reflects in-progress +work and activities of CalConnect +* CalConnect rules governing disclosure +of such work applies +* As always you can discuss this work +freely within the CalConnect +community +* Outside of CalConnect: +** You may discuss the preview and +the work being done in general +** Please do not identify the +organizations and individuals that +are participating +** Please do not discuss specific details +and be cautious about inferences + +== Introduction + +CalConnect members have produced a +Technical Demonstration of key +calendaring and scheduling +technologies being developed by +CalConnect. + +This serves as a technology "preview" +only and does not in any way represent +final protocols or products. + +Our goal is to solicit feedback from +members and invited guests on the +presentation itself as well as the +technologies being demonstrated. + +We also hope to show how CalConnect +is successfully achieving its goal of +improving calendaring and scheduling +standards. + +== Agenda + +* Introduction to CalConnect +* Technical Previews +** CalDAV Scheduling +** iSchedule +** Internet Freebusy +* Conclusion +* Q&A + +[%unnumbered] +image::img01.png[] + +== Introduction to CalConnect + +=== What is CalConnect + +An information technology +consortium focused on calendaring +and scheduling that is a partnership +between vendors and customers. + +[quote] +Our vision of the future is not only +interoperable calendaring, but ubiquitous +interoperable calendaring. Calendaring +should--and can--be as ubiquitous as +electronic mail. + +=== Why do we need it? + +Our goals: + +* improve general understanding +* promote the technologies +* improve the technologies, in +particular interoperability + +[quote] +The driving premise behind the Consortium +is that interoperability between calendaring +programs and systems is essential to +achieving the promise and future growth of +calendaring. + +=== Current Membership + +[%unnumbered] +image::img02.png[] + +=== Done so far? + +* Substantial input to the IETF on new +versions of calendaring RFCs (e.g., +recurrences, timezones, and +minimum interoperability subsets) +* Work on CalDAV, CalDAV Scheduling, +and extensions to CalDAV +* Recommendations and guidance on +Extended Daylight Savings Time +* Timezone Registry and Service +Recommendations +* Mobile Calendaring white paper and +Interoperability Test Suite +* Mobile Calendaring Recurrence +support +* Surveys and use cases for calendaring +events, tasks (``VTODO``s) +* Calendaring Glossary +* Calendar Administrator's mailing list +* Thirteen successful IOP test events +between C&S implementations +* First Mobile Calendaring IOP test +event +* Demo of Federated Freebusy data +consolidation in 2006 + +=== Ongoing work? + +* TC-CALDAV +* TC-EVENTPUB +* TC-FREEBUSY +* TC-IOPTEST +* TC-ISCHEDULE +* TC-MOBILE +* TC-TIMEZONE +* TC-USECASE +* TC-XML + +=== Where is it going? + +* Continue with core goals +* Calendaring libraries/APIs to assist +implementations +* Calendaring as a platform (e.g. project +management) +* Types of calendaring infrastructures +(e.g. enterprise, federation, services, +ad hoc) +* Expand participation in new areas +** Vertical industry focus (e.g., mobile +operators) +** Government and private industry +customer perspective +** Overseas (Europe in short term, +Asia after) + +== Technical Previews + +* Today we will demonstrate: +** CalDAV Scheduling +** iSchedule +** Internet `freebusy` lookups using +`freebusy` URLs +* Each presentation will consist of: +** Introductory slides +** Live demonstration + +== CalDAV Scheduling -- How it works + +=== Introduction to CalDAV + +* RFC4791 defines the CalDAV Access +protocol. +* Built on core internet technologies + +[%unnumbered] +image::img03.png[] + +.Multiple Users can Access and Share Calendars +image::img04.png[] + +=== CalDAV Scheduling + +How it works: + +* Several users on one CalDAV server +(any client) schedule with each +other +* One user is the "Organizer", others +are "Attendees" + +.One is the Organizer, others are Attendees +image::img05.png[] + +There are two parts to scheduling: + +* Freebusy lookup +* Sending invitations and receiving +replies + +Freebusy results are returned +immediately. + +Invitation replies are sent only after +users inspect and accept or decline. + +Each user has an "Outbox" and an +"Inbox". +The "Outbox" is used to trigger +`freebusy` lookup. +The "Inbox" is where invites or replies +are delivered. +Changes to events trigger scheduling. +Clients monitor the "Inbox" for +incoming scheduling messages. + +.Sequence of diagrams showing free-busy lookup. +==== +.Organizer sends `freebusy` request to the server. Server calculates and returns `freebusy` data for attendees. +image::img06.png[] + +.Organizer sees `freebusy` for everyone. Adjusts for free time for everyone. +image::img07.png[] +==== + +.Sequence of diagrams showing invitations being sent out, replies returned. +==== +.Organizer sends invite request to the server. Server copies the request into each attendees' Inbox. Attendees see the invites when they next check the server. +image::img08.png[] + +.Attendee replies to the server. Server copies the reply into the organizer's Inbox. Organizer sees the reply when they next check the server. +image::img09.png[] +==== + +==== Demonstration #1 -- Simple meeting between two people + +.Demo Participants +image::img10.png[] + +==== Demonstration #2 -- Simple meeting between multiple people with different clients some CalDAV others using a CalDAV "connector" + +.Demo Participants +image::img11.png[] + +== iSchedule -- How it works + +=== Basic Concept + +* Provides the ability for users on +different calendaring systems to +schedule meetings with each other +* Instantaneous `freebusy` lookups +* Invites, replies sent as "messages" +with delivery status immediately +returned + +=== Can't this be done today? + +* But I can do scheduling with my +colleagues today! +* True, but only people on the same +server as you, or via some other +communication process such as email +or telephone. + +=== Design of iSchedule + +* Built on core internet technologies +* Can be used with any type of +calendar store (does not depend on +CalDAV) + +[%unnumbered] +image::img12.png[] + +.Organizer and Attendees on different systems +image::img13.png[] + +.Sequence of diagrams showing `freebusy`. +==== +.`Freebusy` response comes back immediately +image::img14.png[] + +.Organizer sees `freebusy` for everyone. Adjusts for free time for everyone. +image::img15.png[] +==== + +.Sequence of diagrams showing invites and replies. +==== +.Organizer sends invite request to their server. Server sends the invite to each attendee's server. Attendees see the invites when they next check the server. +image::img16.png[] + +.Attendees reply to their server. Server sends the reply to the organizer's server. Organizer sees the reply when they next check the server. +image::img17.png[] +==== + +=== iSchedule Demonstration + +==== Two calendar users in different domains + +.iSchedule Demo Setup +image::img18.png[] + +==== Four calendar users in different domains + +.iSchedule Demo Setup +image::img19.png[] + +== Freebusy URL + +=== What is Freebusy? + +* A list of free and busy periods for a +particular calendar user or resource +* Primarily used for scheduling +resources or meetings with other +people +* Time periods may be marked as +** busy +** free +** busy unavailable ("out of office") +** busy-tentative + +=== Expressing Freebusy time + +* Most commonly as a RFC 2445 +`VFREEBUSY` object +** a request for `freebusy` time, +** a response to a request, or +** a published set of busy time + +=== Sharing Freebusy + +* CalDAV Scheduling +* iTIP/iMIP (email) +* iCalendar .ics file +* Freebusy URL (`FBURL`) + +=== Why `FBURL`? + +* Freebusy is LCD scheduling +* `FBURL` is LCD Freebusy (or could be) +* Easy +* Outlook supports a form of `FBURL` +* The market says `FBURL` is desirable +and useful +** tungle.com, timebridge.com, +timetomeet.info, doodle.ch +* Potentially bridge the divide between +enterprise calendaring and +** calendar/scheduling augmenters +** standalone calendaring clients (no +server) + +=== What we have done + +* Standardize/Normalize +* Parameters -URI template +* Error reporting within the HTTP +protocol +* Allow for non-authenticated or weakly +authenticated service +* Keep it simple (in its simplest form) +*Outlook compatibility +* Extend? +** Discovery +** Authentication +** Provisioning +** `VAVAILABILITY` +*** provide a grouping of available +time information over a specific +range of time. + +=== How it works + +* The "Read URL" is used to get +freebusy data for a user ++ +-- +http://www.example.com/freebusy/user1@example.com?start=20070901T000000-0800 + +http://www.example.com/freebusy/user1@example.com +-- +* returns `VFREEBUSY` object +* The "Publish URL" is used by a client to +upload `freebusy` data for a user ++ +-- +http://www.example.com/freebusy/user1@example.com + +http://www.example.com/freebusy?user=user1@example.com&token=xcsfdgetdh +-- + +=== What we will show you + +* Basic form `FBURL` +** lookups - no publishing +** Accessing multiple servers from the +same clients +** Comparison with server-server +lookups + +=== Freebusy URL Demonstration + +==== Several clients retrieving `freebusy` information + +.Freebusy Demo #1 Setup +image::img20.png[] + +==== Freebusy aggregation information + +.Freebusy Demo #2 Setup +image::img21.png[] + +== Conclusion + +=== Wrap-up + +* We have demonstrated how progress +is being made with key scheduling +technologies +* As with a lot of CalConnect work this +is a very interactive process with +specifications and implementations +being worked on together +* This ultimately provides for a better +specification and interoperability + +=== CalDAV Scheduling + +* A new CalDAV scheduling draft with +implicit scheduling support was +recently published and now we are +heavily testing that +* Hope to complete this by end-2008 + +=== iSchedule + +* Demonstrated basic scheduling message +processing +* Key elements of iSchedule still need to be +developed: +** Discovery (use `SRV` records in DNS) +** Security - need input from security +experts as to what model(s) to use +* Hope to complete this by mid 2009 + +=== Freebusy URL + +* Freebusy is LCD scheduling +* Freebusy is soft-core calendaring +* It is what we settle for, not what we +want +* But...Free/Busy is very, very useful +* CalConnect will continue to develop +`FBURL` diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img01.png b/sources/cc-0806-pres-preview-roundtable-13/images/img01.png new file mode 100644 index 0000000..9b8dfb8 Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img01.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img02.png b/sources/cc-0806-pres-preview-roundtable-13/images/img02.png new file mode 100644 index 0000000..b5fb5e9 Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img02.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img03.png b/sources/cc-0806-pres-preview-roundtable-13/images/img03.png new file mode 100644 index 0000000..1b3836a Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img03.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img04.png b/sources/cc-0806-pres-preview-roundtable-13/images/img04.png new file mode 100644 index 0000000..41428e9 Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img04.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img05.png b/sources/cc-0806-pres-preview-roundtable-13/images/img05.png new file mode 100644 index 0000000..34b3e13 Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img05.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img06.png b/sources/cc-0806-pres-preview-roundtable-13/images/img06.png new file mode 100644 index 0000000..115af9b Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img06.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img07.png b/sources/cc-0806-pres-preview-roundtable-13/images/img07.png new file mode 100644 index 0000000..2b69f6a Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img07.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img08.png b/sources/cc-0806-pres-preview-roundtable-13/images/img08.png new file mode 100644 index 0000000..b83c74d Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img08.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img09.png b/sources/cc-0806-pres-preview-roundtable-13/images/img09.png new file mode 100644 index 0000000..970a3a5 Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img09.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img10.png b/sources/cc-0806-pres-preview-roundtable-13/images/img10.png new file mode 100644 index 0000000..43c0213 Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img10.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img11.png b/sources/cc-0806-pres-preview-roundtable-13/images/img11.png new file mode 100644 index 0000000..10c6989 Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img11.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img12.png b/sources/cc-0806-pres-preview-roundtable-13/images/img12.png new file mode 100644 index 0000000..d0e5a39 Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img12.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img13.png b/sources/cc-0806-pres-preview-roundtable-13/images/img13.png new file mode 100644 index 0000000..1cacc73 Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img13.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img14.png b/sources/cc-0806-pres-preview-roundtable-13/images/img14.png new file mode 100644 index 0000000..ba6db9c Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img14.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img15.png b/sources/cc-0806-pres-preview-roundtable-13/images/img15.png new file mode 100644 index 0000000..f23673a Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img15.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img16.png b/sources/cc-0806-pres-preview-roundtable-13/images/img16.png new file mode 100644 index 0000000..9f9e45f Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img16.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img17.png b/sources/cc-0806-pres-preview-roundtable-13/images/img17.png new file mode 100644 index 0000000..23dad60 Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img17.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img18.png b/sources/cc-0806-pres-preview-roundtable-13/images/img18.png new file mode 100644 index 0000000..84c324e Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img18.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img19.png b/sources/cc-0806-pres-preview-roundtable-13/images/img19.png new file mode 100644 index 0000000..505802d Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img19.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img20.png b/sources/cc-0806-pres-preview-roundtable-13/images/img20.png new file mode 100644 index 0000000..eee021d Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img20.png differ diff --git a/sources/cc-0806-pres-preview-roundtable-13/images/img21.png b/sources/cc-0806-pres-preview-roundtable-13/images/img21.png new file mode 100644 index 0000000..fe804a1 Binary files /dev/null and b/sources/cc-0806-pres-preview-roundtable-13/images/img21.png differ diff --git a/sources/cc-0807-report-ioptest/document.adoc b/sources/cc-0807-report-ioptest/document.adoc new file mode 100644 index 0000000..c1cab54 --- /dev/null +++ b/sources/cc-0807-report-ioptest/document.adoc @@ -0,0 +1,431 @@ += October 2008 CalConnect Interoperability Test Report +:docnumber: 0807 +:copyright-year: 2008 +:language: en +:doctype: administrative +:edition: 1.1 +:status: published +:revdate: 2008-12-08 +:published-date: 2008-12-08 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Patricia Egen +:role: author +:fullname_2: Nate Barry +:role_2: author +:fullname_3: Cyrus Daboo +:role_3: author +:fullname_4: Mike Douglass +:role_4: author +:fullname_5: Firdosh Ghyara +:role_5: author +:fullname_6: Libor Grafnetr +:role_6: author +:fullname_7: Tomas Hnetila +:role_7: author +:fullname_8: Kellie Hunter +:role_8: author +:fullname_9: May Ma +:role_9: author +:fullname_10: Ross Peter Nelson +:role_10: author +:fullname_11: Morgen Sagen +:role_11: author + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Introduction + +The thirteenth CalConnect interoperability event was held at the Yahoo campus at Sunnyvale, +California. Participants of the testing event used predetermined test scenarios. Rather than post +the full test scenarios in this document, they can be found on the CalConnect website at the +following URL: http://www.calconnect.org/ioptesting.shtml. + +The documents used in this testing event were the CalConnect CalDAV Matrix for Draft 08, in +particular the scheduling section and an iCalendar, iMIP and iTIP testing matrix. + +=== Participants + +.Participants +[options=header,cols="a,a,a"] +|=== +| Organization | Participants | Versions Tested +| Apple | Cyrus Daboo + +Wilfredo Sanchez + +Haley Allen + +Scott Adler | iCal Server and client - OS X 10.5.3 + +iCal client 3.03 +| Google | Harish Venkataramani + +Ross Nelson | +| IBM | Nate Barry + +Bruce Kahn| Lotus Domino and Notes 8.05 +| Kerio Technologies | Tomas Hnetila | +| Microsoft | Firdosh Ghyara | Exchange 8.5 and Outlook 2007 +| PeopleCube | Kellie Hunter + +Gordon Connelly | Meetingmaker V8.8 +| RPI (Bedework) | Mike Douglass | Bedework server 3.5 +| Scalix | Florian von Kurnatowski + +Gren Elliot + +Chris Olsen | 11.4.3 pre-release +| Sun Microsystems | Arnaud Quillaud + +May Ma + +Karen Wu + +Chengchen Zhou + +Lakshmi Pavithra Pidatala | +| Yahoo/Zimbra | John Holder | Zimbra Server pre 5.0.7 +| EM Client -- Observer | | Comind CalDAV Client +| CalConnect Reps | | +| Interop Manager Logistics | Pat Egen + +Dave Thewlis | +|=== + +== General comments and findings + +Eight CalDAV servers were tested against 4 CalDAV clients. iSchedule, a new specification was +tested as well by several servers. Examples of what was tested by CalDAV servers and clients +are: + +* CalDAV access +* CalDAV scheduling +* CalDAV free/busy +* CalDAV Availability +* CalDAV Delegation. + +In addition, two vendors tested their application's support for iCalendar, iTIP and iMIP. There +were several clients who were testing iCalendar, iMIP and iTIP against regular clients as well as +against several CalDAV servers so the CalDAV servers could test how they handled iMIP +requests. + +The following are general comments about what occurred and specific findings. Vendor names +are not referenced. What is discussed are actual issues found so that developers of applications +can recognize potential issues within their own products. + +== CalDAV Testing + +During CalDAV testing, the following things were noted: + +When creating a new single-instance meeting with an alarm set to trigger 15 minutes prior to the +schedule time of the meeting, a server removed the alarm after several update operations. + +When modifying the location of the meeting a server did not preserve seconds on the override of +the meeting. + +After modifying the title of the first instance of the recurring meeting a server did not support the +overwrite. + +On the "Query all components and return ETag WebDAV property and all data" test, a CalDAV +client did a query only for the etag, not the calendar data + +When creating a calendar-query `REPORT`, one server's Reports are overridden in separate +resources with the same url. + +After creating a new calendar in the current user's personal calendar space, one CalDAV server +appends "1" to the name of the created folder. + +A CalDAV server verified an issue that makes it impossible to use alerts in one of the clients. +Fixing the problem will require the server vendor to preserve non-standard properties specific to +this client, so they do not have a complete resolution at the moment. A few other minor issues +were also uncovered. + +This same server discovered that they were missing a CalDAV operation (options request, not +currently invoked by any other client). They implemented a fix during the interop and verified that +the basic scheduling features worked after adding support for the options request. They helped +one of the clients testing iCalendar uncover an issue with regards to incrementing sequence +numbers when canceling events. + +One CalDAV server noted that they found CalDAV implementations seems more mature than +before. Items they noted were GUI and Usability issues in Availability settings in one of the +clients. They noted incorrect server responses that caused problems with another client. + +A CalDAV server noted the following issues within their own application: + +* a problem with `xmlns:D="DAV:"` +* another problem with `DAV:` in iSchedule response +* Originator and Recipient address are swapped when a meeting reply was sent from a +server over iSchedule +* finally it works. + +Issues found with other clients and servers: + +* iMIP: iPhone doesn't recognize meeting invitation from a CalDAV server +* A CalDAV client modified structure of MIME format on site +* iMIP: when meeting is accepted in a server's email, reply is sent to From: header address +instead of Organizer's address. + +One CalDAV server noted that all Tomcat versions don't work with large data amounts with +CalDAV. They also noted that a client stored user credentials in the browser cache and even if +the server deleted a calendar account and added it back it didn't ask them to re-authenticate. +Also, upon deletion, we had to clear the browser cache to clear user credentials. This happened +on Internet Explorer and Firefox. + +A CalDAV server noted the following: + +Problems found: + +. If you use the wrong authentication for a valid Calendar, we give a 501 error. A more +friendly response would be desirable. +. If you add a daily recurrence with one of the clients with four instances and delete the +third instance, you lose sight of the fourth instance too. +. If you have a recurrence with an exception where the start of the recurrence specifies +seconds, we generate a bad recurrence-id for the exception. +. We were not preserving the value of `RSVP` in Meeting ``REQUEST``s. i.e. we always +assumed the value was `TRUE`. +. Notes originated meetings were not visible to our CalDAV clients. +. One server's iMip Gateway originated messages are not recognized as meeting requests +by us. We spotted an original issue that the Content-Type `METHOD` parameter was not +being specified but we still had an issue with the final form of Mime structure that they +intend to use. +. Notes originated requests end up with blank `DESCRIPTION` in the iCalendar object and +invalid `ATTACH` properties. + +Another server observed the following during testing of iSchedule. + +* From one server to another server, they got the invitation ok, and reply sent properly and +the client was updated with the status +* From one server to another an invitation doesn't show up on the client +* From one server to another the invitation was received ok, and reply sent properly, and +they could see status updated in the client +* On another server to server, the invitation was received ok, and reply sent properly but +the status was not updated on the client +* From one server to another server, the invitation was ok, but reply can't be sent properly +* From one server to another, the invitation was ok, but reply can't be sent properly + +One server noted: + +There were a number of fixes needed to new code - mostly in CalDAV scheduling - had a number +of interactions with a server with problems at both ends. + +One server tested with a client and found it worked well enough with the new CalDAV scheduling +draft. + +== iCalendar Testing + +Two vendors tested their applications against each other and other servers that would accept +iCalendar objects. These were some of the findings. What is shown is the specific test and +observations for each test. + +Send a meeting invitation + +* There is a problem with reading MIME messages sent from one of the servers. + +Accept a meeting invitation + +* Issue where Accepts are showing as Tentative (likely related to above mismatch +bugs) +* One vendor will investigate incorrect assumptions on name match +* Acceptances do not reliably get delivered +* The entire body shows in accept comments + +Cancel a Meeting Invitation + +* Not bumping the sequence on cancel +* One vendor will consider not requiring `SEQUENCE` to be bumped +* Updating the subject only - possibly related to sequence bump (retest) +* Viewing the cancel causing duplicates + +Send an invite with Rich Text + +* Not honoring `ALTREP` or sending any rich text. +* Displaying rich text in invite, not in calendar. +* Putting HTML directly in description rather than in an `ALTREP`. + +Send an invite with attachments + +* Putting inline attachments that can't be handled +* Attachments show in mail only and not in calendar + +Update a meeting invitation + +* Bumping the sequence number and forcing another vendor to accept. + +Reschedule the original meeting invitation + +* Not clearing invitee status on reschedule + +Decline a meeting invitation + +* Not sending `RSVP` thus causing lost responses + +Create a meeting with required and optional Participants + +* Not correlating the message. +* Showing CC users as To users, but without data loss + +Create a repeating monthly by date + +* Bug for monthly on first thurs until 1/2/09 - last instance missing +* Not handling multiple by date entries + +Create a repeating monthly by day + +* Not working when multiple days are selected +* Not implementing second day +* Not handling multiple by day entries + +Create a repeating monthly event from end + +* Error with end of month iCalendar. +* Writing bad iCalendar + +Create a repeating yearly + +* Not honoring `DTSTART` that doesn't match `RRULE`. `DTEND` is also wrong (early). + +Create a repeating `RDATE` meeting + +* Not supporting or understanding `RRULE` +* Not supporting ``RDATE``s + +Repeats with no end date + +* Sending a response for all even though it truncates the set to some finite value + +Repeat every other... + +* Failing for every other year + +Test until (daily) + +* Not including time on the date +* Not showing last instance +* Time on the until is not before the instance - still puts it on the calendar. + +Create a repeating daily invite + +* Duplicate entries upon acceptance (not reproducible) + +Update the invite (all instances) + +* Not supporting ``RDATE``s +* Deleting the existing meeting (and invite) and recreating a new invite since it does not +handle `RRULE` updates + +Reschedule the invite (all instances) + +* Showing as accepted despite not receiving an updated acceptance + +Cancel the invite (all instances) + +* Not bumping sequence - also ``RDATE``s +* Not bumping sequence number on cancel + +Update one instance, then series + +* Not supporting series update (``RDATE``s?) +* Fail when working on messages with multiple ``VEVENT``s +* Not interpreted - Does One vendor need to put the `RDATE`? + +Cancel a single instance + +* Pass but last char of subject is truncated +* Not interpreted - Does One vendor need to put the `RDATE`? +* Doesn't bump sequence +* Does not bump sequence number on cancel +* Only updating subject line - possibly related to a bug +* Only updating subject line - possibly related to a bug + +Reschedule a single instance + +* Does not bump sequence number + +Update a single instance + +* Not interpreted - Does One vendor need to put the `RDATE`? + +Accept the updated single instance + +* Not handling exception instances + +Counter a single date + +* Could not correlate the message, + +Cancel this and all future instances + +* Not supporting ``RDATE``s +* Bug preventing ``RDATE``s from working + +Reschedule meeting and all future instances + +* Not sending cancel when it splits, which causes duplicates + +Remove an attendee from a simple meeting + +* Does not bump sequence +* Chair does not work + +Add an attendee to a series + +* Does not handle ``RDATE``s + +Create a meeting with Reminders - one for 5mins, one for 10 mins + +* Alarms are not preserved for anyone + +Items not supported by several applications: + +* Counter all dates +* Counter for this and all future instances +* Accept the counter for this and all future instances +* Counter a meeting invitation +* Counter a single date +* Counter all dates +* Accept a meeting invitation counter +* Accept the countered single date + +A summary of significant interoperability issues is as follows: + +. Needs to handle ``VCALENDAR``s with multiple ``VEVENT``s - this results in very ugly +behavior and result in severe data loss. +. Needs to increment `SEQUENCE` on cancellations to comply with the standard to unblock +cancellation tests. +. Revisit handling of `RRULE` updates - current method does not lose data but is a very +brute force method. Is there a better way? +. ``RDATE``s are not supported: This causes severe data loss on some (rare) invites and also +on multiple instance updates, which are very common. +. Rich body content is not supported in either direction. ++ +-- +NOTE: Counterproposals now work! +This was very exciting! +-- +. Must fix the reliability of responses as these seem to intermittently not be sent (bug). +. Fix bug with `RDATE` format. This should be working but is not. Fixing this will unblock a +large number of tests. +. Attachments and rich body content come in but do not make it to a calendar. +. Counterproposals are not currently supported. +. Not handling nested multipart/mixed MIME sections. +. The MIME structure needs to be revisited to allow iCalendar data to be represented as +workflow rather than as an attachment. This does not block tests but is ugly and +annoying. +. ``RDATE``s are not supported: This causes severe data loss on some (rare) invites and also +on multiple instance updates, which are very common. +. Counterproposals are not currently supported. +. Meeting modifications to a single instance is not yet supported. +. Intermittent problem where meetings get duplicated + +== Summary + +This meeting was our largest interoperability event to date. Eight CalDAV servers and 4 CalDAV +clients were tested as well as iCalendar, iMIP and iTIP + +The most significant takeaway from this event was CalDAV clients were able to test with the +majority of the servers. In the past, because things were often not finished or applications had +issues, it was not possible to complete testing. The fact that one client was able to successfully +test against 8 servers during a two day process shows tremendous progress. I look forward to +the next set of testing to see how much improvement has been made, particularly with respect to +CalDAV scheduling. + +With regards to iCalendar testing general interoperability worked far better than it has in the past +and it is clear that strong interoperability efforts have been and are being made by many of the +vendors present. + +Respectfully submitted by Pat Egen, CalConnect Interop Manager. diff --git a/sources/cc-0808-report-ioptest/document.adoc b/sources/cc-0808-report-ioptest/document.adoc new file mode 100644 index 0000000..8b9340f --- /dev/null +++ b/sources/cc-0808-report-ioptest/document.adoc @@ -0,0 +1,1015 @@ += November 2008 CalConnect Mobile Interoperability Test +:docnumber: 0808 +:copyright-year: 2009 +:language: en +:doctype: administrative +:edition: 2 +:status: published +:revdate: 2009-02-19 +:published-date: 2009-02-19 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Patricia Egen +:role: author +:fullname_2: Eremias Alexej +:role_2: author +:fullname_3: James Clarke +:role_3: author +:fullname_4: Chris Dudding +:role_4: author +:fullname_5: Beat Forster +:role_5: author +:fullname_6: Tomas Hnetila +:role_6: author +:fullname_7: Jakub Klos +:role_7: author +:fullname_8: Gregory Pekofsky +:role_8: author +:fullname_9: Milan Vojnovic +:role_9: author +:fullname_10: Lukas Zeller +:role_10: author + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Introduction + +The second CalConnect Mobile Calendaring interoperability event was held at the Kerio campus +at Plzen, Czech Republic. This was also our first interoperability event held in Europe. +Participants of the testing event used predetermined test scenarios. Rather than post the full +scenarios in this document, they can be found on the CalConnect website at the following URL: +http://www.calconnect.org/ioptesting.shtml. + +The testing scenarios used in this event were a subset of items found in the CalConnect Mobile +Calendaring Test Suite. Summaries and specific findings and issues found are noted in this +document. The items used in the subset are included in this document in <>. + +=== Participants + +.Participants +[options=header,cols="a,a,a"] +|=== +| Organization | Participants | Versions Tested +| Icewarp | Eremias Alexej + +Jakub Klos + +Milan Vojnovic | Icewarp Server v9.4 +| Kerio | Tomas Hnetila | +| Oracle | Gregory Pekofsky | Oracle Beehive Server R1.4 +| Symbian | James Clarke + +Chris Dudding | Symbian OS v9.5 +| Synthesis | Beat Forster + +Lukas Zeller | Synthesis SyncML Server 3.2.0.10 + +Synthesis SyncML Client for iPhone 3.2.x + +Synthesis SyncML Client Test Suite 3.2.x +| CalConnect Reps | | +| Interop Manager | Pat Egen | +| Logistics | Dave Thewlis | +|=== + +== Testing Results + +The following reflects general items noted during the testing. The subset used during testing was +comprised of 111 scenarios of which 52 were classified as easy, 42 as medium and 17 as hard. +During testing, 781 test responses were noted. The breakdown of the tests was as follows: + +Easy tests:: 210 passed, 33 failed, 1 was noted as "half pass" and 120 were skipped. +Medium tests:: 138 passed, 29 failed, 3 "half passed" and 118 were skipped. +Hard tests:: 31 passed, 17 failed, 1 "half passed" and 70 were skipped. + +Therefore, 49% of the tests passed, 11% failed, 39% were skipped and .06% half-passed. +Considering the fact that only 27% of the tests performed were deemed "easy", a 49% pass ratio +is good, but not as good as the numbers could be. + +Lack of support on client or server applications was the primary reason tests failed. There were a +few bugs noted. Occasional failures were because of differences in the level of support for +vCalendar formats. + +== Testing Tables + +The following tables show results found during testing. The names of the testing pairs have been +removed to provide a generic idea of findings. + +[cols=3,options=header] +.Test Pair 1 +|=== +| Test ID | Status | Comments + +| 1.1 Create an Event with a Reminder | Pass | +| 1.2 Access Level and Priority | Pass | Passed, showing privacy status when syncing from server, then after removal of private and synced back, correct behaviour was seen on server. Could not test priority. Issue in vendor calendar test app with all day events - we believe this is the test app and not the calendar database engine. +| 1.3 Special Characters From Server | Fail | Generally successful but failed on handling "&" -- was converted to the html entity "&" and then not handled correctly. +| 1.4 Multi-Byte Characters From Server | Fail | Chinese characters not shown correctly on web client and device +| 1.5 Deletion | Pass | +| 1.6 Create an Event with a Reminder | Pass | +| 1.7 Access Level and Priority (can only be done if device supports setting an access level or priority) | Pass | +| 1.8 Special Characters from Device | Pass | Special characters shown correctly. We were not able to test the euro symbol "€" on the Vendor calendar test app. +| 1.9 Multi-Byte Characters from Device | | Couldn't test this. +| 1.10 Deletion | Pass | +| 2.1 Create all-day event in same time zone | Fail | Not handling the event as an all day event but instead treats it as an event from 12am to 12am the next day. Passed on recent Vendor-based products. +| 2.2 Create all-day event to device in different time zone | Fail | Not handling the event as an all day event but instead treats it as an event from 12am to 12am the next day. +| 2.3 Create a Single Instance All Day Event with Reminder | Fail | Not handling the event as an all day event but instead treats it as an event from 12am to 12am the next day. +| 2.4 Create an anniversary all-day event | Fail | Not handling the event as an all day event but instead treats it as an event from 12am to 12am the next day. Saw an error on the Vendor test app. Not clear whether the event repeats. +| 2.5 All-day event on last day of month & last day of year check | | Not run. +| 2.6 Create a Single Instance Holiday with Reminder | | Not run. +| 2.7 Update an all-day event on server and synchronize back to mobile device in same time zone | | Not run. +| 2.8 Update an all-day event on server and synchronize back to a device in different time zone | | Not run. +| 2.9 Create a Single Instance Multi-day Day Event | Fail | Same problem as above with the end of the event being treated as 12am on the following day. +| 2.10 Remove Single Instance Meeting, Day Event, and Holiday | | Not run. +| 2.11 Create an all-day event and synchronize to a server in same time zone | Fail | +| 2.12 Create an all-day event and synchronize to a server in different time zone | Fail | Showed on the server as start and end time as 5am and not as an all day event (relating to the 5 hour timezone offset). +| 2.13 Create a Single Instance All Day Event with Reminder | Fail | Did have the alarm but didn't display properly in the server. +| 2.14 Create an anniversary all-day event | Fail | Displayed as having no duration (start and end time the same, 12am on the same day) +| 2.15 Update an all-day event on mobile device and synchronize back to server in same time zone | | Not run. +| 2.16 Update an all-day event on mobile device and synchronize back to a server in different time zone | | Not run. +| 2.17 Create a Single Instance Multi-Day Day Event | | Not run. +| 2.18 Remove Single Instance Meeting, Day Event, and Holiday | | Not run. +| 3.1 Create Daily Repeat (every day, bounded) | Pass | +| 3.2 Create Daily Repeat (every other day, unbounded) | Pass | +| 3.3 Create Daily Repeat (every 7 days, unbounded) | Pass | +| 3.4 Create Weekly Repeat (every Wed, unbounded) | Pass | +| 3.5 Create Weekly repeat (Wed & Fri, unbounded) | Pass | +| 3.6 Create Fortnightly Repeat (unbounded) | Pass | +| 3.7 Create Monthly By Date Repeat (unbounded) | Pass | +| 3.8 Create Monthly By Day Repeat (first occurrence, bounded) | Pass | +| 3.9 Create Monthly By Day Repeat (nth occurrences, bounded) | Pass | Unable to create monthly by day repeat on 2nd and 3rd Sunday on server web client - so test case is not the same +| 3.10 Create Monthly By Day Repeat (last occurrence, bounded) | | Unable to create last occurrence on server web client +| 3.11 Create Yearly Repeat (every year, unbounded) | Pass | +| 3.12 Create Yearly Repeat (every year for 5 years, bounded) | Pass | +| 3.13 Create Yearly Repeat (every 4 years, bounded) | Pass | +| 3.14 Create custom repeat (``RDATE``s only) | | Not run. Unable to create on server web client +| 3.15 Create repeat combination | | Not run. Unable to create on server web client +| 3.16 Create repeating event plus custom repeat (`RRULE` + `RDATE`) | | Not run. Unable to create on server web client +| 3.17 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) | | Not run. Unable to create on server web client +| 3.18 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) | | Not run. Unable to create on server web client +| 3.19 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) | | Not run. Unable to create on server web client +| 3.20 Modify anniversary | Pass | +| 3.21 Modify occurrences of repeating meeting | Fail | Issue with server web client update and handling of multiple exception dates +| 3.22 Modify exceptions of repeating meeting | Pass | Test case description is wrong. Instead of modify exception it should be modify event +| 3.23 Delete recurring meeting | Pass | +| 3.24 Create Daily Repeat (every day, bounded) | Pass | +| 3.25 Create Daily Repeat (every other day, unbounded) | Pass | +| 3.26 Create Daily Repeat (every 7 days, unbounded) | Pass | +| 3.27 Create Weekly Repeat (every Wed, unbounded) | Pass | +| 3.28 Create Weekly repeat (Wed & Fri, unbounded) | | Not run. Unable to test due to defect in Vendor test user interface +| 3.29 Create Fortnightly Repeat (unbounded) | Pass | +| 3.30 Create Monthly By Date Repeat (unbounded) | Fail | Problem with interpretation of client repeat forever vCalendar (uses #0 to indicate repeat forever). Web mail bug?? +| 3.31 Create Monthly By Day Repeat (first occurrence, bounded) | | Not run. Unable to test due to defect in Vendor test user interface +| 3.32 Create Monthly By Day Repeat (nth occurrences, bounded) | | Not run. Unable to test due to defect in Vendor test user interface +| 3.33 Create Monthly By Day Repeat (last occurrence, bounded) | | Not run. Unable to test due to defect in Vendor test user interface +| 3.34 Create Yearly Repeat (every year, unbounded) | Fail | Problem with interpretation of client repeat forever vCalendar (uses #0 to indicate repeat forever). Web mail bug?? +| 3.35 Create Yearly Repeat (every year for 5 years, bounded) | Pass | +| 3.36 Create Yearly Repeat (every 4 years, bounded) | Pass | +| 3.37 Create custom repeat (``RDATE``s only) | Fail | `RDATE` not supported by server +| 3.38 Create repeat combination | | Not run. Unable to test due to defect in Vendor test user interface +| 3.39 Create repeating event plus custom repeat (`RRULE` + `RDATE`) | | Not run. Server does not support `RDATE` +| 3.40 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) | Pass | +| 3.41 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) | | Not run. Server does not support `RDATE` +| 3.42 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) | | Not run. Server does not support `RDATE` +| 3.43 Modify anniversary | Pass | +| 3.44 Modify occurrences of repeating meeting | Pass | +| 3.45 Delete recurring meeting | Pass | +| 4.1 Create Entry as owner with Attendees from Server | | Not run. Unable to test due to defect in Vendor test user interface +| 4.2 Accept Entry as Invitee from Device | | Not run. Unable to test due to lack of support +| 4.3 Create Entry as owner with Attendees from Device | | Not run. Unable to test due to lack of support +| 5.1 Time Zones and Simple Meetings | Pass | Test case description has a defect as procedure doesn't match expected results +| 5.2 Time Zones and Repeating Meetings | | Not run +| 5.3 Time Zones and All-Day Events | | Not run +| 5.4 Spring Daylight Savings Single Entries from Server | | Not run +| 5.5 Spring Daylight Savings Repeating Entry from Server | | Not run. +| 5.6 Autumn Daylight Savings Single Entries from Device | | Not run. +| 5.7 Autumn Daylight Savings Recurring Entry from Device | | Not run. +| 6.1 Create task | Pass | Passed. Test case failed with attachment added +| 6.2 Task Access Level and Priority | | Not run. +| 6.3 Create task with alarm | | Not run. +| 6.4 Mark task as completed | | Not run. +| 6.5 Special Characters From Server | | Not run. +| 6.6 Multi-Byte Characters From Server | | Not run. +| 6.7 Deletion | | Not run. +| 6.8 Create task | | Not run. +| 6.9 Task Access Level and Priority | | Not run. +| 6.10 Create task with alarm | | Not run. +| 6.11 Mark task as completed | | Not run. +| 6.12 Special Characters From Device | | Not run. +| 6.13 Multi-Byte Characters From Device | | Not run +| 6.14 Deletion | | Not run. +| 7.1 Create new contact with minimal fields from the server | Pass | Passed in general but some data was lost. +| 7.2 Create new contact with minimal fields from the device | Pass | Passed in general but some data was lost. +| 7.3 Special Characters | | Not run. +| 7.4 Multi-Byte Characters | | Not run. +| 7.5 Delete a contact from the server | | Not run. +| 7.6 Delete a contact from the device | | Not run. +| 8.1 Create new contact with addresses from the server | | Not run. +| 8.2 Create new contact with addresses from the device | | Not run. +| 9.1 Create new contact with telephone numbers from the server | | Not run. +| 9.2 Create new contact with telephone numbers from the device | | Not run. +| 10.1 Create new contact with emails from the server | | Not run. +| 10.2 Create new contact with URLs/web page addresses from the server. | | Not run. +| 10.3 Create new contact with emails from the device | | Not run. +| 10.4 Create new contact with URLs/web page addresses from the device | | Not run. +|=== + +[cols="a,a,a",options=header] +.Test Pair 2 +|=== +| Test ID | Status | Comments + +| 1.1 Create an Event with a Reminder | Pass | +| 1.2 Access Level and Priority | | Not run. Calendar app does not support access level or priority. +| 1.3 Special Characters From Server | Pass | +| 1.4 Multi-Byte Characters From Server | Pass | However, app cannot display the multibyte characters correctly but the characters are preserved and given back to the server correctly after modifying the calendar entry. +| 1.5 Deletion | Pass | +| 1.6 Create an Event with a Reminder | Fail | The alarm/reminder did not work. +| 1.7 Access Level and Priority (can only be done if device supports setting an access level or priority) | | Not run. Calendar app does not support access level or priority. +| 1.8 Special Characters from Device | Pass | +| 1.9 Multi-Byte Characters from Device | | Not run. Not able to enter multi-byte characters on the phone. +| 1.10 Deletion | Pass | +| 2.1 Create all-day event in same time zone | Pass | +| 2.2 Create all-day event to device in different time zone | Pass | +| 2.3 Create a Single Instance All Day Event with Reminder | Pass | +| 2.4 Create an anniversary all-day event | Pass | +| 2.5 All-day event on last day of month & last day of year check | Fail | Cannot see the repeat rule on the device. +| 2.6 Create a Single Instance Holiday with Reminder | Pass | +| 2.7 Update an all-day event on server and synchronize back to mobile device in same time zone | Pass | +| 2.8 Update an all-day event on server and synchronize back to a device in different time zone | Pass | +| 2.9 Create a Single Instance Multi-day Day Event | Pass | +| 2.10 Remove Single Instance Meeting, Day Event, and Holiday | Fail | Server does not support exceptions +| 2.11 Create an all-day event and synchronize to a server in same time zone | Pass | +| 2.12 Create an all-day event and synchronize to a server in different time zone | Pass | +| 2.13 Create a Single Instance All Day Event with Reminder | Fail | Could not see the reminder on the server. +| 2.14 Create an anniversary all-day event | Pass | +| 2.15 Update an all-day event on mobile device and synchronize back to server in same time zone | Pass | +| 2.16 Update an all-day event on mobile device and synchronize back to a server in different time zone | Pass | +| 2.17 Create a Single Instance Multi-Day Day Event | Pass | +| 2.18 Remove Single Instance Meeting, Day Event, and Holiday | Fail | Server does not support exceptions +| 3.1 Create Daily Repeat (every day, bounded) | Pass | +| 3.2 Create Daily Repeat (every other day, unbounded) | Pass | +| 3.3 Create Daily Repeat (every 7 days, unbounded) | Pass | +| 3.4 Create Weekly Repeat (every Wed, unbounded) | Pass | +| 3.5 Create Weekly repeat (Wed & Fri, unbounded) | Pass | +| 3.6 Create Fortnightly Repeat (unbounded) | | +| 3.7 Create Monthly By Date Repeat (unbounded) | | +| 3.8 Create Monthly By Day Repeat (first occurrence, bounded) | | +| 3.9 Create Monthly By Day Repeat (nth occurrences, bounded) | | +| 3.10 Create Monthly By Day Repeat (last occurrence, bounded) | | +| 3.11 Create Yearly Repeat (every year, unbounded) | | +| 3.12 Create Yearly Repeat (every year for 5 years, bounded) | | +| 3.13 Create Yearly Repeat (every 4 years, bounded) | | +| 3.14 Create custom repeat (``RDATE``s only) | | +| 3.15 Create repeat combination | | +| 3.16 Create repeating event plus custom repeat (`RRULE` + `RDATE`) | | +| 3.17 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) | | +| 3.18 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) | | +| 3.19 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) | | +| 3.20 Modify anniversary | | +| 3.21 Modify occurrences of repeating meeting | | +| 3.22 Modify exceptions of repeating meeting | | +| 3.23 Delete recurring meeting | | +| 3.24 Create Daily Repeat (every day, bounded) | Pass | +| 3.25 Create Daily Repeat (every other day, unbounded) | Pass | +| 3.26 Create Daily Repeat (every 7 days, unbounded) | Pass | +| 3.27 Create Weekly Repeat (every Wed, unbounded) | Pass | +|=== + +NOTE: No other testing was done after 3.27. + +[cols=3,options=header] +.Test Pair 3 +|=== +| Test ID | Status | Comments +| 1.1 Create an Event with a Reminder | Pass | 1.1 to 1.4 can be combined +| 1.2 Access Level and Priority | Pass | device supported access level but it missing transp property from devinf +| 1.3 Special Characters From Server | Pass | perhaps skip this test and go right to multibytes +| 1.4 Multi-Byte Characters From Server | | client interface could display multibytes +| 1.5 Deletion | Pass | +| 1.6 Create an Event with a Reminder | Pass | +| 1.7 Access Level and Priority (can only be done if device supports setting an access level or priority) | Pass | +| 1.8 Special Characters from Device | Pass | +| 1.9 Multi-Byte Characters from Device | | client interface could not write multibytes +| 1.10 Deletion | Pass | +| 2.1 Create all-day event in same time zone | Pass | vendor day events have nothing to do with timezones +| 2.2 Create all-day event to device in different time zone | | +| 2.3 Create a Single Instance All Day Event with Reminder | | reminder is currently turned off for day events from server to device +| 2.4 Create an anniversary all-day event | | server sends back single instance for recurrence, so not worth testing +| 2.5 All-day event on last day of month & last day of year check | | +| 2.6 Create a Single Instance Holiday with Reminder | Pass | +| 2.7 Update an all-day event on server and synchronize back to mobile device in same time zone | Pass | +| 2.8 Update an all-day event on server and synchronize back to a device in different time zone | | again timezone on day events are independent on server +| 2.9 Create a Single Instance Multi-day Day Event | Pass | +| 2.10 Remove Single Instance Meeting, Day Event, and Holiday | Pass | but client or server doesn't support a holiday flag so we assume this is a multi-day event +| 2.11 Create an all-day event and synchronize to a server in same time zone | Pass | +| 2.12 Create an all-day event and synchronize to a server in different time zone | Pass | +| 2.13 Create a Single Instance All Day Event with Reminder | Pass | client sent alarm but server purposely does not save it on all day events +| 2.14 Create an anniversary all-day event | Pass | +| 2.15 Update an all-day event on mobile device and synchronize back to server in same time zone | Pass | +| 2.16 Update an all-day event on mobile device and synchronize back to a server in different time zone | Pass | +| 2.17 Create a Single Instance Multi-Day Day Event | Pass | +| 2.18 Remove Single Instance Meeting, Day Event, and Holiday | Pass | +| 3.1 Create Daily Repeat (every day, bounded) | | skip to 3.24 because server will not send recurrences to device +| 3.2 Create Daily Repeat (every other day, unbounded) | | +| 3.3 Create Daily Repeat (every 7 days, unbounded) | | +| 3.4 Create Weekly Repeat (every Wed, unbounded) | | +| 3.5 Create Weekly repeat (Wed & Fri, unbounded) | | +| 3.6 Create Fortnightly Repeat (unbounded) | | +| 3.7 Create Monthly By Date Repeat (unbounded) | | +| 3.8 Create Monthly By Day Repeat (first occurrence, bounded) | | +| 3.9 Create Monthly By Day Repeat (nth occurrences, bounded) | | +| 3.10 Create Monthly By Day Repeat (last occurrence, bounded) | | +| 3.11 Create Yearly Repeat (every year, unbounded) | | +| 3.12 Create Yearly Repeat (every year for 5 years, bounded) | | +| 3.13 Create Yearly Repeat (every 4 years, bounded) | | +| 3.14 Create custom repeat (``RDATE``s only) | | +| 3.15 Create repeat combination | | +| 3.16 Create repeating event plus custom repeat (`RRULE` + `RDATE`) | | +| 3.17 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) | | +| 3.18 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) | | +| 3.19 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) | | +| 3.20 Modify anniversary | | +| 3.21 Modify occurrences of repeating meeting | | +| 3.22 Modify exceptions of repeating meeting | | +| 3.23 Delete recurring meeting | | +| 3.24 Create Daily Repeat (every day, bounded) | Pass | client note: for better recurrence support put until value as UTC as `TZ` and `DATETIME` are optional properties in vCal 1 +| 3.25 Create Daily Repeat (every other day, unbounded) | Pass | NOTE: we combined 3.24 to 3.36 into one big test +| 3.26 Create Daily Repeat (every 7 days, unbounded) | Pass | +| 3.27 Create Weekly Repeat (every Wed, unbounded) | Pass | +| 3.28 Create Weekly repeat (Wed & Fri, unbounded) | | client does not support creating this type of recurrence +| 3.29 Create Fortnightly Repeat (unbounded) | Pass | +| 3.30 Create Monthly By Date Repeat (unbounded) | Pass | +| 3.31 Create Monthly By Day Repeat (first occurrence, bounded) | Fail | client test app has a bug +| 3.32 Create Monthly By Day Repeat (nth occurrences, bounded) | Fail | client test app has a bug +| 3.33 Create Monthly By Day Repeat (last occurrence, bounded) | Fail | client test app has a bug +| 3.34 Create Yearly Repeat (every year, unbounded) | Pass | +| 3.35 Create Yearly Repeat (every year for 5 years, bounded) | Pass | +| 3.36 Create Yearly Repeat (every 4 years, bounded) | Pass | +| 3.37 Create custom repeat (``RDATE``s only) | Pass | +| 3.38 Create repeat combination | | client ui cannot do this +| 3.39 Create repeating event plus custom repeat (`RRULE` + `RDATE`) | Pass | +| 3.40 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) | | CalConnect comment: skip this test and just do 3.42 +| 3.41 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) | | CalConnect comment: if there is no `RRULE`, `EXDATE` cancels `RDATE`s, which is bad implementation, so really this test should be removed from the suite +| 3.42 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) | Pass | +| 3.43 Modify anniversary | | server replaces recurrences on the device with single instances +| 3.44 Modify occurrences of repeating meeting | Pass | +| 3.45 Delete recurring meeting | Pass | +| 4.1 Create Entry as owner with Attendees from Server | Pass | +| 4.2 Accept Entry as Invitee from Device | | +| 4.3 Create Entry as owner with Attendees from Device | | there is no direct way to do this with vCal 1 +| 5.1 Time Zones and Simple Meetings | Pass | +| 5.2 Time Zones and Repeating Meetings | Pass | +| 5.3 Time Zones and All-Day Events | Pass | +| 5.4 Spring Daylight Savings Single Entries from Server | Pass | +| 5.5 Spring Daylight Savings Repeating Entry from Server | Pass | +| 5.6 Autumn Daylight Savings Single Entries from Device | Pass | +| 5.7 Autumn Daylight Savings Recurring Entry from Device | Pass | +| 6.1 Create task | Pass | we combined 6.1,6.2.6.3,6.5,6.6 into one sync +| 6.2 Task Access Level and Priority | Pass | +| 6.3 Create task with alarm | Pass | +| 6.4 Mark task as completed | Pass | +| 6.5 Special Characters From Server | Pass | +| 6.6 Multi-Byte Characters From Server | | cannot view multi-bytes on client test interface +| 6.7 Deletion | Pass | +| 6.8 Create task | Pass | +| 6.9 Task Access Level and Priority | Pass | +| 6.10 Create task with alarm | Pass | +| 6.11 Mark task as completed | Pass | +| 6.12 Special Characters From Device | | client test ui cannot write special characters +| 6.13 Multi-Byte Characters From Device | | client test ui cannot write multi-bytes characters +| 6.14 Deletion | Pass | +| 7.1 Create new contact with minimal fields from the server | Pass | CalConnect note: get rid of empty vCard sync and combine the rest of the tests into one sync +| 7.2 Create new contact with minimal fields from the device | Pass | +| 7.3 Special Characters | Pass | +| 7.4 Multi-Byte Characters | | device test ui cannot read or write this +| 7.5 Delete a contact from the server | Pass | +| 7.6 Delete a contact from the device | Pass | +| 8.1 Create new contact with addresses from the server | Pass | +| 8.2 Create new contact with addresses from the device | Pass | +| 9.1 Create new contact with telephone numbers from the server | Pass | +| 9.2 Create new contact with telephone numbers from the device | Pass | +| 10.1 Create new contact with emails from the server | Pass | +| 10.2 Create new contact with URLs/web page addresses from the server. | Pass | +| 10.3 Create new contact with emails from the device | Pass | +| 10.4 Create new contact with URLs/web page addresses from the device | Pass | +|=== + +[cols="a,a,a",options=header] +.Test Pair 4 +|=== +| Test ID | Status | Comments +| 1.1 Create an Event with a Reminder | Pass | Server sends extra \ escape when name starts with double quote +| 1.2 Access Level and Priority | Pass | +| 1.3 Special Characters From Server | Pass | +| 1.4 Multi-Byte Characters From Server | | n/a, web UI is ISO8859-1 +| 1.5 Deletion | Pass | +| 1.6 Create an Event with a Reminder | Pass | +| 1.7 Access Level and Priority (can only be done if device supports setting an access level or priority) | Pass | +| 1.8 Special Characters from Device | Pass | +| 1.9 Multi-Byte Characters from Device | | n/a, both sides don't have UI for eastern fonts +| 1.10 Deletion | Pass | +| 2.1 Create all-day event in same time zone | | Passed except that device did not set the all-day flag (but period covered in calendar is correct) +| 2.2 Create all-day event to device in different time zone | | Passed except that device did not set the all-day flag (but period covered in calendar is correct) +| 2.3 Create a Single Instance All Day Event with Reminder | Fail | reminder did show at wrong time in client +| 2.4 Create an anniversary all-day event | Pass | Tested with regular yearly recurrence (proprietary vCalendar extension property used by client to flag anniversaries) +| 2.5 All-day event on last day of month & last day of year check | Pass | +| 2.6 Create a Single Instance Holiday with Reminder | | n/a, both sides don't have special "holiday" entry type +| 2.7 Update an all-day event on server and synchronize back to mobile device in same time zone | Pass | +| 2.8 Update an all-day event on server and synchronize back to a device in different time zone | Pass | +| 2.9 Create a Single Instance Multi-day Day Event | Pass | but definition of what an `ALL-DAY` event actually `IS` is different in the device (binds day to current device zone) and server (considers all-day floating, i.e. not moving when `TZ` changes) +| 2.10 Remove Single Instance Meeting, Day Event, and Holiday | Pass | +| 2.11 Create an all-day event and synchronize to a server in same time zone | Pass | but device fixes start and end in time (see comment for 2.9) +| 2.12 Create an all-day event and synchronize to a server in different time zone | Fail | see comment in 2.9 (comes out fixed in UTC-5 time, which is not all-day in GMT server time) +| 2.13 Create a Single Instance All Day Event with Reminder | Pass | +| 2.14 Create an anniversary all-day event | Pass | Anniversaries are in fact floating time, which is IMHO what all-day events should be as well +| 2.15 Update an all-day event on mobile device and synchronize back to server in same time zone | Pass | +| 2.16 Update an all-day event on mobile device and synchronize back to a server in different time zone | Pass | But generally: synchronizing modified anniversary back to device will make loose the anniversary status on the device (because it would need proprietary vCalendar extension property to remain anniversary) +| 2.17 Create a Single Instance Multi-Day Day Event | | not run, because largely the same as 2.9 +| 2.18 Remove Single Instance Meeting, Day Event, and Holiday | Pass | +| 3.1 Create Daily Repeat (every day, bounded) | Pass | +| 3.2 Create Daily Repeat (every other day, unbounded) | Pass | +| 3.3 Create Daily Repeat (every 7 days, unbounded) | Pass | +| 3.4 Create Weekly Repeat (every Wed, unbounded) | Pass | +| 3.5 Create Weekly repeat (Wed & Fri, unbounded) | Pass | +| 3.6 Create Fortnightly Repeat (unbounded) | Pass | +| 3.7 Create Monthly By Date Repeat (unbounded) | Pass | +| 3.8 Create Monthly By Day Repeat (first occurrence, bounded) | Pass | +| 3.9 Create Monthly By Day Repeat (nth occurrences, bounded) | Pass | +| 3.10 Create Monthly By Day Repeat (last occurrence, bounded) | Pass | +| 3.11 Create Yearly Repeat (every year, unbounded) | Pass | +| 3.12 Create Yearly Repeat (every year for 5 years, bounded) | Pass | +| 3.13 Create Yearly Repeat (every 4 years, bounded) | Pass | +| 3.14 Create custom repeat (``RDATE``s only) | | n/a +| 3.15 Create repeat combination | | n/a +| 3.16 Create repeating event plus custom repeat (`RRULE` + `RDATE`) | | n/a +| 3.17 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) | Pass | +| 3.18 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) | | n/a +| 3.19 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) | | n/a +| 3.20 Modify anniversary | Pass | implicitly done above +| 3.21 Modify occurrences of repeating meeting | Pass | +| 3.22 Modify exceptions of repeating meeting | Pass | implicitly done above +| 3.23 Delete recurring meeting | Pass | +| 3.24 Create Daily Repeat (every day, bounded) | Pass | +| 3.25 Create Daily Repeat (every other day, unbounded) | Pass | +| 3.26 Create Daily Repeat (every 7 days, unbounded) | Pass | +| 3.27 Create Weekly Repeat (every Wed, unbounded) | Pass | +| 3.28 Create Weekly repeat (Wed & Fri, unbounded) | | n/a because of UI problem in client +| 3.29 Create Fortnightly Repeat (unbounded) | Pass | +| 3.30 Create Monthly By Date Repeat (unbounded) | Pass | +| 3.31 Create Monthly By Day Repeat (first occurrence, bounded) | Pass | +| 3.32 Create Monthly By Day Repeat (nth occurrences, bounded) | | n/a because of UI problem in client +| 3.33 Create Monthly By Day Repeat (last occurrence, bounded) | Pass | +| 3.34 Create Yearly Repeat (every year, unbounded) | Pass | +| 3.35 Create Yearly Repeat (every year for 5 years, bounded) | Pass | +| 3.36 Create Yearly Repeat (every 4 years, bounded) | Pass | +| 3.37 Create custom repeat (``RDATE``s only) | | n/a +| 3.38 Create repeat combination | | n/a +| 3.39 Create repeating event plus custom repeat (`RRULE` + `RDATE`) | | n/a +| 3.40 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) | Pass | +| 3.41 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) | | n/a +| 3.42 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) | | n/a +| 3.43 Modify anniversary | Pass | +| 3.44 Modify occurrences of repeating meeting | Pass | But we think test case is not very useful because this does not really test exceptions (it simply changes the recurrence end date) - we should have a case actually testing modifying exception details like time, summary, location. +| 3.45 Delete recurring meeting | Pass | +| 4.1 Create Entry as owner with Attendees from Server | | Test Session `TIMEOUT` +| 4.2 Accept Entry as Invitee from Device | | Test Session `TIMEOUT` +| 4.3 Create Entry as owner with Attendees from Device | Pass | Implicitly tested above +| 5.1 Time Zones and Simple Meetings | | n/a +| 5.2 Time Zones and Repeating Meetings | | n/a +| 5.3 Time Zones and All-Day Events | | n/a +| 5.4 Spring Daylight Savings Single Entries from Server | | Test Session `TIMEOUT` +| 5.5 Spring Daylight Savings Repeating Entry from Server | | Test Session `TIMEOUT` +| 5.6 Autumn Daylight Savings Single Entries from Device | | Test Session `TIMEOUT` +| 5.7 Autumn Daylight Savings Recurring Entry | | Test Session `TIMEOUT` from Device +| 6.1 Create task | Pass | +| 6.2 Task Access Level and Priority | Pass | +| 6.3 Create task with alarm | | `TIMEOUT` from here on +|=== + +NOTE: Tests after 6.3 were not performed. + +[cols="a,a,a",options=header] +.Test Pair 5 +|=== +| Test ID | Status | Comments +| 1.1 Create an Event with a Reminder | Pass | +| 1.2 Access Level and Priority | Pass | +| 1.3 Special Characters From Server | Pass | +| 1.4 Multi-Byte Characters From Server | Pass | +| 1.5 Deletion | Pass | +| 1.6 Create an Event with a Reminder | Pass | +| 1.7 Access Level and Priority (can only be done if device supports setting an access level or priority) | Pass | +| 1.8 Special Characters from Device | Pass | +| 1.9 Multi-Byte Characters from Device | Pass | +| 1.10 Deletion | Pass | +| 2.1 Create all-day event in same time zone | Pass | +| 2.2 Create all-day event to device in different time zone | | no point in testing because both day event implementation do not involve timezones +| 2.3 Create a Single Instance All Day Event with Reminder | | server does not support alarms on day events +| 2.4 Create an anniversary all-day event | | anniversary flag not supported +| 2.5 All-day event on last day of month & last day of year check | Pass | +| 2.6 Create a Single Instance Holiday with Reminder | | holiday flag is not supported +| 2.7 Update an all-day event on server and synchronize back to mobile device in same time zone | Pass | +| 2.8 Update an all-day event on server and synchronize back to a device in different time zone | | device and server do not associate timezone with day events +| 2.9 Create a Single Instance Multi-day Day Event | Pass | +| 2.10 Remove Single Instance Meeting, Day Event, and Holiday | | device and server do not support holiday flag +| 2.11 Create an all-day event and synchronize to a server in same time zone | Pass | +| 2.12 Create an all-day event and synchronize to a server in different time zone | | device and server do not support holiday flag +| 2.13 Create a Single Instance All Day Event with Reminder | | server does not support alarms on day events +| 2.14 Create an anniversary all-day event | | device and server do not support anniversary flag +| 2.15 Update an all-day event on mobile device and synchronize back to server in same time zone | Pass | +| 2.16 Update an all-day event on mobile device and synchronize back to a server in different time zone | | device and server do not associate timezone with day events +| 2.17 Create a Single Instance Multi-Day Day Event | | +| 2.18 Remove Single Instance Meeting, Day Event, and Holiday | Pass | +| 3.1 Create Daily Repeat (every day, bounded) | | server replaces recurrence on the device with single instance so we will skip to 3.24 +| 3.2 Create Daily Repeat (every other day, unbounded) | | see 3.1 +| 3.3 Create Daily Repeat (every 7 days, unbounded) | | see 3.1 +| 3.4 Create Weekly Repeat (every Wed, unbounded) | | see 3.1 +| 3.5 Create Weekly repeat (Wed & Fri, unbounded) | | see 3.1 +| 3.6 Create Fortnightly Repeat (unbounded) | | see 3.1 +| 3.7 Create Monthly By Date Repeat (unbounded) | | see 3.1 +| 3.8 Create Monthly By Day Repeat (first occurrence, bounded) | | see 3.1 +| 3.9 Create Monthly By Day Repeat (nth occurrences, bounded) | | see 3.1 +| 3.10 Create Monthly By Day Repeat (last occurrence, bounded) | | see 3.1 +| 3.11 Create Yearly Repeat (every year, unbounded) | | see 3.1 +| 3.12 Create Yearly Repeat (every year for 5 years, bounded) | | see 3.1 +| 3.13 Create Yearly Repeat (every 4 years, bounded) | | see 3.1 +| 3.14 Create custom repeat (``RDATE``s only) | | see 3.1 +| 3.15 Create repeat combination | | see 3.1 +| 3.16 Create repeating event plus custom repeat (`RRULE` + `RDATE`) | | see 3.1 +| 3.17 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) | | see 3.1 +| 3.18 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) | | see 3.1 +| 3.19 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) | | see 3.1 +| 3.20 Modify anniversary | | see 3.1 +| 3.21 Modify occurrences of repeating meeting | | see 3.1 +| 3.22 Modify exceptions of repeating meeting | | see 3.1 +| 3.23 Delete recurring meeting | | see 3.1 +| 3.24 Create Daily Repeat (every day, bounded) | Pass | +| 3.25 Create Daily Repeat (every other day, unbounded) | Pass | +| 3.26 Create Daily Repeat (every 7 days, unbounded) | Pass | +| 3.27 Create Weekly Repeat (every Wed, unbounded) | Pass | +| 3.28 Create Weekly repeat (Wed & Fri, unbounded) | Pass | +| 3.29 Create Fortnightly Repeat (unbounded) | Pass | +| 3.30 Create Monthly By Date Repeat (unbounded) | Pass | +| 3.31 Create Monthly By Day Repeat (first occurrence, bounded) | Pass | +| 3.32 Create Monthly By Day Repeat (nth occurrences, bounded) | | not possible on client +| 3.33 Create Monthly By Day Repeat (last occurrence, bounded) | Pass | +| 3.34 Create Yearly Repeat (every year, unbounded) | Pass | +| 3.35 Create Yearly Repeat (every year for 5 years, bounded) | Pass | +| 3.36 Create Yearly Repeat (every 4 years, bounded) | Pass | +| 3.37 Create custom repeat (``RDATE``s only) | | client cannot send ``RDATE``s +| 3.38 Create repeat combination | | +| 3.39 Create repeating event plus custom repeat (`RRULE` + `RDATE`) | | client cannot send ``RDATE``s +| 3.40 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) | Pass | +| 3.41 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) | | client cannot send ``RDATE``s +| 3.42 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) | | client cannot do ``RDATE``s +| 3.43 Modify anniversary | | anniversary flag not supported +| 3.44 Modify occurrences of repeating meeting | Pass | +| 3.45 Delete recurring meeting | Pass | +| 4.1 Create Entry as owner with Attendees from Server | Pass | +| 4.2 Accept Entry as Invitee from Device | | there is no native way to do this +| 4.3 Create Entry as owner with Attendees from Device | Pass | +| 5.1 Time Zones and Simple Meetings | | currently only can sending floating +| 5.2 Time Zones and Repeating Meetings | | currently only can sending floating +| 5.3 Time Zones and All-Day Events | | currently only can sending floating +| 5.4 Spring Daylight Savings Single Entries from Server | | currently only can sending floating +| 5.5 Spring Daylight Savings Repeating Entry from Server | | currently only can sending floating +| 5.6 Autumn Daylight Savings Single Entries from Device | | currently only can sending floating +| 5.7 Autumn Daylight Savings Recurring Entry from Device | | currently only can sending floating +| 6.1 Create task | Pass | +| 6.2 Task Access Level and Priority | Pass | +| 6.3 Create task with alarm | Pass | +| 6.4 Mark task as completed | Pass | +| 6.5 Special Characters From Server | Pass | +| 6.6 Multi-Byte Characters From Server | Pass | +| 6.7 Deletion | Pass | +| 6.8 Create task | Pass | +| 6.9 Task Access Level and Priority | Pass | +| 6.10 Create task with alarm | Pass | +| 6.11 Mark task as completed | Pass | +| 6.12 Special Characters From Device | Pass | +| 6.13 Multi-Byte Characters From Device | Pass | +| 6.14 Deletion | Pass | +| 7.1 Create new contact with minimal fields from the server | Pass | +| 7.2 Create new contact with minimal fields from the device | Pass | +| 7.3 Special Characters | Pass | +| 7.4 Multi-Byte Characters | Pass | +| 7.5 Delete a contact from the server | Pass | +| 7.6 Delete a contact from the device | Pass | +| 8.1 Create new contact with addresses from the server | Pass | +| 8.2 Create new contact with addresses from the device | Pass | +| 9.1 Create new contact with telephone numbers from the server | Pass | +| 9.2 Create new contact with telephone numbers from the device | Pass | +| 10.1 Create new contact with emails from the server | Pass | +| 10.2 Create new contact with URLs/web page addresses from the server. | Pass | +| 10.3 Create new contact with emails from the device | Pass | +| 10.4 Create new contact with URLs/web page addresses from the device | Pass | +|=== + +[cols="a,a,a",options=header] +.Test Pair 6 +|=== +| Test ID | Status | Comments +| 1.1 Create an Event with a Reminder | Fail | waiting for vAlarm to be added to devinf +| 1.2 Access Level and Priority | Pass | access level not support by client +| 1.3 Special Characters From Server | Pass | +| 1.4 Multi-Byte Characters From Server | Pass | +| 1.5 Deletion | Pass | +| 1.6 Create an Event with a Reminder | Pass | +| 1.7 Access Level and Priority (can only be done if device supports setting an access level or priority) | Pass | same as issue 1.1 with vAlarm +| 1.8 Special Characters from Device | Pass | +| 1.9 Multi-Byte Characters from Device | Pass | +| 1.10 Deletion | Pass | +| 2.1 Create all-day event in same time zone | Pass | client and server do not associate timezone with day events +| 2.2 Create all-day event to device in different time zone | Pass | +| 2.3 Create a Single Instance All Day Event with Reminder | Pass | same issue as 1.1, missing timezone +| 2.4 Create an anniversary all-day event | Pass | +| 2.5 All-day event on last day of month & last day of year check | Pass | device and server do not have direct property for this, so we just assumed that it was a yearly recurrence +| 2.6 Create a Single Instance Holiday with Reminder | Pass | similarly, server and client do not directly support holiday, but we assumed this is a yearly recurrence with multiple days +| 2.7 Update an all-day event on server and synchronize back to mobile device in same time zone | Pass | +| 2.8 Update an all-day event on server and synchronize back to a device in different time zone | Fail | modify single day event to yearly from device failed on server +| 2.9 Create a Single Instance Multi-day Day Event | Pass | +| 2.10 Remove Single Instance Meeting, Day Event, and Holiday | | +| 2.11 Create an all-day event and synchronize to a server in same time zone | Pass | +| 2.12 Create an all-day event and synchronize to a server in different time zone | Pass | +| 2.13 Create a Single Instance All Day Event with Reminder | Pass | +| 2.14 Create an anniversary all-day event | Pass | +| 2.15 Update an all-day event on mobile device and synchronize back to server in same time zone | Pass | +| 2.16 Update an all-day event on mobile device and synchronize back to a server in different time zone | Pass | +| 2.17 Create a Single Instance Multi-Day Day Event | Pass | +| 2.18 Remove Single Instance Meeting, Day Event, and Holiday | Pass | +| 3.1 Create Daily Repeat (every day, bounded) | | server replace recurrences with single meetings so these do not apply for 3.1 to 3.22 +| 3.2 Create Daily Repeat (every other day, unbounded) | | +| 3.3 Create Daily Repeat (every 7 days, unbounded) | | +| 3.4 Create Weekly Repeat (every Wed, unbounded) | | +| 3.5 Create Weekly repeat (Wed & Fri, unbounded) | | +| 3.6 Create Fortnightly Repeat (unbounded) | | +| 3.7 Create Monthly By Date Repeat (unbounded) | | +| 3.8 Create Monthly By Day Repeat (first occurrence, bounded) | | +| 3.9 Create Monthly By Day Repeat (nth occurrences, bounded) | | +| 3.10 Create Monthly By Day Repeat (last occurrence, bounded) | | +| 3.11 Create Yearly Repeat (every year, unbounded) | | +| 3.12 Create Yearly Repeat (every year for 5 years, bounded) | | +| 3.13 Create Yearly Repeat (every 4 years, bounded) | | +| 3.14 Create custom repeat (``RDATE``s only) | | +| 3.15 Create repeat combination | | +| 3.16 Create repeating event plus custom repeat (`RRULE` + `RDATE`) | | +| 3.17 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) | | +| 3.18 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) | | +| 3.19 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) | | +| 3.20 Modify anniversary | | +| 3.21 Modify occurrences of repeating meeting | | +| 3.22 Modify exceptions of repeating meeting | | +| 3.23 Delete recurring meeting pass | | +| 3.24 Create Daily Repeat (every day, bounded) | pass | +| 3.25 Create Daily Repeat (every other day, unbounded) | pass | +| 3.26 Create Daily Repeat (every 7 days, unbounded) | pass | +| 3.27 Create Weekly Repeat (every Wed, unbounded) | pass | +| 3.28 Create Weekly repeat (Wed & Fri, unbounded) | pass | +| 3.29 Create Fortnightly Repeat (unbounded) | pass | +| 3.30 Create Monthly By Date Repeat (unbounded) | pass | +| 3.31 Create Monthly By Day Repeat (first occurrence, bounded) | pass | some tests can be run at the same time such as the next 3 +| 3.32 Create Monthly By Day Repeat (nth occurrences, bounded) | pass | +| 3.33 Create Monthly By Day Repeat (last occurrence, bounded) | pass | +| 3.34 Create Yearly Repeat (every year, unbounded) | pass | +| 3.35 Create Yearly Repeat (every year for 5 years, bounded) | pass | +| 3.36 Create Yearly Repeat (every 4 years, bounded) | pass | +| 3.37 Create custom repeat (``RDATE``s only) | | device does not support ``RDATE``s or combination +| 3.38 Create repeat combination | | +| 3.39 Create repeating event plus custom repeat (`RRULE` + `RDATE`) | | +| 3.40 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) | pass | +| 3.41 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) | | +| 3.42 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) | | +| 3.43 Modify anniversary | pass | +| 3.44 Modify occurrences of repeating meeting | pass | +| 3.45 Delete recurring meeting | pass | +| 4.1 Create Entry as owner with Attendees from Server | pass | attendee parsing error on client ... try again later +| 4.2 Accept Entry as Invitee from Device | Pass | only via markup in subject +| 4.3 Create Entry as owner with Attendees from Device | pass | +| 5.1 Time Zones and Simple Meetings | pass | +| 5.2 Time Zones and Repeating Meetings | pass | +| 5.3 Time Zones and All-Day Events | pass | +| 5.4 Spring Daylight Savings Single Entries from Server | pass | +| 5.5 Spring Daylight Savings Repeating Entry from Server | pass | +| 5.6 Autumn Daylight Savings Single Entries from Device | pass | +| 5.7 Autumn Daylight Savings Recurring Entry from Device | pass | +| 6.1 Create task | Fail | property status not sending in_process or cancelled, but it is receiving quite well +| 6.2 Task Access Level and Priority | pass | +| 6.3 Create task with alarm | | client+server do not support tasks with alarms +| 6.4 Mark task as completed | pass | +| 6.5 Special Characters From Server | pass | +| 6.6 Multi-Byte Characters From Server | pass | +| 6.7 Deletion | pass | +| 6.8 Create task | pass | +| 6.9 Task Access Level and Priority | pass | +| 6.10 Create task with alarm | pass | +| 6.11 Mark task as completed | pass | +| 6.12 Special Characters From Device | pass | +| 6.13 Multi-Byte Characters From Device | pass | +| 6.14 Deletion | pass | +| 7.1 Create new contact with minimal fields from the server | pass | `BDAY` not working on server +| 7.2 Create new contact with minimal fields from the device | pass | +| 7.3 Special Characters | pass | +| 7.4 Multi-Byte Characters | pass | +| 7.5 Delete a contact from the server | pass | +| 7.6 Delete a contact from the device | pass | +| 8.1 Create new contact with addresses from the server | pass | NOTE: `BDAY` property did not pass but it was not a test +| 8.2 Create new contact with addresses from the device | pass | combined some of these into single test +| 9.1 Create new contact with telephone numbers from the server | pass | +| 9.2 Create new contact with telephone numbers from the device | pass | +| 10.1 Create new contact with emails from the server | pass | +| 10.2 Create new contact with URLs/web page addresses from the server. | pass | +| 10.3 Create new contact with emails from the device | pass | +| 10.4 Create new contact with URLs/web page addresses from the device | pass | +|=== + +[cols="a,a,a",options=header] +.Test Pair 7 +|=== +| Test ID | Status | Comments + +| 1.1 Create an Event with a Reminder | Pass | +| 1.2 Access Level and Priority | Pass | +| 1.3 Special Characters From Server | Pass | tests only possible with `VCALENDAR1.0`, folding problems +| 1.4 Multi-Byte Characters From Server | Pass | tests only possible with `VCALENDAR1.0`, folding problems +| 1.5 Deletion | Fail | Server performs just slow sync +| 1.6 Create an Event with a Reminder | Fail | Mix between 2.0 and 1.1 format causes problems +| 1.7 Access Level and Priority (can only be done if device supports setting an access level or priority) | Pass | +| 1.8 Special Characters from Device | Pass | +| 1.9 Multi-Byte Characters from Device | Pass | +| 1.10 Deletion | Fail | Server performs just slow sync and can't delete +| 2.1 Create all-day event in same time zone | Fail | Mix between 2.0 and 1.1 format causes problems +| 2.2 Create all-day event to device in different time zone | HalfPass | All-day is ok, but still mix +| 2.3 Create a Single Instance All Day Event with Reminder | - | +| 2.4 Create an anniversary all-day event | - | same as 2.1 +| 2.5 All-day event on last day of month & last day of year check | HalfPass | Mix between 2.0 and 1.1 format causes problems +| 2.6 Create a Single Instance Holiday with Reminder | HalfPass | X-Label is Kerio specific +| 2.7 Update an all-day event on server and synchronize back to mobile device in same time zone | Pass | +| 2.8 Update an all-day event on server and synchronize back to a device in different time zone | Pass | +| 2.9 Create a Single Instance Multi-day Day Event | HalfPass | Mix between 2.0 and 1.1 format causes problems +| 2.10 Remove Single Instance Meeting, Day Event, and Holiday | Fail | Server performs just slow sync +| 2.11 Create an all-day event and synchronize to a server in same time zone | Pass | +| 2.12 Create an all-day event and synchronize to a server in different time zone | Pass | +| 2.13 Create a Single Instance All Day Event with Reminder | Fail | Mix between 2.0 and 1.1 format causes problems +| 2.14 Create an anniversary all-day event | Pass | +| 2.15 Update an all-day event on mobile device and synchronize back to server in same time zone | Pass | +| 2.16 Update an all-day event on mobile device and synchronize back to a server in different time zone | Pass | +| 2.17 Create a Single Instance Multi-Day Day Event | Pass | +| 2.18 Remove Single Instance Meeting, Day Event, and Holiday | Fail | Server performs just slow sync and can't delete +| 3.1 Create Daily Repeat (every day, bounded) | Pass | +| 3.2 Create Daily Repeat (every other day, unbounded) | Pass | +| 3.3 Create Daily Repeat (every 7 days, unbounded) | Pass | +| 3.4 Create Weekly Repeat (every Wed, unbounded) | Pass | +| 3.5 Create Weekly repeat (Wed & Fri, unbounded) | Pass | +| 3.6 Create Fortnightly Repeat (unbounded) | Pass | +| 3.7 Create Monthly By Date Repeat (unbounded) | Pass | +| 3.8 Create Monthly By Day Repeat (first occurrence, bounded) | Pass | +| 3.9 Create Monthly By Day Repeat (nth occurrences, bounded) | - | only possible with more than one entry +| 3.10 Create Monthly By Day Repeat (last occurrence, bounded) | Fail | Server will not send MP1 1-, but just MP1 +| 3.11 Create Yearly Repeat (every year, unbounded) | Fail | Server sends YM1 2 14 #0 instead of Y1 #0 +| 3.12 Create Yearly Repeat (every year for 5 years, bounded) | Fail | Server sends YM1 4 1 #5 instead of Y1#5 +| 3.13 Create Yearly Repeat (every 4 years, bounded) | - | only possible with more than one entry +| 3.14 Create custom repeat (``RDATE``s only) | - | only possible with more than one entry +| 3.15 Create repeat combination | Fail | Client and Server do not support this +| 3.16 Create repeating event plus custom repeat (`RRULE` + `RDATE`) | Fail | Server can't support ``EXDATE``s with 1.1 +| 3.17 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) | Fail | Server can't support ``EXDATE``s with 1.1 +| 3.18 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) | Fail | Server can't support ``EXDATE``s with 1.1 +| 3.19 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) | Fail | Server can't support ``EXDATE``s with 1.1 +| 3.20 Modify anniversary | Pass | +| 3.21 Modify occurrences of repeating meeting | Pass | Server sends recurrence end date in UTC +| 3.22 Modify exceptions of repeating meeting | Fail | Server can't support ``EXDATE``s with 1.1 +| 3.23 Delete recurring meeting | Fail | Server performs just slow sync +| 3.24 Create Daily Repeat (every day, bounded) | Pass | +| 3.25 Create Daily Repeat (every other day, unbounded) | Pass | +| 3.26 Create Daily Repeat (every 7 days, unbounded) | Pass | +| 3.27 Create Weekly Repeat (every Wed, unbounded) | Pass | +| 3.28 Create Weekly repeat (Wed & Fri, unbounded) | Pass | +| 3.29 Create Fortnightly Repeat (unbounded) | Pass | +| 3.30 Create Monthly By Date Repeat (unbounded) | Pass | +| 3.31 Create Monthly By Day Repeat (first occurrence, bounded) | Pass | +| 3.32 Create Monthly By Day Repeat (nth occurrences, bounded) | Fail | Client and Server do not support this +| 3.33 Create Monthly By Day Repeat (last occurrence, bounded) | Fail | Server can't recognize -1FR correctly +| 3.34 Create Yearly Repeat (every year, unbounded) | Pass | +| 3.35 Create Yearly Repeat (every year for 5 years, bounded) | Pass | +| 3.36 Create Yearly Repeat (every 4 years, bounded) | Pass | +| 3.37 Create custom repeat (``RDATE``s only) | - | only possible with more than one entry +| 3.38 Create repeat combination | Fail | Client can't handle `BYMONTH` + `BYDAY` combinations +| 3.39 Create repeating event plus custom repeat (`RRULE` + `RDATE`) | Fail | Server can't support ``EXDATE``s with 1.1 +| 3.40 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) | Fail | Server can't support ``EXDATE``s with 1.1 +| 3.41 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) | Fail | Server can't support ``EXDATE``s with 1.1 +| 3.42 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) | Fail | Server can't support ``EXDATE``s with 1.1 +| 3.43 Modify anniversary | HalfPass | Mix between 2.0 and 1.1 format causes problems +| 3.44 Modify occurrences of repeating meeting | Pass | +| 3.45 Delete recurring meeting | Fail | Server performs just slow sync and can't delete +| 4.1 Create Entry as owner with Attendees from Server | Pass | Mix between 2.0 and 1.1 format workaround at client +| 4.2 Accept Entry as Invitee from Device | Fail | Attendees ok, but Server does not accept status this way +| 4.3 Create Entry as owner with Attendees from Device | Fail | Attendees ok, but Server does not accept status this way +| 5.1 Time Zones and Simple Meetings | Fail | `TZ` recognition not appropriate +| 5.2 Time Zones and Repeating Meetings | Fail | `TZ` recognition not appropriate +| 5.3 Time Zones and All-Day Events | Fail | `TZ` recognition not appropriate +| 5.4 Spring Daylight Savings Single Entries from Server | Fail | `TZ` recognition not appropriate +| 5.5 Spring Daylight Savings Repeating Entry from Server | Fail | `TZ` recognition not appropriate +| 5.6 Autumn Daylight Savings Single Entries from Device | Fail | `TZ` recognition not appropriate +| 5.7 Autumn Daylight Savings Recurring Entry from Device | Fail | `TZ` recognition not appropriate +| 6.1 Create task | Fail | Tasks not supported on server side +| 6.2 Task Access Level and Priority | Fail | Tasks not supported on server side +| 6.3 Create task with alarm | Fail | Tasks not supported on server side +| 6.4 Mark task as completed | Fail | Tasks not supported on server side +| 6.5 Special Characters From Server | Fail | Tasks not supported on server side +| 6.6 Multi-Byte Characters From Server | Fail | Tasks not supported on server side +| 6.7 Deletion | Fail | Tasks not supported on server side +| 6.8 Create task | Fail | Tasks not supported on server side +| 6.9 Task Access Level and Priority | Fail | Tasks not supported on server side +| 6.10 Create task with alarm | Fail | Tasks not supported on server side +| 6.11 Mark task as completed | Fail | Tasks not supported on server side +| 6.12 Special Characters From Device | Fail | Tasks not supported on server side +| 6.13 Multi-Byte Characters From Device | Fail | Tasks not supported on server side +| 6.14 Deletion | Fail | Tasks not supported on server side +| 7.1 Create new contact with minimal fields from the server | Pass | +| 7.2 Create new contact with minimal fields from the device | Pass | +| 7.3 Special Characters | Pass | tests only possible with VCARD2.1, folding problems +| 7.4 Multi-Byte Characters | Pass | +| 7.5 Delete a contact from the server | Fail | Server performs just slow sync and can't delete +| 7.6 Delete a contact from the device | Fail | Server performs just slow sync and can't delete +| 8.1 Create new contact with addresses from the server | Pass | tests only possible with `VCARD2.1`, folding problems +| 8.2 Create new contact with addresses from the device | Fail | `ADDTL` (2nd) field will be removed on server +| 9.1 Create new contact with telephone numbers from the server | Pass | +| 9.2 Create new contact with telephone numbers from the device | Pass | +| 10.1 Create new contact with emails from the server | Pass | +| 10.2 Create new contact with URLs/web page addresses from the server. | Pass | +| 10.3 Create new contact with emails from the device | Pass | +| 10.4 Create new contact with URLs/web page addresses from the device | Pass | +|=== + +== Summary + +The first mobile event found the test suite had too many scenarios to test during one event. +Therefore, this time we tested only a subset of the scenarios and this proved to be the right thing +to do. Participants were able to get through all the scenarios and provide commentary. It was +found that there were some things tested that appeared to be redundant. Gregory Pekofsky put +together a document that provides suggestions on how to streamline the limited subset so we can +better utilize our valuable testing time. His suggested are noted in <> at the end of this +document. + +As usual, participants found that sitting in a room together and doing live testing was extremely +useful. The facilities were perfect and connectivity, always an issue when doing mobile testing, +was excellent. + +We extend our thanks and appreciation to Kerio for providing with us with an excellent testing +environment and very helpful and professional staff. We also thank the participants for their time +in helping us further interoperability among mobile devices and calendaring. + +Respectfully submitted by Patricia Egen. + +[[appendix-A]] +[appendix] +== Testing Scenarios -- Subset + +* 1.1 Create an Event with a Reminder +* 1.2 Access Level and Priority +* 1.3 Special Characters From Server +* 1.4 Multi-Byte Characters From Server +* 1.5 Deletion +* 1.6 Create an Event with a Reminder +* 1.7 Access Level and Priority (can only be done if device supports setting an access level or priority) +* 1.8 Special Characters from Device +* 1.9 Multi-Byte Characters from Device +* 1.10 Deletion +* 2.1 Create all-day event in same time zone +* 2.2 Create all-day event to device in different time zone +* 2.3 Create a Single Instance All Day Event with Reminder +* 2.4 Create an anniversary all-day event +* 2.5 All-day event on last day of month & last day of year check +* 2.6 Create a Single Instance Holiday with Reminder +* 2.7 Update an all-day event on server and synchronize back to mobile device in same time zone +* 2.8 Update an all-day event on server and synchronize back to a device in different time zone +* 2.9 Create a Single Instance Multi-day Day Event +* 2.10 Remove Single Instance Meeting, Day Event, and Holiday +* 2.11 Create an all-day event and synchronize to a server in same time zone +* 2.12 Create an all-day event and synchronize to a server in different time zone +* 2.13 Create a Single Instance All Day Event with Reminder +* 2.14 Create an anniversary all-day event +* 2.15 Update an all-day event on mobile device and synchronize back to server in same time zone +* 2.16 Update an all-day event on mobile device and synchronize back to a server in different time zone +* 2.17 Create a Single Instance Multi-Day Day Event +* 2.18 Remove Single Instance Meeting, Day Event, and Holiday +* 3.1 Create Daily Repeat (every day, bounded) +* 3.2 Create Daily Repeat (every other day, unbounded) +* 3.3 Create Daily Repeat (every 7 days, unbounded) +* 3.4 Create Weekly Repeat (every Wed, unbounded) +* 3.5 Create Weekly repeat (Wed & Fri, unbounded) +* 3.6 Create Fortnightly Repeat (unbounded) +* 3.7 Create Monthly By Date Repeat (unbounded) +* 3.8 Create Monthly By Day Repeat (first occurrence, bounded) +* 3.9 Create Monthly By Day Repeat (nth occurrences, bounded) +* 3.10 Create Monthly By Day Repeat (last occurrence, bounded) +* 3.11 Create Yearly Repeat (every year, unbounded) +* 3.12 Create Yearly Repeat (every year for 5 years, bounded) +* 3.13 Create Yearly Repeat (every 4 years, bounded) +* 3.14 Create custom repeat (``RDATE``s only) +* 3.15 Create repeat combination +* 3.16 Create repeating event plus custom repeat (`RRULE` + `RDATE`) +* 3.17 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) +* 3.18 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) +* 3.19 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) +* 3.20 Modify anniversary +* 3.21 Modify occurrences of repeating meeting +* 3.22 Modify exceptions of repeating meeting +* 3.23 Delete recurring meeting +* 3.24 Create Daily Repeat (every day, bounded) +* 3.25 Create Daily Repeat (every other day, unbounded) +* 3.26 Create Daily Repeat (every 7 days, unbounded) +* 3.27 Create Weekly Repeat (every Wed, unbounded) +* 3.28 Create Weekly repeat (Wed & Fri, unbounded) +* 3.29 Create Fortnightly Repeat (unbounded) +* 3.30 Create Monthly By Date Repeat (unbounded) +* 3.31 Create Monthly By Day Repeat (first occurrence, bounded) +* 3.32 Create Monthly By Day Repeat (nth occurrences, bounded) +* 3.33 Create Monthly By Day Repeat (last occurrence, bounded) +* 3.34 Create Yearly Repeat (every year, unbounded) +* 3.35 Create Yearly Repeat (every year for 5 years, bounded) +* 3.36 Create Yearly Repeat (every 4 years, bounded) +* 3.37 Create custom repeat (``RDATE``s only) +* 3.38 Create repeat combination +* 3.39 Create repeating event plus custom repeat (`RRULE` + `RDATE`) +* 3.40 Create a repeating event with exceptions (`RRULE` + `EXDATE`, bounded) +* 3.41 Create a custom repeat with exceptions (`RDATE` + `EXDATE`, bounded) +* 3.42 Create repeating event plus custom repeat and exceptions (`RRULE`, `RDATE` & `EXDATE`) +* 3.43 Modify anniversary +* 3.44 Modify occurrences of repeating meeting +* 3.45 Delete recurring meeting +* 4.1 Create Entry as owner with Attendees from Server +* 4.2 Accept Entry as Invitee from Device +* 4.3 Create Entry as owner with Attendees from Device +* 5.1 Time Zones and Simple Meetings +* 5.2 Time Zones and Repeating Meetings +* 5.3 Time Zones and All-Day Events +* 5.4 Spring Daylight Savings Single Entries from Server +* 5.5 Spring Daylight Savings Repeating Entry from Server +* 5.6 Autumn Daylight Savings Single Entries from Device +* 5.7 Autumn Daylight Savings Recurring Entry from Device +* 6.1 Create task +* 6.2 Task Access Level and Priority +* 6.3 Create task with alarm +* 6.4 Mark task as completed +* 6.5 Special Characters From Server +* 6.6 Multi-Byte Characters From Server +* 6.7 Deletion +* 6.8 Create task +* 6.9 Task Access Level and Priority +* 6.10 Create task with alarm +* 6.11 Mark task as completed +* 6.12 Special Characters From Device +* 6.13 Multi-Byte Characters From Device +* 6.14 Deletion +* 7.1 Create new contact with minimal fields from the server +* 7.2 Create new contact with minimal fields from the device +* 7.3 Special Characters +* 7.4 Multi-Byte Characters +* 7.5 Delete a contact from the server +* 7.6 Delete a contact from the device +* 8.1 Create new contact with addresses from the server +* 8.2 Create new contact with addresses from the device +* 9.1 Create new contact with telephone numbers from the server +* 9.2 Create new contact with telephone numbers from the device +* 10.1 Create new contact with emails from the server +* 10.2 Create new contact with URLs/web page addresses from the server. +* 10.3 Create new contact with emails from the device +* 10.4 Create new contact with URLs/web page addresses from the device + +[[appendix-B]] +[appendix] +== Suggested Test Case modifications + +[cols="a,a"] +.Suggested Test Case modifications +|=== +| 3.1 Create Daily Repeat (every day, bounded) | 3.1 to 3.19 can be combined into one sync titled with the name of the test +| 3.24 Create Daily Repeat (every day, bounded) | 3.24 to 3.42 can be combined into one sync titled with the name of the test +| 1.1 Create an Event with a Reminder | combine 1.1 to 1.4 +| 1.2 Access Level and Priority | combine 1.1 to 1.4 +| 1.3 Special Characters From Server | combine 1.1 to 1.4 +| 1.4 Multi-Byte Characters From Server | combine 1.1 to 1.4 +| 1.6 Create an Event with a Reminder | combine 1.6 to 1.9 +| 1.7 Access Level and Priority (can only be done if device supports setting an access level or priority) | combine 1.6 to 1.9 +| 1.8 Special Characters from Device | combine 1.6 to 1.9 +| 1.9 Multi-Byte Characters from Device | combine 1.6 to 1.9 +| 1.10 Deletion | combine 1.6 to 1.9 +| 2.1 Create all-day event in same time zone | combine 2.1 and 2.3 +| 2.3 Create a Single Instance All Day Event with Reminder | combine 2.1 and 2.3 +| 2.11 Create an all-day event and synchronize to a server in same time zone | combine 2.11 and 2.13 +| 2.13 Create a Single Instance All Day Event with Reminder | combine 2.11 and 2.13 +| 6.1 Create task | combine 6.1 to 6.6 into one sync +| 6.8 Create task | combine 6.8 to 6.13 into one sync +| 2.4 Create an anniversary all-day event | remove this as it is proprietary not apart of vCal +| 2.6 Create a Single Instance Holiday with Reminder | remove this as it is proprietary not apart of vCal +| 2.10 Remove Single Instance Meeting, Day Event, and Holiday | remove this as it is proprietary not apart of vCal +| 2.14 Create an anniversary all-day event | remove this as it is proprietary not apart of vCal +| 2.18 Remove Single Instance Meeting, Day Event, and Holiday | remove this as it is proprietary not apart of vCal +| 3.20 Modify anniversary | remove this as it is proprietary not apart of vCal +| 3.43 Modify anniversary | remove this as it is proprietary not apart of vCal +| 7.1 Create new contact with minimal fields from the server | remove this simple case +| 7.2 Create new contact with minimal fields from the device | remove this simple case +| 7.3 Special Characters | The rest of the test can be combined +|=== diff --git a/sources/cc-0809-report-roundtable-11/document.adoc b/sources/cc-0809-report-roundtable-11/document.adoc new file mode 100644 index 0000000..890c0b5 --- /dev/null +++ b/sources/cc-0809-report-roundtable-11/document.adoc @@ -0,0 +1,162 @@ += Report on Roundtable XI, February 6-8 2008 +:docnumber: 0809 +:copyright-year: 2008 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2008-02-08 +:published-date: 2008-02-08 +:technical-committee: CALCONNECT +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Introduction + +Roundtable XI and the accompanying IOP Test Events took place February 6-8, 2008, hosted by +Sun Microsystems in Menlo Park, California. The event was attended by 53 representatives from +25 organizations, including representatives from five observers (organizations attending a +Roundtable to see if they wish to join). Two media representatives were also present by invitation +to see the Technology Preview on Wednesday afternoon. + +The CalConnect Interoperability Test Events (C.I.T.E.) were held immediately prior to the +Roundtable, running all day Monday and Tuesday, February 4-5. Nine organizations participated +in the regular IOP Test Event, performing interoperability testing between their calendaring and +scheduling implementations. In parallel, CalConnect hosted its first Mobile Interoperability Test +Event, attended by three organizations interested in conducting mobile calendaring tests. A total of +30 people attended the two IOP Test Events, including four observers. Reports on the IOP Test +Events will be published as soon as possible. + +Roundtable XI began Wednesday morning, and ran through early afternoon on Friday. Special +events at Roundtable XI included + +* A Technology Preview demonstrating live interoperability in the areas of CalDAV +Scheduling, Server-Server, and Free/Busy URL. A presentation about this Technology +Preview is available at Roundtable XI Technology Preview. +* Presentations on the Danish eKalendar.dk project from representatives of the Danish +Government and of Cabo Communications, the prime contractor on the project. The +presentations are available at Danish eKalendar Project and eKalendar from a Developer's +Perspective. + +The remainder of the Roundtable was dedicated to technical committee sessions, BOFs, and +informal discussions and networking, with an all-hands Plenary meeting as the last item on Friday +afternoon. The Technical Committee sessions were as usual organized sequentially, without +competing parallel sessions, to allow all attendees who wished to be involved in the discussions of +a Technical Committee the opportunity to do so. + +== Update on Technical Committees and Initiatives + +=== TC CALDAV + +TC CALDAV reported on its work since the last Roundtable and on its planto +incorporate implicit scheduling into the CalDAV Scheduling Specification. Discussions were held +in this area to clarify specific elements of implicit scheduling for the Technical Committee. + +=== TC EVENTPUB + +TC EVENTPUB reviewed the current state of the `VVENUE` proposal and +initiated a discussion on whether the approach was correct, or whether we should be encouraging +the appropriate extensions to vCard now that the IETF has undertaken a Working Group to +revise the vCard RFC. + +=== TC FREEBUSY + +TC FREEBUSY reviewed work since the last Roundtable, especially work on +Free/Busy URL and in preparing for the Technology Previews of CalDAV Scheduling, serverserver, +and Free/Busy URL and discussed synergies with the Danish Government and the +eKalender.dk project. + +=== TC IOPTEST + +TC IOPTEST reported on the IOP test events just completed, including the first +Mobile Interoperability Test Event, discussed early plans to implement an issue-tracking +mechanism, and decided to adopt a work item on a formal test suite and capabilities to support +virtual IOP testing. + +=== TC MOBILE + +TC MOBILE presented its work since the publication of the Mobile Calendar +Interoperability Test Suite, and discussed the first Mobile Calendar Interoperability Test Event just +completed. Future directions in work for extending the test suite for vCard testing, and a focus on +mobile requirements for CalDAV, were adopted into the work plan. TC MOBILE is also exploring +having the next Mobile Interoperability Test Event in Europe, possibly in the autumn of 2008. + +=== TC REALTIME + +TC REALTIME presented and discussed its work on the `REALTIME` +messaging protocol, Discovery, and Authentication and Authorization, and in particular needs for +additional expertise in security within CalConnect to inform this work. + +=== TC TIMEZONE + +TC TIMEZONE presented the conceptual work to date for the registry and +service proposals and led discussion on various elements of the proposals. + +=== TC USECASE + +The TC presented its in-progress work on Resources generating a lengthy +discussion on the subject and some recommendations from other participants. + +=== CalConnect Interoperability Test Event + +Participants in the IOP test events +included Apple, Kerio, Marware, Microsoft, Oracle, RPI (Bedework), Scalix, Sony Ericsson, Sun +Microsystems and Zimbra. Results from the event will be posted at Past IOP Reports as soon as +they are collated and prepared. + +=== BOFS + +BOF topics included CalDAV Implicit Scheduling, moving forward with a TC-XML, how +to go forward with vCARD, and how to better support and attract European members. + +=== New Initiatives + +* CalConnect will initiate TC-XML in the area of XML representation of iCalendar data. +* CalConnect will support vCard via existing work within extant TCs plus a coordinating +function in TC CHAIRS, but will not initiate a new TC for vCard at this time. The public +vcard-workshop-l mailing list will be retained as a way of continuing to involve external +participants in ongoing focus in this area. +* CalConnect is exploring offering an invitational "meet CalConnect" event in Europe later +this year as a way to introduce potential members to the Consortium. +* CalConnect has initated a Guest Speaker program to invite selected individuals to speak to +CalConnect who are unlikely to attend Roundtables due to locale or work interests. + +== Future Meetings + +* ROUNDTABLE XII: June 2-6, 2008, at the University of Wisconsin, Madison, Wisconsin. +* ROUNDTABLE XIII: October 6-10, 2008, at Zimbra, Sunnyvalle, California. +* ROUNDTABLE XIV: February 2-6, 2009, host and location to be determined. + +The format of the CalConnect week is: + +* Monday morning through Wednesday noon, C.I.T.E. (CalConnect Interoperability Test Events) +* Wednesday noon through Friday afternoon, Roundtable (presentations, TC sessions, BOFs, +networking, Plenary). diff --git a/sources/cc-0810-report-roundtable-12/document.adoc b/sources/cc-0810-report-roundtable-12/document.adoc new file mode 100644 index 0000000..79aa343 --- /dev/null +++ b/sources/cc-0810-report-roundtable-12/document.adoc @@ -0,0 +1,139 @@ += Report on Roundtable XII, June 4-6 2008 +:docnumber: 0810 +:copyright-year: 2008 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2008-06-06 +:published-date: 2008-06-06 +:technical-committee: CALCONNECT +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Introduction + +Roundtable XII took place June 4-6, 2008, hosted by the University of Wisconsin in Madison, +Wisconsin. The event was attended by 31 people from 22 organizations, including representatives +from two observers (organizations attending a Roundtable to see if they wish to join). + +The Roundtable was dedicated to technical committee sessions, BOFs, and informal discussions +and networking, with an all-hands Plenary meeting as the last item on Friday afternoon. The +Technical Committee sessions were as usual organized sequentially, without competing parallel +sessions, as is our standard practice to allow all attendees who wished to be involved in the +discussions of each Technical Committee the opportunity to do so. + +== Update on Technical Committees and Initiatives + +=== TC CALDAV + +TC CALDAV reported on its work since the last Roundtable and on implicit +scheduling. In particular the discussion focused on calendar roles in preparation for the +development of a draft protocol on role-based access control in CalDAV. + +=== TC EVENTPUB + +TC EVENTPUB discussed venue information on vCard and the need to let the +new vCard specification develop. vCard V4 as planned will include new property types for +individual, organization, and group, and provide scope for resources. The TC will focus going +forward on requirements and use cases around the public event space, and additionally on how +that may relate to CalDAV. + +=== TC FREEBUSY + +TC FREEBUSY reviewed its work on Freebusy URL. Key issues related to +whether `FBURL` would be used to publish information, as well as meeting events and interactions +with CalDAV. Going forward the TC will focus on developing a formal `FBURL` specification. + +=== TC IOPTEST + +TC IOPTEST reported on the IOP test event just completed, and presented the +proposed Virtual Test Lab as part of the TC MOBILE session. + +=== TC MOBILE + +TC MOBILE presented its work on extending the Mobile Calendar +Interoperability Test Suite in the area of recurrences and formal definitions of mobile device +capability levels. Plans for a Virtual Test Lab were presented by TC IOPTEST, and the second +Mobile Interoperability Test Event was decided upon. + +=== TC TIMEZONE + +TC TIMEZONE presented the work to date on its draft proposal and RFC and +will work towards having the proposal ready to present at the October Roundtable. + +=== TC USECASE + +TC USECASE has been reviewing the topic of resources and finds little +commonality between existing implementations. The TC will focus on a recommendation +document for specific resource management issues. + +=== TC XML + +TC XML, founded at the last Roundtable, reported on its work to date in developing a +transform of iCalendar data to/from XML, particularly with respect to the size of an XML +representation and the relative friendliness of the XML created. + +=== CalConnect Interoperability Test Event + +Participants in the IOP test included +Apple, Mozilla, RPI (Bedework), Scalix, and Yahoo!/Zimbra. Results from the event will be +posted at Past IOP Reports as soon as they are collated and prepared. + +=== BOFS + +The major BOF was on preparing for an enhanced Technology Preview at the October +event, and to what degree CalConnect should be trying to conduct a public event with press +representatives. As before, we will invite a small number of selected individuals from the media +with an interest in calendaring to the Technical Preview in October. + +=== New Initiatives + +* CalConnect is developing a pilot of a Virtual Test Lab, to allow remote interoperability +testing of regular or mobile calendaring between registered test pairs, as an adjunct to its +regular in-person IOP test events. +* The second Mobile Interoperability Test Event will be held on 4-6 November, 2008, in +Plzen, Czech Republic, hosted by Kerio Technologies. +* CalConnect is continuing to consider an invitational "meet CalConnect" event in Europe but +the location and timing is still under discussion. + +== Future Meetings + +* ROUNDTABLE XIII: October 6-10, 2008, at Yahoo!, Sunnyvale, California. +Mobile IOP Test Event: November 4-6, 2008, at Kerio Technologies, Plzen, Czech Republic. +* ROUNDTABLE XIV: February 2-6, 2009, host and location TBD (east coast intended). +* ROUNDTABLE XV: June 1-5, 2009, host and location TBD (west coast intended). + +The format of the CalConnect week is: + +* Monday morning through Wednesday noon, C.I.T.E. (CalConnect Interoperability Test Event) +* Wednesday noon through Friday afternoon, Roundtable (presentations, TC sessions, BOFs, +networking, Plenary). diff --git a/sources/cc-0811-report-roundtable-13/document.adoc b/sources/cc-0811-report-roundtable-13/document.adoc new file mode 100644 index 0000000..03fa94c --- /dev/null +++ b/sources/cc-0811-report-roundtable-13/document.adoc @@ -0,0 +1,159 @@ += Report on Roundtable XIII, October 8-10 2008 +:docnumber: 0811 +:copyright-year: 2008 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2008-10-10 +:published-date: 2008-10-10 +:technical-committee: CALCONNECT +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Introduction + +Roundtable XIII took place October 8-10, 2008, hosted by Yahoo!/Zimbra in Santa Clara, +California. The event was attended by 52 people from 19 organizations, including representatives +from two observers (organizations attending a Roundtable to see if they wish to join). + +The CalConnect Interoperability Test Event (CITE) was held immediately prior to the Roundtable, +October 6-8. Eleven organizations and 27 people participated in the regular test event, performing +interoperability testing between their calendaring and scheduling implementations. A reports on +the CITE will be published as soon as information has been delivered from all participants. + +The Roundtable was dedicated to technical committee sessions, BOFs, and informal discussions +and networking, with an all-hands Plenary meeting as the last item on Friday afternoon. The +Technical Committee sessions were as usual organized sequentially, without competing parallel +sessions, as is our standard practice to allow all attendees who wished to be involved in the +discussions of each Technical Committee the opportunity to do so. + +An additional ten invitees joined us for the Technical Previews session on Wednesday afternoon. +The previews demonstrated live interoperability in the areas of CalDAV Scheduling, iSchedule +Server-Server scheduling, and Free/Busy URL. The presentation accompanying the life demos +will be made available shortly on the CalConnect website. + +== Update on Technical Committees and Initiatives + +=== TC CALDAV + +TC CALDAV reported on its work since the last Roundtable and on the status of +the latest scheduling draft, which includes implicit scheduling. A number of issues were raised and +discussed which will be further discussed and resolved in TC calls going forward. Work on +calendar roles will be resumed once the scheduling issues have been resolved. + +=== TC EVENTPUB + +TC EVENTPUB presented use cases concerning event publication and venue +information, and proposed some solutions. The TC will begin work on a formal proposal. + +=== TC FREEBUSY + +TC FREEBUSY summarized its work on the FREEBUSY READ URL draft +proposal. The TC will continue work on finalizing the draft and will begin consideration of issues +involving richer Freebusy information and availability/office hours. + +=== TC IOPTEST + +TC IOPTEST reported on the IOP test event just completed and on plans to start +collecting and reporting on bug and issue information discovered during the IOP tests. The TC +will look into the possiblity of an iCalendar parser to be made availabe on the CalConnect +website. The TC also presented a live demo of the new Virtual Test Lab facility. + +=== TC iSCHEDULE + +TC iSCHEDULE presented the status of the draft protocol. Much of the +discussion was on URI schemes and security provisions, such as relying on SSL certificates or to +move to S-MIME certificates in the payload rather than the transport layer. The TC will begin +work on the formal protocol. + +=== TC MOBILE + +TC MOBILE reported on its work since the last Roundtable and presented +feedback from the Open Mobile Alliance Data Synchronization working group on the TC's +recently published work products: Mobile Calendar Interoperability Test Suite V1.1 and Mobile +Recurrence Interoperability Recommendations. Plans for future interoperability testing were +discussed, including the second CalConnect Mobile Calendaring Interoperability Test Event in +Nov 2008 and beta testing of the new CalConnect Virtual Test Labs. It was agreed that the next +work item for the TC will be a "CalDAV considerations for mobile calendaring" paper. + +=== TC TIMEZONE + +TC TIMEZONE presented work to date on its draft proposal and RFC, and on +tentative plans to offer an open Timezone Workshop at the next Roundtable. The TC will work on +completion of its registry specification RFC and on a CalConnect Proposal for the Timezone +Service. + +=== TC USECASE + +TC USECASE presented its work on a new Resource Recommendations +document which includes congruences between iCalendar and vCard. The TC will develop a +formal document for publication and will work to provide its recommendations for vCard +extensions to the IETF in time for its November meeting. + +=== TC XML + +TC XML reported on its work to date in developing a round-trippable transform of +iCalendar data to/from XML, including an outline of what the XML data would look like and a +Relax NG Schema. Going forward the TC will resolve open issues and prepare a formal draft +document. + +=== CalConnect Interoperability Test Event + +Participants in the IOP test included +Apple, E&S Software, Google, IBM, Kerio, Microsoft, PeopleCube, RPI (Bedework), Scalix, Sun, +and Yahoo!/Zimbra. Results from the event will be posted at Past IOP Reports as soon as they are +collated and prepared. + +=== New Initiatives + +* The CalConnect Virtual Test Lab will be piloted immediately after Roundtable XIII and +should be available for use by the Mobile IOP Test Event in November. +* The second Mobile Interoperability Test Event will be held on 4-6 November, 2008, in +Plzen, Czech Republic, hosted by Kerio Technologies. +* CalConnect will offer a half-day Meet CalConnect introductory event on November 7 in +Prague, and November 10 in London. +* CalConnect will host an open Timezone Workshop on Tuesday, February 3, during the +CalConnect XIV week in Redmond. + +== Future Events + +* Mobile IOP Test Event: November 4-6, 2008, at Kerio Technologies, Plzen, Czech Republic. +* Meet CalConnect introductory event: November 7 (Prague) and November 10 (London), 2008. +* CALCONNECT XIV: February 2-6, 2009, Microsoft, Redmond, Washington. +* CALCONNECT XV: June 1-5, 2009, host and location TBD. +* CALCONNECT XVI: October 5-9, 2009, host and location TBD. + +The format of the CalConnect week is: + +* Monday morning through Wednesday noon, C.I.T.E. (CalConnect Interoperability Test Event) +* Wednesday noon through Friday afternoon, Roundtable (presentations, TC sessions, BOFs, +networking, Plenary). diff --git a/sources/cc-0812-pres-meet-cc/images/img01.png b/sources/cc-0812-pres-meet-cc/images/img01.png new file mode 100644 index 0000000..c17cb2c Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img01.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img02.png b/sources/cc-0812-pres-meet-cc/images/img02.png new file mode 100644 index 0000000..f78f8f3 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img02.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img03.png b/sources/cc-0812-pres-meet-cc/images/img03.png new file mode 100644 index 0000000..1827d93 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img03.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img04.png b/sources/cc-0812-pres-meet-cc/images/img04.png new file mode 100644 index 0000000..713bdd5 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img04.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img05.png b/sources/cc-0812-pres-meet-cc/images/img05.png new file mode 100644 index 0000000..c0bbdb1 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img05.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img06.png b/sources/cc-0812-pres-meet-cc/images/img06.png new file mode 100644 index 0000000..10ae82e Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img06.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img07.png b/sources/cc-0812-pres-meet-cc/images/img07.png new file mode 100644 index 0000000..e862e90 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img07.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img08.png b/sources/cc-0812-pres-meet-cc/images/img08.png new file mode 100644 index 0000000..50d2f00 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img08.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img09.png b/sources/cc-0812-pres-meet-cc/images/img09.png new file mode 100644 index 0000000..ae4ea43 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img09.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img10.png b/sources/cc-0812-pres-meet-cc/images/img10.png new file mode 100644 index 0000000..17ee3b5 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img10.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img11.png b/sources/cc-0812-pres-meet-cc/images/img11.png new file mode 100644 index 0000000..3f7d392 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img11.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img12.png b/sources/cc-0812-pres-meet-cc/images/img12.png new file mode 100644 index 0000000..b56bbc5 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img12.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img13.png b/sources/cc-0812-pres-meet-cc/images/img13.png new file mode 100644 index 0000000..fb2e5a9 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img13.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img14.png b/sources/cc-0812-pres-meet-cc/images/img14.png new file mode 100644 index 0000000..f96bc29 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img14.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img15.png b/sources/cc-0812-pres-meet-cc/images/img15.png new file mode 100644 index 0000000..a485a61 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img15.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img16.png b/sources/cc-0812-pres-meet-cc/images/img16.png new file mode 100644 index 0000000..57b8f0d Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img16.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img17.png b/sources/cc-0812-pres-meet-cc/images/img17.png new file mode 100644 index 0000000..21f37f8 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img17.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img18.png b/sources/cc-0812-pres-meet-cc/images/img18.png new file mode 100644 index 0000000..99ccf72 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img18.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img19.png b/sources/cc-0812-pres-meet-cc/images/img19.png new file mode 100644 index 0000000..f3d85fc Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img19.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img20.png b/sources/cc-0812-pres-meet-cc/images/img20.png new file mode 100644 index 0000000..f076133 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img20.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img21.png b/sources/cc-0812-pres-meet-cc/images/img21.png new file mode 100644 index 0000000..a62d9f8 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img21.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img22.png b/sources/cc-0812-pres-meet-cc/images/img22.png new file mode 100644 index 0000000..57636cc Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img22.png differ diff --git a/sources/cc-0812-pres-meet-cc/images/img23.png b/sources/cc-0812-pres-meet-cc/images/img23.png new file mode 100644 index 0000000..6d3da60 Binary files /dev/null and b/sources/cc-0812-pres-meet-cc/images/img23.png differ diff --git a/sources/cc-0812-pres-meet-cc/metanorma.yml b/sources/cc-0812-pres-meet-cc/metanorma.yml new file mode 100644 index 0000000..9ed93c2 --- /dev/null +++ b/sources/cc-0812-pres-meet-cc/metanorma.yml @@ -0,0 +1,11 @@ +--- +metanorma: + source: + files: + - pres-intro-01.adoc + - pres-intro-02.adoc + - pres-iop-testing.adoc + - pres-ischedule.adoc + - pres-tc-mobile.adoc + - pres-bedework.adoc + - pres-stockholm.adoc diff --git a/sources/cc-0812-pres-meet-cc/pres-bedework.adoc b/sources/cc-0812-pres-meet-cc/pres-bedework.adoc new file mode 100644 index 0000000..aa9fcd5 --- /dev/null +++ b/sources/cc-0812-pres-meet-cc/pres-bedework.adoc @@ -0,0 +1,356 @@ += CalConnect and Open Source +:docnumber: 0812 +:copyright-year: 2008 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2008-11-07 +:published-date: 2008-11-07 +:technical-committee: CALCONNECT +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Gary Schwartz +:affiliation: Communications & Middleware Technologies, Rensselaer Polytechnic Institute +:contributor-position: Director +:imagesdir: images + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks +and Disclaimer of Warranty for External (Public) Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +[IMPORTANT] +==== +All documents included in the zip file for Meet CalConnect 2008 are considered part of CD 0812 and the public disclaimer included by reference above applies to all contents of the file. +==== + +Presentation location:: Prague, Czech Republic + +== Please Allow Me to Introduce Myself + +Gary Schwartz + +* Director, Communications & Middleware Technologies, Rensselaer Polytechnic Institute +* Bedework Project Leader +* CalConnect Vice President & Chair of FreebusyTechnical Committee + +== What I will be talking about + +* Bedework, our open source, Java-based implementation of CalDAV +* The relationship between CalConnect and the open source movement +* RPI's reasons for joining CalConnect +* The benefits which RPI enjoys from active participation in CalConnect, both as +calendar developers and as a research university + +== Rensselaer History + +The Rensselaer School was established in Troy, NY, in 1824 by Stephen Van Rensselaer +"for the purpose of instructing persons ... in the application of science to the +common purposes of life." + +It is + +[quote,"Palmer C. Ricketts 2nd ed History of Rensselaer Polytechnic Institute (1914)"] +____ +...the first school of science and +school of civil engineering, which has had +a continuous existence, to be established +in any English-speaking country. +____ + +.RPI Back in the Day +image::img11.png[] + +.Rensselaer Today +==== +[%unnumbered] +image::img12.png[] + +[%unnumbered] +image::img13.png[] + +[%unnumbered] +image::img14.png[] + +[%unnumbered] +image::img15.png[] +==== + +== Overview of Bedework + +[%unnumbered] +image::img16.png[] + +=== What Is Bedework? + +Bedework is + +* a comprehensive calendaring and events system +* open source +* platform independent (Java) +* modular & extensible +* intended for higher education +* and... *STANDARDS COMPLIANT* + +=== Calendaring Standards + +* iCal : RFC 2445 (2446, 2447) +** http://www.ietf.org/rfc/rfc2445.txt +* CalDAV : RFC 4791 +** http://www.ietf.org/rfc/rfc4791.txt +* CalDAV Scheduling (in draft) +* Vavailability (in draft) + +Why? ...interoperability! + +=== Agnosticisms of Bedework + +* Database -Hibernate +* Application server +* Authentication +* Internationalization / localization +* Portal -- JSR168 +* Presentation +* Standards compliance +* Scalability + +=== Bedework Features + +Features: + +* Distributed, fine grained administration +** Administrative groups +** Location and contacts management +* Access control & sharing +* Stand-alone & portlet implementations +* Highly customizable look and feel +* *Interoperable with CalDAV desktop clients* -- currently Mozilla Lightning and Apple's iCal + +=== Who's Using Bedework? + +In production: + +* Bennington College (US) +* Bishop's University (Canada) +* Cornerstone University (US) +* Dalhousie University (Canada) +* Duke University (US) +* Montana State University (US) +* Public University of Navarra(Spain) +* Queens University (Canada) +* Rensselaer Polytechnic Institute (US) +* University of British Columbia (Canada) +* University of Maine, Fort Kent (US) +* University of Maryland (US) +* University of Chicago (US) +* University of Washington (US) + +In development: + +* Brown University (US) +* Cornell University (US) +* Rutherford Appleton Lab (UK) +* Stockholm University (Sweden) +* Yale University (US) +* Others... + +=== The Many faces of Bedework + +.The Many faces of Bedework +==== +[%unnumbered] +image::img17.png[] + +[%unnumbered] +image::img18.png[] + +[%unnumbered] +image::img19.png[] + +[%unnumbered] +image::img20.png[] +==== + +.Another face of Bedework +image::img21.png[] + +[bibliography] +== References + +* [[[bedework,Bedework]]], bedework.org + +== Open Source + +=== I'm a programmer + +* not a bricklayer +* not a psychiatrist +* not an escalator +* not a mechanic +* not an engineer +* not a coal miner + +Or + +An open source theorist + +[%unnumbered] +image::img22.png[] + +=== Open Source -- What do we mean? + +* http://www.opensource.org/docs/osd[Open Source Initiative] +** The 'open source' label was invented February 3rd, 1998 in Palo Alto, California +** Wanted an alternative to "free software" +** 'Open source' coined by Chris Peterson +** Open source doesn't just mean access to the source code. The distribution terms of +open-source software must comply with the 10 enumerated criteria + +=== Open source is a continuum + +* Product provenance +* Licensing terms +* Support +* Governance +* Sometimes east meets west -like when Georgia Tech integrated Zimbra (proprietary +version) into Sakai (open source) using CalDav, facilitating future integrations, +open source or otherwise. + +=== OSS and the marketplace + +* Open source is inherently neither better nor worse than other software development +or distribution models +* Open source provides another option, representing a different value proposition + +== Bedework The Open Source Project + +=== RPI and OSS + +[quote] +____ +[underline]#Whereas many university people enjoy a spiritual affinity for open source +software, our interest is more pragmatic.# As a campus-wide development group, +technologies and products with no license or usage fees are critical to providing +solutions which can be deployed with impunity. Our web foundation is largely built +atop products and technologies which have no usage fees, allowing us to deploy as +many instances, servers, CPU's, etc as necessary. +____ + +[quote] +____ +[underline]#RPI relies heavily on and benefits from open source# software but seldom +contributes to open source. We believe this contribution will enhance Rensselaer's +reputation in the area of software development. +____ + +=== Interoperability + +* Bedework's preoccupation with standards and interoperability is in large part +recognition that in many organizations, *Bedework is unlikely to be the only +calendaring product in an enterprise.* +* The ability to share and exchange data with other calendaring products and +environments is an important key to Bedework's future well-being as a product and a +project. + +=== Standards compliance -- the double-edged sword + +* Standards compliance is the key to Bedework's success -but +** potentially useful features that are not standards compliant impede interoperability. +** We could be more ingenious but sometimes no way to have our standards cake and eat it too. +** The heart wants what it wants. + +== CalConnect And Open Source + +=== OSS and CalConnect + +* CalConnect vendor members +** Proprietary only +** Open source only -- Bedework, Mozilla, OSAF +** Dual mode -- Apple, Zimbra +** Mixed -- Google, IBM, Oracle, Sun, Symbian/Nokia, Microsoft + +=== CalConnect and OSS organizations + +* The world is flat - open source, +proprietary source, no source -- +everyone is equal partner +* Sometimes open source organizations have more flexibility and agility and fewer +constraints to participate, to speak publicly + +=== Ron Abel -- 4 postulates + +. Open source reference implementations are +extremely critical in achieving adoption of open +standards for software interoperability. +. Standards organizations are the only way to get a +level playing field w.r.t new open source +applications for learning -- that won't happen +unless the open source projects/communities +participate. + +http://blog.worldcampus.psu.edu/index.php/2007/09/19/open-source-and-open-standards/ + +=== OSS vendors -- why join CalConnect? + +* Join CalConnect to add adopters? Unlikely. More likely to find collaboration +partners than customers +* CalConnect members generally get "it" when "it"= "open source". +* CalConnect vendor members generally get "it" where "it"= good products benefit from +interoperability, becoming stronger, more marketable products. + +=== CalConnect as an open source entity + +In Dreaming in Code", Scott Rosenberg referring to Eric Raymond's "The Cathedral and the Bazaar" said, + +[quote,"Scott Rosenberg"] +____ +Raymond identified 2 key prerequisites ...the *rise of a cooperative ethos* built +around a leadership style like Torvald's that *encouraged newcomers* and *welcomed +contributions*, and *strove to maximize the number of qualified participants* +____ + +== Why We Joined CalConnect + +* We have history of collaborative (but not OSS) software development -- MTS +* We have a history of working with high quality people -- MTS +* We saw first-rate people doing exciting work and we wanted to be part of it. + +[%unnumbered] +image::img23.png[] + +=== Why we really joined + +We were showing off as observers at a CalConnect Roundtable, and had to join to save face. + +=== What RPI gets from participation in CalConnect, both as calendar developers and as a research university + +Like the Beatles said: + +[quote, Beatles] +____ +And, in the end, the love you take/ Is equal to the love you make +____ + + +* *Active participation* in CalConnect +** Chair FREEBUSY Technical Committee +** Chair Timezone Technical Committee +** iSchedule, CalDAV Technical Committees +** Publicity Committee +** Steering Committee +** Board of Directors + +=== CalConnect -- the benefits + +* CalConnect has many research university members. Getting together with like +institutions to discuss C&S and other topics of mutual interest. +* Interoperability Test Events are invaluable +* Influencing/informing standards is useful, and a responsibility + +== The bottom line + +We believe in interoperability and open standards -- CalConnect promotes both diff --git a/sources/cc-0812-pres-meet-cc/pres-intro-01.adoc b/sources/cc-0812-pres-meet-cc/pres-intro-01.adoc new file mode 100644 index 0000000..b148e61 --- /dev/null +++ b/sources/cc-0812-pres-meet-cc/pres-intro-01.adoc @@ -0,0 +1,78 @@ += An Introduction to The Calendaring and Scheduling Consortium +:docnumber: 0812 +:copyright-year: 2008 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2008-11-07 +:published-date: 2008-11-07 +:technical-committee: CALCONNECT +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:imagesdir: images + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks +and Disclaimer of Warranty for External (Public) Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +[IMPORTANT] +==== +All documents included in the zip file for Meet CalConnect 2008 are considered part of CD 0812 and the public disclaimer included by reference above applies to all contents of the file. +==== + +Presentation locations: + +* November 7: Prague, Czech Republic +* November 10: London, United Kingdom + +== Agenda + +* Introduction to CalConnect +** Dave Thewlis, Executive Director, CalConnect +* Interoperability Testing and Standards Development +** Patricia Egen, Interoperability Test Event Manager +* CalConnect Technical Committees +** TC MOBILE -- Chris Dudding, Symbian +** TC iSCHEDULE -- Mattias Amnefelt, Stockholm University +* CalConnect and Open Source +** Gary Schwartz, Rensselaer Polytechnic Institute +* CalConnect from a Member Perspective +** Gary Schwartz, Rensselaer Polytechnic Institute +** Tomáš Hnétila, Kerio Technologies +** Mattias Amnefelt, Stockholm University +* General Question & Answer Session + +== The Presenters + +* Mattias Amnefelt +** Affiliation: Stockholm University +** iSchedule Technical Committee +* Chris Dudding +** Affiliation: Symbian +** Chair, Mobile Technical Committee +* Patricia Egen +** Affiliation: Patricia Egen Consulting +** CalConnect Interoperability Test Event Manager +* Tomáš Hnétila +** Affiliation: Kerio Technologies +* Gary Schwartz +** Affiliation: Rensselaer Polytechnic Institute +** Chair, Freebusy Technical Committee +* Dave Thewlis +** CalConnect Executive Director + +== Questions + +* You may ask questions at any time +** During a presentation +** At the end of a presentation +** At the General Question and Answer Session +* The Presenter may ask you to defer your question to later +* If you have a question we don't answer +** E-mail it to the appropriate presenter or to Dave Thewlis +** We'll get you an answer diff --git a/sources/cc-0812-pres-meet-cc/pres-intro-02.adoc b/sources/cc-0812-pres-meet-cc/pres-intro-02.adoc new file mode 100644 index 0000000..e8a1fb1 --- /dev/null +++ b/sources/cc-0812-pres-meet-cc/pres-intro-02.adoc @@ -0,0 +1,691 @@ += Introduction to CalConnect: The Calendaring and Scheduling Consortium +:docnumber: 0812 +:copyright-year: 2008 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2008-11-07 +:published-date: 2008-11-07 +:technical-committee: CALCONNECT +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Dave Thewlis +:affiliation: The Calendaring and Scheduling Consortium +:contributor-position: Executive Director +:imagesdir: images + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks +and Disclaimer of Warranty for External (Public) Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +[IMPORTANT] +==== +All documents included in the zip file for Meet CalConnect 2008 are considered part of CD 0812 and the public disclaimer included by reference above applies to all contents of the file. +==== + +[heading=terms and definitions] +== Definitions + +=== Calendar +A collection of events, tasks, journal entries, etc. +Examples include a person's or group's schedule, +resource availability, and event listings. + +=== Scheduling +The exchange of request/invitations and +responses between organizers and attendees of +scheduled events, tasks or journal entries. + +=== CalConnect +The Calendaring and Scheduling Consortium, +consisting of vendors and user groups interested +in promoting and improving calendaring and +scheduling [underline]#standards and interoperability#. + +== Why CalConnect was established + +=== 1996-1999 + +* 1996 Versit Consortium issued vCalendar +* 1996 IETF CALSCH working group started on iCalendar specification +* 1997 Work began on Calendaring Access Protocol (CAP) calendar server draft +* 1998 iCalendar (RFC 2445), iTIP (RFC 2446) and iMIP (RFC 2447) became proposed standards +* 1998-2000 Some interoperability testing + +=== 2000-2004 + +* Work on CAP -- stopped +* Interoperability testing -- stopped +* Work on iCalendar, iTIP and iMIP -- stopped +* IETF CALSCH working group -- stopped +* Vendors started to diverge from the standards to enhance their products +* *The draft RFCs were not ready* +** Too ambiguous +** Too complex +** Untested + +=== Establishment of CalConnect + +CalConnect was founded in January of +2004 to promote interoperable +Calendaring and Scheduling. + +[quote] +The driving premise behind the Consortium is that +interoperability between calendaring programs and +systems is essential to achieving the promise and +future growth of calendaring. + +=== What is CalConnect? + +* An information technology consortium focused on calendaring and scheduling +* A collegial partnership between vendors and customers working towards achieving common goals of interoperability and functionality + +=== Why do we need CalConnect? + +* Improve the general understanding and applicability of calendaring +* Promote the technologies +* Improve the technologies and standards, in particular with regard to interoperability + +=== The Vision + +[quote,"Dave Thewlis, CalConnect Executive Director"] +Our vision of the future is not only +interoperable calendaring, but ubiquitous +interoperable calendaring. Calendaring +should--and can--be as ubiquitous as +electronic mail. + +[quote,"Pamela Taylor, CalConnect Board Member"] +Being able to schedule meetings with my +work group is important. But being able to +schedule an appointment with my +hairdresser could change the world. + +=== CalConnect Members + +[%unnumbered] +image::img06.png[] + +=== CalConnect Membership List + +* Apple Inc. +* Cabo Communications{blank}footnote:eu[European Member] +* California State University Fresno +* Carnegie Mellon University +* Dartmouth College +* Duke University +* Eventful +* Google +* IBM +* Kerio Technologies{blank}footnote:eu[] +* MailSite Software{blank}footnote:eu[] +* M.I.T. (Mass. Institute of Technology) +* Microsoft +* Mozilla Foundation +* neutralSpace +* New York University +* Oracle Corporation +* OSAF (Open Source Appl. Foundation) +* Patricia Egen Consulting +* PeopleCube +* R.P.I. (Rensselaer Polytechnic Inst.) +* Scalix{blank}footnote:eu[] +* Sony Ericsson{blank}footnote:eu[] +* Stanford University +* Stockholm University{blank}footnote:eu[] +* Sun Microsystems +* SWAMI (Swedish Alliance for Middleware Infrastrucure){blank}footnote:eu[] +* Symbian Ltd.{blank}footnote:eu[] +* Synchronica{blank}footnote:eu[] +* Timebridge +* University of California +* University of Chicago +* University of Michigan +* University of Pennsylvania +* University of Washington +* University of Wisconsin +* Yahoo!/Zimbra + +=== What do we do? + +What we do + +* Drive evolution of open standards for C&S +* Requirements, use cases, specifications and protocols +** May be submitted to IETF etc. for progression to standards +* Interoperability testing +* Promote a shared vision of calendaring and scheduling + +The organizational model of CalConnect + +* All members have same rights and privileges +* Collegial, consensus environment +* Completed work products published +* Member may have unlimited participation +* Interoperability testing open to non-members + +=== What we've done so far + +* Substantial input to the IETF on new versions of calendaring RFCS (e.g. recurrences, timezones, minimum interoperability subsets) +* Work on CalDAV, CalDAV Scheduling, extensions to CalDAV +* Recommendations and guidance on Extended Daylight Savings Time +* Timezone Registry and Service Recommendations +* Mobile calendaring white paper (value of iCalendar for the mobile industry) +* Mobile calendaring interoperability test suite +* Mobile calendaring recurrence recommendations +* Surveys and use cases for calendaring events and tasks (`VTODO`) +* Calendaring and Scheduling Glossary +* Calendaring administrator's mailing list +* Thirteen successful interoperability test events among up to eleven calendaring and scheduling implementations +* First two Mobile Calendaring Interoperability Test Events +* Demo of Federated Freebusy data consolidation in 2006 +* Technical Previews at CalConnect events of CalDAV Scheduling, iSCHEDULE, and Freebusy URL + +=== Events + +. Interops (Interoperability Testing) +** Open to members and non-members +** 2.5-3 day event usually co-located with Roundtable +** Results published to relevant standards development +organizations +** Public reports omit some details + +. Roundtables +** Members' meetings of CalConnect +** Held three times per year, midway between IETF meetings +** Held in conjunction with Interops +** Technical committee working meetings +** Steering Committee meeting +** Review and status of technical committees + +. Technical Workshops +** Participation by members and invited guests +** Co-hosted with Roundtable or independent event +** Presentations and findings publicly available on CalConnect website + +. Calendaring & Scheduling Public Conference +** *Under evaluation* +** Would offer technology and product overviews, +tutorials and classes, demonstrations and vendor +offerings + +=== Current Technical Committees + +==== CALDAV + +Define use cases and +requirements for CalDAV; +assist in development of CalDAV +and CalDAV Scheduling specifications + +==== EVENTPUB + +Define event publishing +& establish differences +from normal +calendaring and +scheduling + +==== FREEBUSY + +Develop and conduct +Federated Freebusy +Challenge Response; +Freebusy URL protocol; +availability and office hours + +==== IOPTEST + +Support interoperability +testing for all technical +committees, develop +test suites & reference +implementation, publish +IOP test results + +==== iSCHEDULE + +Develop Internet Scheduling Protocol +(iSCHEDULE) (iTIP over HTTP) +for submission as proposed standard to IETF + +==== MOBILE + +Define issues for mobile +support of standards-based +Calendaring and +recommend extensions +to standards for mobile +support + +==== TIMEZONE + +Develop proposals for a +formal, authoritative +Timezone Registry and +a Timezone Service +Protocol + +==== USECASE + +Develop sets of real +world use cases that +can be used to validate +identified functionality & +testing scenarios for +existing & future C&S +implementations + +==== XML + +Develop XML specification for iCalendar that is fully round-trippable + +=== The Current State of Calendaring Standards + +==== Calendaring Standards Today + +===== RFCs 2445/6/7 (iCalendar, iTIP, iMIP) + +* Target of initial CalConnect work products +* All have revised drafts underway +* Expect publication of revised RFCs in 2008/2009 +* Still require interoperability demonstration to +progress to Draft Standards (i.e. CalConnect) +* IETF "CALSIFY" Working Group to simplify (rationalize) RFCs 2445/6/7 +** Substantial input from CalConnect + +===== CalDAV + +* "Calendaring Extensions to WebDAV" published as +Proposed Standard, RFC 4791 +* "Scheduling Extensions to CalDAV" is draft in IETF +* CalDAV implementations by CalConnect members +** Apple +** Bedework +** Kerio Technologies +** Mozilla +** neutralSpace +** Oracle +** OSAF +** Scalix +** Sun +** Zimbra + +[.source] +<> + +===== iCalendar Extensions + +* `VAVAILABILITY` +** New iCalendar component allowing publication of available and unavailable time periods associated with calendar user +* `VVENUE` +** New iCalendar component allowing the specification of structured location data for publishing event information + +===== vCard and CardDAV + +* Not strictly "calendaring" but closely related +* Revision work underway in IETF +* `RESOURCE REF` intended to embed vCard information into iCalendar + +== CalConnect Technical Committees + +=== TC CALDAV + +==== Charter + +* Begin: October 2004 +* Define problems CalConnect wishes to resolve with _CalDAV Extensions to WebDAV_ +* Work with authors on CalDAV specifications + +==== Projects, Topics + +* Develop requirements and use cases for CalDAV (and CalDAV authors are members of TC CALDAV) +* Develop CalDAV testing matrices for TC IOPTEST +* Develop `VAVAILABILITY` with TC FREEBUSY +* Support development of CalDAV Scheduling +* Extensions to CalDAV Scheduling (discovery, security) + +==== Products + +* CalDAV testing matrices +* CalDAV use cases and requirements +* CalDAV scheduling and extensions to CalDAV scheduling +* *`VAVAILABILITY` Freebusy extensions* + +=== TC EVENTPUB + +==== Charter + +* Begin: March 2005 +* Define Event Publication and distinguish from regular +calendaring +* Determine requirements for event publication not met by +existing specifications and propose remedies + +==== Projects, Topics + +* Review of possible extensions to iCalendar to support +event publication and venue information +* Develop mechanism for event "crawlers" to find and +consume event information on websites, analogous to +"sitemap" + +==== Products + +* `VVENUE` extension to iCalendar +* `EVENTMAP` proposal +* *`RESOURCE REF` proposal under development* + +=== TC FREEBUSY + +==== Charter + +* Begin: May 2006 +* Act as CalConnect Liaison with The Open Group for the Federated +Freebusy Challenge in 2006 +* Inform the work of CALDAV, REALTIME, and other TCs +* Participate in drafting the final report for The Open Group + +==== Projects, topics + +* Demo-ed a Federated Freebusy Aggregator at The Open Group +meeting in July 2006 +* Assist Boeing to "productize" components used in the demo as well +as those being further developed by Boeing +* *Standardize and simplify FREEBUSY URL* +* *Revisit Freebusy extensions (availability, office hours)* + +==== References + +* http://tools.ietf.org/html/draft-daboo-calendar-availability-00 +* http://calconnect.org/publicity/060724freebusydemorelease.pdf +* http://calconnect.org/presentations/freebusydemo.pdf + +=== TC IOPTEST + +==== Charter + +* Begin: October 2004 +* Conduct CalConnect Interoperability Test Events and +publish results + +==== Projects, topics + +* CalConnect Interoperability Test Events scheduled with +each Consortium event week (i.e. together with +Roundtables) +* CalConnect Virtual Test Lab (with TC MOBILE) +* iCalendar .ics stream syntax and semantics checking tool + +==== Products + +* Public and CalConnect-internal IOP test event reports +* *iCalendar (.ics stream) syntax and semantics tool* +* *Virtual Test Lab (with TC MOBILE)* + +=== TC iSCHEDULE + +==== Charter + +* Rechartered June 2008 (originally TC REALTIME) +* Develop proposal for Internet Scheduling Protocol (iSCHEDULE) (iTIP via HTTP) + +==== Projects, topics + +* Recommendations for Addressability, Discovery, Authentication, Authorization +* iSCHEDULE Protocol internet draft and RFC + +==== Products + +* *iSCHEDULE Internet Draft* +* *iSCHEDULE RFC* +* *IOP testing matrices* + +=== TC MOBILE + +==== Charter + +* Begin: September 2005 +* Identify issues related to mobile calendaring and +scheduling and develop recommendations to address + +==== Projects, topics + +* Determine mobile calendaring issues and problems +* Survey mobile users about problems +* Evaluate issues with continued use of vCalendar and develop ways of moving vendors forward to iCalendar +* Mobile Calendaring Interoperability Test Suite +* *Implement Mobile Calendaring IOP Test Events and Virtual Test Lab (with TC IOPTEST)* +* *Mobile Calendaring Considerations for CalDAV* + +==== Products + +* Report on Mobile Calendaring Questionnaires +* White Paper: Benefits of iCalendar for the Mobile Industry +* Mobile Calendaring Interoperability Test Suite +* Mobile Recurrence Interoperability Recommendations + +=== TC TIMEZONE (Phase 2) + +==== Charter + +* Begin: May 2007 +* Continue work of TC TIMEZONE by developing formal +proposals based on Timezone Registry and Service +Recommendations + +==== Projects, topics + +* Develop proposal for formal, authoritative Timezone +Registry for submission to IETF to be published as an RFC +* Develop requirements for Timezone Registry Service +* Develop proposals for Timezone Registry Service +implementations using current protocols + +==== Products + +* *Timezone Registry RFC* +* *Timezone Service Protocol* + +=== TC USECASE + +==== Charter + +* Begin: October 2004 +* Develop use cases for calendaring and scheduling and +their contextual environments +* Establish the ways that users actually want to use +calendaring environments +* Establish "Minimum Interoperable Subsets" (the minimum +set of functions which must be interoperable to make an +implementation useful to a customer) + +==== Projects, topics + +* *Recommendations on Resources in iCalendar* +* *Survey and use cases for groups* + +==== Products + +* Min-IOP Use Cases for iCalendar +* CalDAV Use Cases (with TC CALDAV) +* Min-IOP Use Cases for Tasks +* Calendaring and Scheduling Glossary of Terms +* *Recommendations for Resources* +* *Analysis of "group" implementations* + +=== TC XML + +==== Charter + +* Begin: February 2008 +* Develop two-way reference mapping between iCalendar and + +==== Projects, topics + +* Round-trippable reference mapping between iCalendar and XML such that same iCalendar input products same XML result +* Mapping such that iCalendar or XML input can be round-tripped without losing or changing content + +==== Products + +* *XML Reference Mapping and Schema* +* *MIME media type to transport XML version of iCalendar data* +* *Submission to IETF as RFC* + +=== DST AD HOC + +==== Charter + +* Begin: June 2005 +* Establish CalConnect position on Extended Daylight Savings Time Proposal by U.S. Congress +* Continue DST Advisory Work + +==== Projects, topics + +* Develop CalConnect position on EDST and communicate to U.S. Congress prior to enactment of law +* Develop guidance for industry on planning for and implementing EDST Changes in March and October +* Work with TC TIMEZONE on recommendations on future of timezone and DST support + +==== Products + +* Extended Daylight Savings Time Advisory +* Extended Daylight Savings Time Review and Considerations +* EDST Links, Advisories and Changes +* CalConnect Reflections and Recommendations -> +* *TC TIMEZONE Phase 2* + +=== TC RECURR + +==== Charter + +* Begin: October 2004 (completed February 2006) +* Identify problems with Recurrences in iCalendar +* Make recommendations to IETF CALSIFY effort (revision of RFC 2445 iCalendar) + +==== Projects, topics + +* Questionnaires to determine problems with recurrence in implementations of iCalendar +* Develop problem statement and recommendations + +==== Products + +* Results from Recurrence Questionnaire +* iCalendar Recurrence Problems and Recommendations + +=== TC TIMEZONE (Phase 1) + +==== Charter + +* Begin: October 2004 (completed February 2006) +* Identify problems with timezone usage in iCalendar and timezone support in genera + +==== Projects, topics + +* Conduct survey on problems with timezone management +* Develop problem statements and recommendations for IETF CALSIFY effort for iCalendar + +==== Products + +* Timezone Questionnaire +* Report on Timezone Questionnaire +* Timezone Problems and Recommendations +* Timezone Registry and Service Recommendations + +=== vCard Ad Hoc + +==== Charter + +* Begin: January 2007 +* Determine interest in and support for revision of vCard standard + +==== Projects, topics + +* vCard Workshop planning and implementation +* Liaisons with OMA/DS on interest in vCard Revision +* Recommendation on establishment of vCard TC + +==== Products + +* vCard Workshop (September 2007) +* Recommendation not to establish separate vCard TC +* Influenced initiation of vCard/CardDAV working group in IETF + +=== Where are we going? + +==== New Activities + +* Second Mobile Calendaring Interoperability Test Event just completed +* iSCHEDULE Internet Scheduling Protocol +* CalDAV Scheduling and Extensions +* Timezone Registry and Timezone Service +* Freebusy URL extensions for availability +* Resource Ref extensions in iCalendar +* Interoperability Virtual Test Lab +* Expansion of Interoperability Testing areas +* Event Sharing between servers (event publication extensions) +* Automated Scheduling Updates (implicit scheduling) (CalDAV) +* External Attachments (CalDAV) +* Rich Freebusy data +* iCalendar/XML mapping +* Meet CalConnect Invitational Events + +==== Future Directions + +* Diverse calendaring specifications and tools +** Rationalize to achieve interoperability and synergy +* Calendaring libraries and APIs +** Assist implementations +** Support interoperability +* Calendaring as a Platform +** E.g. Project Management, Appointment Systems +* Calendaring Infrastructure and types +** E.g. enterprise, federation, services, ad hoc +* Mobile Calendaring +** Increasing focus on mobile in ICT and computing infrastructure and technologies +** Catapult mobile calendaring into 21^st^ Century +* Participation in new areas +** Vertical industry focus (e.g. mobile operators) +** Government and private industry focus and requirements +* European Presence for CalConnect +** >20% of members are European +** New companies and products +** Focus on mobile and calendar integration +** How do we make this a reality + +[bibliography] +== References + +* [[[ccw, CalConnect Web Site]]], http://www.calconnect.org + +* [[[ccpd, CalConnect Published Documents]]], http://www.calconnect.org/aboutproducts.shtml (Questionnaires, Recommendations, Use Cases and Requirements, Mobile Interoperability Test Suite, Calendaring and Scheduling Glossary of Terms, Event Reports, vCard Workshop Report) + +* [[[ccs, CalConnect Calendaring Standards]]], http://www.calconnect.org/calendaringstandards.shtml + +* [[[ccp, CalConnect Presentations]]], http://www.calconnect.org/presentations.shtml + +* [[[ccdst, CalConnect DST Documents]]], http://www.calconnect.org/dstdocs.shtml + +* [[[caldav,CalDAV]]], http://caldav.calconnect.org + +== More Info + +. Website: http://www.calconnect.org +. Contact us: info@calconnect.org +. For more information: ++ +-- +Dave Thewlis, Executive Director + +The Calendaring and Scheduling Consortium + +4390 Chaffin Lane + +McKinleyville, CA 95519-8028 + +Voice: +1 707 840 9391 + +FAX: +1 415 946 3454 + +Mobile: +1 707 498 2238 + +Email: Dave.Thewlis@calconnect.org +-- diff --git a/sources/cc-0812-pres-meet-cc/pres-iop-testing.adoc b/sources/cc-0812-pres-meet-cc/pres-iop-testing.adoc new file mode 100644 index 0000000..e1e718b --- /dev/null +++ b/sources/cc-0812-pres-meet-cc/pres-iop-testing.adoc @@ -0,0 +1,159 @@ += Interoperability Testing and Standards Development +:docnumber: 0812 +:copyright-year: 2008 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2008-11-07 +:published-date: 2008-11-07 +:technical-committee: CALCONNECT +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Patricia Egen +:affiliation: The Calendaring and Scheduling Consortium +:contributor-position: Interoperability Testing Manager +:imagesdir: images + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks +and Disclaimer of Warranty for External (Public) Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +[IMPORTANT] +==== +All documents included in the zip file for Meet CalConnect 2008 are considered part of CD 0812 and the public disclaimer included by reference above applies to all contents of the file. +==== + +== What is Testing outside of CalConnect + +* Several organizations do testing for conformance purposes +* This is usually against a small subset of operations and uses testing tools +* The goal is to "pass certification" +* Some groups do very large TEST-FESTs again with the goal of conformance testing +** Typically limited to very specific test cases + +== What is Interoperability Testing at CalConnect? + +At CalConnect, we test partner pairs, at face to face functions: + +* Specific test cases are outlined and documented +* Testing typically done by developers +** In some cases, the developers are the authors of the specifications being tested +* They are able to find and often times fix existing problems onsite +* Discussions with other developers are held +* Even though they are testing a specification, the developers know their products +* The ultimate goal is better interoperability across vendor implementations + +== Testing Timeline + +.CalConnect Interoperability Testing +image::img01.png[] + +== Standards Development + +As a protocol advances, our testing expands to accommodate the new specifications added to a protocol + +* For example, Scheduling was added to CalDAV in the latter part of 2007. +* In 2008, we started testing vendor implementations of the specification +* This allows the vendors to see in real time how their applications perform against other products +** Seeing quickly what works or doesn't work allows the authors of the specification to make changes that will encourage interoperability +** Case in point --at the October 2008 Interoperability Testing Event, 8 servers and 4 clients held CalDAV testing and two of the clients supported CalDAV Scheduling + +== Interoperability Testing Pre-Specification + +* iSchedule is new in 2008 +** Still in the discussion mode +** Not yet defined as a specification + +* The CalConnect Community enabled members to work together and actually have interoperability happening prior to a specification creation +* In October, we tested implementations of the new "specification under development" +** This is an example of vendors quickly rolling out software using a proposed new specification +** In this case, it will lead to a specification that has a good chance of acceptance and interoperability + +== How Do Organizations Participate + +Any member or non-member may participate in a CalConnect Interoperability Test Event + +* Submit a registration application +* Agreement to abide by the rules of the event +* Payment of the appropriate fee. + +Any member or non-member may attend [underline]#a single# CalConnect Interoperability Test Event as an Observer + +* The same bullet points as above apply + +CalConnect provides the location, Internet connectivity, testing documents, and food + +* Typically, a CalConnect member organization hosts the event + +== What Happens at an Interoperability Event + +* Participants provide details on how to access their servers and clients +* Test suites and/or Test Matrices are used for testing +* Partner testing pairs are set up and each pair tests using the testing documents +* Participants document findings and deliver them to the Interoperability Testing Manager +* Impromptu meetings are held during the event to allow participants to have adhoc discussions +** This is often the first time people who have been testing together informally meet for the first time +** Face to face testing has proven to be invaluable to participants + +== Our October 2008 Event --Yahoo Campus + +* 8 CalDAV Servers +* 4 CalDAV Clients +* IBM / Microsoft iCalendar testing + +[%unnumbered] +image::img02.png[] + +[%unnumbered] +image::img03.png[] + +[%unnumbered] +image::img04.png[] + +== What is Produced from the Testing + +CalConnect produces two documents several weeks after the Testing is completed + +* An [underline]#*members-only internal document*# details in depth who tested what, with whom and what failed or succeeded. +* A Public document outlines what was tested and general observations but excludes actual references to vendor results + +The Public documents are shared with Standards organizations to assist them with modifications and/or enhancements to the tested specifications. + +Prior CalConnect Reports available back to July 2004: http://www.calconnect.org/eventreports.shtml + +== What is Publicly Available + +* Test suites are publicly available on the CalConnect website +* Past Public reports can be downloaded and reviewed +* A new Virtual Testing Lab is in Beta now +** Once complete, external developers can use the Virtual Lab to further test their implementations + +== Virtual Test Lab + +The site is a series of work areas: + +* User id request +* Logon screen +* Profile Setup +* Create a Test or +* Join a test event in progress +* Report findings on a Wiki page + +.Virtual Test Lab +image::img05.png[] + +== Future Projects + +* Complete the Virtual Testing Lab (`VCITE`) +* We are currently working on an iCalendar validation tool that will reside on our website +** The goal is that people can paste iCalendar streams into the tool and it will identify issues and validate that the text is structured correctly +* Continued Interoperability testing on: +** CalDAV Scheduling +** CalDAV Security and Roles +** iSchedule +** Mobile Calendaring Testing diff --git a/sources/cc-0812-pres-meet-cc/pres-ischedule.adoc b/sources/cc-0812-pres-meet-cc/pres-ischedule.adoc new file mode 100644 index 0000000..88d963d --- /dev/null +++ b/sources/cc-0812-pres-meet-cc/pres-ischedule.adoc @@ -0,0 +1,75 @@ += iSchedule TC +:docnumber: 0812 +:copyright-year: 2008 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2008-11-07 +:published-date: 2008-11-07 +:technical-committee: CALCONNECT +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Mattias Amnefelt +:affiliation: Stockholm University +:contributor-position: Infrastructure architect +:email: mattiasa@it.su.se +:imagesdir: images + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks +and Disclaimer of Warranty for External (Public) Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +[IMPORTANT] +==== +All documents included in the zip file for Meet CalConnect 2008 are considered part of CD 0812 and the public disclaimer included by reference above applies to all contents of the file. +==== + +Presentation locations: + +* November 7: Prague, Czech Republic +* November 10: London, United Kingdom + +== Who am I? + +* Mattias Amnefelt +* Infrastructure architect at Stockholm University +* Member of the iSchedule TC of CalConnect + +== Introduction + +* iSchedule--The Internet Scheduling Protocol +* Provides the ability for users on different calendaring systems to schedule meetings with each other + +== CalDAV!= iSchedule + +But I can do scheduling with my colleagues today! + +True, but only people on the same server as you, or via some other communication process such as email or telephone. + +CalDAV:: Client contacts a server to manipulate a calendar +iSchedule:: Server contacts another server to schedule on a user's behalf + +== iSchedule + +.iSchedule +image::img07.png[] + +* Built on core internet technologies +** HTTP, SSL, iTIP +* Instantaneous `freebusy` lookups across systems +* Invites, replies sent as "messages" with delivery status immediately returned +* Can be used with any type of calendar store (does not depend on CalDAV) + +== Current topics + +Discovery:: How to find your server given your calendar address +Security:: How do I know who you are and what you are allowed to do? + +== Standards status + +Nothing published yet. Working on the first draft. diff --git a/sources/cc-0812-pres-meet-cc/pres-stockholm.adoc b/sources/cc-0812-pres-meet-cc/pres-stockholm.adoc new file mode 100644 index 0000000..0adcf22 --- /dev/null +++ b/sources/cc-0812-pres-meet-cc/pres-stockholm.adoc @@ -0,0 +1,64 @@ += Stockholm University -- Membership in CalConnect +:docnumber: 0812 +:copyright-year: 2008 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2008-11-07 +:published-date: 2008-11-07 +:technical-committee: CALCONNECT +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Mattias Amnefelt +:affiliation: Stockholm University +:contributor-position: Infrastructure architect +:email: mattiasa@it.su.se +:imagesdir: images + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks +and Disclaimer of Warranty for External (Public) Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +[IMPORTANT] +==== +All documents included in the zip file for Meet CalConnect 2008 are considered part of CD 0812 and the public disclaimer included by reference above applies to all contents of the file. +==== + +== What is Stockholm University? + +* Largest Higher-ed institution in Sweden +** 50,000 Students +** 5,000 Employees +* Central IT Department with 110 employees +* Approx. the same in other departments +* Very diverse IT-organisation +* About 110 different mail systems (many with calendar support) +* Several calendar-enabled systems (10 exchange, 1 FirstClass, 1 Kerio...) +* We need interoperability! + +== Calendars at Stockholm University + +Many applications which can produce and consume calendar data + +* Class schedules +* Room and equipment reservations +* Public website +* Personal and group calendars + +== Why CalConnect? + +* Close contact with vendors +* Get early familiarity with the technology +* Contact with other orgs with similar problems +** Many University members +* Can influence to "get things right" from our perspective + +== Questions? + +Mattias Amnefelt + +mattiasa@it.su.se diff --git a/sources/cc-0812-pres-meet-cc/pres-tc-mobile.adoc b/sources/cc-0812-pres-meet-cc/pres-tc-mobile.adoc new file mode 100644 index 0000000..66f9118 --- /dev/null +++ b/sources/cc-0812-pres-meet-cc/pres-tc-mobile.adoc @@ -0,0 +1,118 @@ += CalConnect Technical Committees: TC Mobile +:docnumber: 0812 +:copyright-year: 2008 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2008-11-07 +:published-date: 2008-11-07 +:technical-committee: MOBILE +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Chris Dudding +:affiliation: Symbian +:contributor-position: Technology Architect +:imagesdir: images + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks +and Disclaimer of Warranty for External (Public) Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +[IMPORTANT] +==== +All documents included in the zip file for Meet CalConnect 2008 are considered part of CD 0812 and the public disclaimer included by reference above applies to all contents of the file. +==== + +Chair(s):: Chris Dudding + +== What is different about mobile calendaring? + +. Capabilities +** Less memory & processing power +** Limited battery life +** Small screen size +** Lower resolutions +** Input methods + +. Usage +** Device is mobile +** User pays for data +** Calendar usage may be interrupted + +. Challenges +** Software distribution +** Proprietary platforms +** Open standards adoption + +. Connectivity +** Bandwidth/Latency +** Intermittent Connectivity + +[%unnumbered] +image:img08.png[] + +== Charter + +The goal of the Mobile technical committee is to identify the issues associated with mobile calendaring & scheduling and propose recommendations on how to address any problem areas. + +This TC will provide the Consortium with information on the current state of mobile calendaring & scheduling and gather requirements and use cases specific to mobile environments. + +The TC will promote adoption of open calendaring standards for mobile devices (e.g. iCalendar and CalDAV) and create best practice documents as needed to assist implementation of these standards. + +To achieve these goals, the TC intends to work in concert with organisations and vendors in the mobile industry. + +== Milestones to date + +[%unnumbered] +image:img09.png[] + +== Mobile Calendaring Questionnaire + +Two questionnaires were conducted in 2006 to understand: + +* What feature sets were currently supported +* What features users wanted + +[example] +==== +What would you like to be able to do with your device that you cannot do right now? + +"Sync reliably" + +"Power on quickly :-)" + +"SyncML! Synchronize the calendar" + +"Use the calendar better, and sync it with PC apps..." + +"Handle events in different time zones" +==== + +== The Benefits of iCalendar paper + +* iCalendar is the standard for interoperable exchange of calendaring information +** It is widely used and is being actively developed +** However, it has limited adoption within the mobile industry + +* TC Mobile produced a white paper to promote wider adoption of iCalendar on mobile devices. It covers +** The differences between vCalendar and iCalendar +** The benefits of using iCalendar +** Current efforts to improve interoperability + +== Mobile Calendar IOP Test Suite + +.Examples of known problem areas +image::img10.png[] + +== Future Plans + +* CalDAVfor mobile devices white paper +** It will describe technical requirements, recommendations and future mobile-specific possibilities +** We hope this will help explain the relevance of CalDAVto mobile devices + +* More interoperability testing +** Regular face to face events and virtual testing + +* Mobile Calendaring workshop +** CalConnect is considering a mobile event in 2009 diff --git a/sources/cc-0901-report-roundtable-14/document.adoc b/sources/cc-0901-report-roundtable-14/document.adoc new file mode 100644 index 0000000..0ebedfe --- /dev/null +++ b/sources/cc-0901-report-roundtable-14/document.adoc @@ -0,0 +1,122 @@ += Report on Roundtable XIV, February 4-6 2009 +:docnumber: 0901 +:copyright-year: 2009 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2009-02-06 +:published-date: 2009-02-06 +:technical-committee: CALCONNECT +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Introduction + +Roundtable XIV took place on February 4-6, 2009, hosted by Microsoft in Redmond, Washington. +The event was attended by 31 people from 20 organizations, including representatives from two +observers (organizations attending a Roundtable to see if they wish to join). + +The CalConnect Interoperability Test Event (CITE) was held immediately prior to the Roundtable +on February 2-4. Five organizations and 18 people participated in the regular test event, +performing interoperability testing between their calendaring and scheduling implementations. A +reports on the CITE will be published as soon as information has been delivered from all +participants. + +The Roundtable was dedicated to technical committee sessions, BOFs, and informal discussions +and networking, with an all-hands Plenary meeting as the last item on Friday afternoon. The +Technical Committee sessions were as usual organized sequentially, without competing parallel +sessions, as is our standard practice to allow all attendees who wished to be involved in the +discussions of each Technical Committee the opportunity to do so. + +== Special Events + +Two special events occured at this roundtable. On Tuesday, the Timezone Technical Committee +sponsored an open workshop on issues with timezones, and CalConnect's work towards a +Timezone Registry and Timezone Service proposals. The event was attended by 17 people; remote +call-in and Livemeeting support was also available. + +On Wednesday afternoon Ben Fortuna, the author of iCal4J, was our first guest speaker. Ben spoke +about the inception and evolution of ical4j, and where he saw ical4j going in the future. Ben was +with us almost the entire week, so the membership had many opportunities to meet and talk with +Ben. Ben's presentation may be found at iCal4j at CalConnect. + +== Update on Technical Committees and Initiatives + +The following documents are about to finish Last Call and be published: + +* The draft proposed RFC for the iCalendar<-->XML transformation specification from TC +XML +* The Freebusy Read URL draft proposed RFC from TC FREEBUSY +* The draft RESOURCE proposed RFC from TC EVENTPUB + +The [underline]#Calendar Standards Roadmap#, which originally came out of TC-CalDAV, was enthusiastically +discussed at this Roundtable, spawning work in new areas by several TC's. This discussion is +hopefully just the beginning of a longer, engaging conversation. + +[underline]#Calonnect and the World Wide Calendar#: This brainstorming session for everyone attending the +Roundtable was designed to get people's heads up and have them look at the larger picture. We +looked at calendaring issues beyond the institutions and corporations most of us represent. +Interoperability on a world wide scale will begin to happen when soccer moms (or football +mums!) can see when their child's next game is and make appointments with their doctor as easily +as keep a work schedule. We discussed social adaptations like ubiquitous cell phone conversations +(maybe not a plus!) as well as the coming integration of calendaring with social networking sites +like Facebook. We intend for this to be an ongoing discussions at Roundtables as we pull back +from the (equally important) technical work to view calendaring from the viewpoint of the world +at large. + +== CalConnect Interoperability Test Event + +Participants in the IOP test included Apple, IBM, Microsoft, PeopleCube, and Yahoo!/Zimbra. +Results from the event will be posted at Past IOP Reports as soon as they are collated and +prepared. + +== Other Events + +* The second Mobile Interoperability Test Event was be held on 4-6 November, 2008, in +Plzen, Czech Republic, hosted by Kerio Technologies. The report from this IOP Test Event +may be found at Mobile Calendaring IOP Test Event Report - Nov 2008. +* CalConnect offered a half-day "Meet CalConnect" introductory event on November 7 in +Prague, and November 10 in London. A zip file of most of the presentations may be found +at Meet CalConnect Presentations. + +== Future Events + +* CALCONNECT XV: June 1-5, 2009. +* CALCONNECT XVI: October 5-9, 2009 +* CALCONNECT XVII: February 1-5, 2010 +* Third Mobile Calendaring IOP Test Event: timing and location not yet determined + +The format of the CalConnect week is: + +* Monday morning through Wednesday noon, C.I.T.E. (CalConnect Interoperability Test Event) +* Wednesday noon through Friday afternoon, Roundtable (presentations, TC sessions, BOFs, +networking, Plenary). diff --git a/sources/cc-0902-report-ioptest/document.adoc b/sources/cc-0902-report-ioptest/document.adoc new file mode 100644 index 0000000..28f56aa --- /dev/null +++ b/sources/cc-0902-report-ioptest/document.adoc @@ -0,0 +1,354 @@ += February 2009 CalConnect Interoperability Test Report +:docnumber: 0902 +:copyright-year: 2009 +:language: en +:doctype: administrative +:edition: 2 +:status: published +:revdate: 2009-04-14 +:published-date: 2009-04-14 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Patricia Egen +:role: author +:fullname_2: Nate Barry +:role_2: author +:fullname_3: Gordon Connelly +:role_3: author +:fullname_4: Cyrus Daboo +:role_4: author +:fullname_5: Jong Yoon Lee +:role_5: author +:fullname_6: Mu Zhang +:role_6: author +:fullname_7: Bruce Wiedemann +:role_7: author + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Introduction + +The February 2009 CalConnect interoperability testing event was held at the Microsoft campus at +Redmond, Washington. Participants of the testing event used predetermined test scenarios. Rather than +post the full scenarios in this document, they can be found on the CalConnect website at the following +URL: http://www.calconnect.org/ioptesting.shtml. + +The documents used in this testing event were the CalConnect CalDAV Matrix for Draft 08, in particular +the scheduling section and an iCalendar/iMIP/iTIP testing matrix. Summaries and specific findings and +issues found are noted in this document. + +=== Participants + +[cols=3] +.Participants +|=== +| Organization | Participants | Versions Tested +| Apple | Cyrus Daboo + +Wilfredo Sanchez + +John Drummond + +Red Dutta | iCal Server and client - OS X 10.5.3 + +iCal client 3.03 +| Entourage | Mu Zhang | Entourage EWS Beta (2008) +| Google | Peter Colijn | Google CalDav server +| IBM | Nate Barry | Lotus Domino 8.5/Lotus Notes 8.5 +| Microsoft | Bruce Wiedemann + +Brian Bishop | Exchange 14 and Outlook 2007 w/Beta Service Pk +| PeopleCube | Kellie Hunter + +Gordon Connelly | Meetingmaker V8.8 +| Yahoo/Zimbar | Jong Yoon Lee | Zimbra Server pre 5.0.7 +| CalConnect Reps | | +| Interop Manager + +Logistics | Pat Egen + +Dave Thewlis | +|=== + +== Participant Comments and Findings + +=== CALDAV Testing + +==== Vendor 1 + +Vendor 1 tested both client and server products. On the server side we tested CalDAV client interactions +as well as iMIP scheduling out from the server. Various issues were found and fixed. + +On the client side, CalDAV server testing was done and various issues discussed. The client also did +iMIP testing with other clients and a few issues were found, and follow-ups after the event have +happened. + +==== Vendor 2 + +Vendor 2 was happy to test with some new server/clients. We did the basic client to client iCalendar +testing. We do see some issues with different clients. It is good we've discussed with each product +vendor and we've understood all the root causes of the issues. + +General issues: + +. Sequence number: Different design on sequence number in Cancellation or update caused +the update or cancellation not recognized well. +. Cancellations are not recognized by different clients due to varied reasons +. `RDATE` issue. Vendor 2 doesn't support `RDATE`. + +=== Detailed Results + +==== Vendor 1 + +Issues: + +. Vendor 1 calendar server will send duplicate update when organizer receives responses. +i.e. the server considers the meeting is changed when responses are received. +. The cancellation for single occurrence in a series has the wrong date value (always points +to the first occurrence of the series) in the "When" field and Body text. The iCalendar +actually has the correct value and it can remove the correct occurrence from calendar. + +==== Vendor 3 + +We did good tests with Vendor 3 this time. + +Issues: + +. All Vendor 3's cancellations, including cancellations for single meeting, for series or for +occurrence in series, are not recognized in Vendor 2. +.. The root cause is these cancellations do not have "`ATTENDEE`" section in the iCal. +Vendor 2 requires this for any meeting message. +. All Vendor 2's cancellations, includes cancellation for single meeting, recurring series, or +occurrence in series, are interpreted as "Update" in Vendor 3. +.. The root cause is Vendor 2 doesn't have "`STATUS: CANCELLED`" in the +cancellation message. Notes require this section and the value has to be +`CANCELLED`. +. Vendor 3 uses `RDATE` for modified occurrence and in updating series. +.. Vendor 2 doesn't support `RDATE`. The only issues happening now is Vendor 2 +couldn't interpret Vendor 3's update to series. The original invite to series or +update to modified occurrence are good. +. Vendor 2's update to single occurrence of the series is not recognized correctly in Vendor +3's application: +.. This is because Vendor 2's initial `SEQ` for such update is from 0. In Vendor 2 +design, the `SEQ` for modified occurrence is calculated separately from Series' +`SEQ`. +. Counter messages from Vendor 3 do not have Attendee status set to "Tentative". +.. Vendor 2 doesn't support Counter message. It only changes the Attendee status +according to the value set in the message. iCalendar generated in Vendor 3's +Counter message has "Needs-Action" for this field. +. Vendor 2's attachment in meeting messages are not shown up in Vendor 3. +.. This seems to be a Vendor 3 bug so far. + +==== Vendor 8 + +Issues: + +. All Vendor 2's cancellations, includes cancellation for single meeting, recurring series, or +occurrence in series, do not work in Vendor 4. +.. This is because Vendor 4 requires the `SEQ` number increased in the +Cancellation. Vendor 4 is planning to fix this. +. Vendor 4's cancellations for series or for occurrence in series do not work in Vendor 2. +.. The root cause is these cancellations do not have "`ATTENDEE`" section in the +iCal. Vendor 2 requires this for any meeting message. +.. Vendor 4 has a bug here since Cancellation for single meeting does have this +section. Vendor 4 is going to investigate this. +. Vendor 4 does not increase sequence number for informational update +.. This shows an Vendor 2 bug here: Vendor 2 treats all meeting invites/updates +with `SEQ=0` as new invites, thus it changes the banner for previous +invites/updates. +.. Vendor 4 also treats changing "End time" of meeting without changing Start time +as informational update. + +==== Vendor 5 + +Our testing effort was minimal this time around due to issues involving the subscription method and URL +we were using to configure the Vendor 1's client and the Vendor 6 client. + +We were able to take this issue back with us to discuss with our engineering team and now have a better +understanding of the blocker issues and have corrected the problem. + +To help continue our testing effort, we are looking to take advantage of the virtual environments available +and will work toward setting up an environment to share with others in the group. + +We are looking forward to the next testing session as we will bring in a more robust servlet for testing. + +==== Vendor 6 + +Here's the result of testing. We were using our home brewed CalDAV client against the following servers: + +* Vendor 1 CalDAV Server +* Vendor 4 CalDAV server + +=== Tests Performed + +The following tests were done against all the servers: + +* authentication using HTTP basic auth +* `PROPFIND` on principal url +* creating new non-recurring events +* modifying non-recurring events (start/end time, summary, description) +* creating new recurring events +* creating an exception to recurring events + +Vendor 1 and Vendor 4 servers passed all the tests. + +=== iCalendar Testing + +==== Vendor 3 + +Overall we were pleased with the amount of testing and with the results of the testing. Vendor 2 and +Vendor 6 testing had never been done previously and was more successful than would have expected. +While there was only small progress made since the last test event between Vendor 3 and Vendor 1 and +Vendor 7, we certainly pinned down some specific problems that we can address in coming releases +which made this event very valuable. + +Notes on specific vendors: + +Vendor 3: + +* Cancellations to some clients are not honored - likely due to no `ATTENDEE` listed on +cancellation. Notes to investigate and address. +* Investigate being lenient of missing `STATUS:CANCELLED` on cancellations coming to us. +* We will make an attempt to improve user experience around receiving series +updates/reschedules. +* We will consider sending out an alternative block even when sending simplified MIME to provide +richer experience for some clients. +* Overaggressive name matching caused some response tracking errors + +Vendor 7a: + +* No major surprises. +* We do not implement ``RDATE``s on invites/updates/reschedules. Now (incorrectly) says 'not a +valid iCal file'. +* Does not handle rich content in description. +* There was a bug found with counter-proposals of a single instance of a repeat set. +* Comments ARE shown when they come from iCalendar - This has improved since October. +* Cancel all somewhat worked accidentally via corruption. This is certainly livable but not ideal. +* There seems to be a display issue with original time on counter-proposals +* Name matching problems cause response tracking errors + +Vendor 7b: + +* Vendor 3 worked largely to the expected extent... no major surprises. +* Does not implement ``RDATE``s on invites/updates/reschedules. They now (incorrectly) say 'not a +valid iCal file'. +* Does not handle rich content in description. +* Cancellations do not work. Both Vendor 1 and Vendor 7 have plans to address. +* Counters are not handled correctly by Vendor 3. Investigation needed. +* Acceptance notice didn't seem to come +* Decline of a counter-proposal from Vendor 3 was not handled. +* Name matching problems cause response tracking errors +* Cosmetic issues: +** Does not append 'rescheduled' to a rescheduled meeting. +** There is timezone munge in the body showing incorrect timezone, but it comes through +fine otherwise. + +Vendor 6: + +* This testing was very successful even for complicated issues. Good job! +* Reschedules of a single instance need to increment sequence number. Vendor 6 to address. +* Questions on why some meetings show plain text and some show rich content -- Vendor 6 to +investigate +* Responses from Vendor 3 do not show any body -- they will address by including an alternative +block even when simplifying MIME. +* Does not implement counter-proposals + +Vendor 1: + +* Still sends ics attachments rather than actual workflow. Some clients (Vendor 4) have hacks to +treat this like workflow, but it is not valid. MIME edits to make these ics attachments is minimal, +and Vendor 1 is taking these changes back to see if they can implement, although this might be +difficult due to limited Mail APIs. +* Rich text is not handled by Vendor 1 Mail +* Vendor 1 mail loses attachments from Vendor 3 +* Vendor 3 does not handle Vendor 1's inline or URI attachments -- Vendor 1 to investigate +* Cancellations from Vendor 1 do not show as such in Vendor 3 (`STATUS:CANCELLED` problem). +Actions by Vendor 3 and Vendor 1 planned. +* Cancellations from Vendor 3 do not show as such in Vendor 1. This is likely a bug with +`ATTENDEE` not specified. +* Vendor 1 was not tested very much beyond this as working with the attachments is difficult. + +Vendor 1 CalDAV: + +* This is only one way as one cannot invite an Vendor 1 CalDAV user to a meeting (this uses iCal) +* Cancellations from Vendor 1 do not show as such in Notes (`STATUS:CANCELLED` problem). +Actions by Vendor 3 and Vendor 1 planned. +* Attachments from Vendor 1 are not working with Vendor 3 - Vendor 1 to investigate. +* Vendor 3 and Vendor 1 will meet in a month or so to retest some scenarios as server problems +stopped testing prematurely and because we have some bugs to fix. + +Vendor 2: + +* Vendor 2 testing worked fairly well, with most problems encountered inherited from Outlook. +* Vendor 2 does not implement ``RDATE``s on invites/updates/reschedules and this causes major +data loss. +* Vendor 2 does not handle rich content in description. +* Cancellations from Vendor 2 do not show as such in Vendor 3 (`STATUS:CANCELLED` problem). +Actions by Vendor 3 and Vendor 2 planned. +* Cancellations from Vendor 3 do not show as such in Vendor 2. This is likely a bug with +`ATTENDEE` not specified. +* Seem to have a problem with Vendor 2 attachments - Vendor 3 to investigate. +* Counters are not implemented. +* Updates/Reschedules from Vendor 2 fail. I don't have the details of this written down but I +believe that this was a problem where Vendor 2 did not update the sequence number. + +==== Vendor 7 + +Since this was our first real experience with CalConnect, we did not really have specific testing goals, but +our focus was to get accounted with the people and products that were attending CalConnect. It was a +real pleasure to meet all the people we got accounted with through the interoperability testing event. It +was also good to get a better understanding of many of the clients customers will be using to interoperate +with our application. + +We really look forward to ongoing interactions with everyone we worked with through CalConnect. Below +are notes I took on our interaction with specific vendors: + +Vendor 3: + +* On single instance items, we are not showing the time zone for the item sent from another time zone. It is +the correct time, but only shows the local time zone. (known issue) +* When Vendor 3 changes the time of a meeting, the subject in our client connect through our server +changes prepends Rescheduled, and the direct pop client does not put anything extra in the subject. +* Auto Configuring a Vendor 8 profile through our application, connected with POP. It connected as IMAP. +(investigating) +* Default setting for meeting processing for Vendor 9 POP is turned off. I need to confirm this is expected +for POP. (investigating) +* Default setting on Vendor 8 POP is to decline on propose new time. I need to confirm this is expected for +POP. (investigating) + +Vendor 1: + +* Meeting request from Vendor 1 is not recognized as meeting requests and must be processed by opening +.ics file which may or may not cause some of the other issues below. These cases all need to be +confirmed with another client or once this issue is fixed. +* Clicking Accept on ICS attachment for updated informational item does not send acceptance. Since it +should be informational, we do not send an acceptance, but the buttons should not show up on +informational update. +* Informational update does not show as informational. +* Decline an instance then receive an update for a new time on declined instance, and client does not +prompt to send an acceptance. +* Receiving a meeting update with attendee change where someone else is added, I am prompted to +Accept. I would expect this to be informational. +* Closing recurring ICS attachment prompts me to save on meeting request in inbox. This does not repro +for single instance ICS file. +* On meeting Cancellation, the processing of the cancellation removes the meeting from the calendar +without clicking the Remove from calendar button. +* Remove from Calendar on our server account on cancellation from Vendor 1 does not remove any +instance from my calendar. This also happens when sent from Vendor 1 client. It did the right thing when +sent from the server, but when sent from Vendor 1 it does not. +* When our client accepts a Vendor 1 recurring meeting, the acceptance contains an attachment when +viewed with Vendor 1's client. + +Vendor 2: + +* All interoperability cases we tried in the test event worked as expected. + +== Summary + +This Interop showed continued improvement in iCalendar interoperability. On the CalDAV side of testing, +several issues regarding Cancellations of calendar events showed up during testing. This should be an +area of focus at the next Interop session. + +Our thanks to all participants and contributors to this document. + +Respectfully submitted by Pat Egen, CalConnect Interoperability OP Testing Manager diff --git a/sources/cc-0903-freebusy-read-url/document.adoc b/sources/cc-0903-freebusy-read-url/document.adoc new file mode 100644 index 0000000..adb32ec --- /dev/null +++ b/sources/cc-0903-freebusy-read-url/document.adoc @@ -0,0 +1,611 @@ += Freebusy Read URL +:docnumber: 0903 +:copyright-year: 2009 +:language: en +:doctype: specification +:edition: 1 +:status: published +:revdate: 2009-04-15 +:published-date: 2009-04-15 +:technical-committee: FREEBUSY +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Eric York +:role: author +:affiliation: Apple Inc. +:street: 1 Infinite Loop +:city: Cupertino +:region: CA +:postcode: 95014 +:country: USA +:email: eyork@apple.com +:contributor-uri: http://www.apple.com/ + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +[abstract] +== Abstract + +This document defines a standardized form of Freebusy +read URL to improve interoperability between client +and server implementations, while extending the +functionality and utility through the use of optional +parameters. + +== Introduction + +The foundation of scheduling is the availability of +information about those periods when an attendee or +resource is available to be scheduled and when that +attendee or resource is not available to be scheduled. +This information is referred to in calendaring and +scheduling as "Freebusy" time, and is most commonly +expressed as an <> `VFREEBUSY` object, which +can be a request for Freebusy time, a response to a +request, or a published set of busy time. + +Calendaring standards, such as <>, +<>, <>, <>, and the draft +CalDAV Scheduling (http://tools.ietf.org/html/draftdesruisseaux- +caldav-sched.txt) provide mechanisms +for publishing, retrieving, and interrogating Freebusy +status. + +Outside these specifications, another mechanism for +sharing Freebusy information is widely used - Freebusy +URL. Freebusy URL typically allows for the publication +and/or retrieval of Freebusy information via HTTP. The +exact form of the URL, the specifics of the data +actually returned (such as the period, format, etc), and +error handling are all proprietary to each product or +server. In most instances, a URL is stored, most often +in an addressbook of some kind. This does not +accommodate requests for Freebusy information +across specific periods of time. + +Freebusy URL is a weak form of calendar sharing which +does not provide for interoperability across the range +of calendaring products and services, but it is a very +useful form of sharing, nonetheless: + +* It is simple (in many respects) +* It is relatively easy to implement Freebusy URL +* It facilitates scheduling in the non-enterprise, +standalone calendaring client scenario. +* Microsoft Outlook supports a form of Freebusy URL +in the "Internet Free/Busy" feature + +The objective of this specification is to preserve the +simplicity, ease of implementation, and compatibility +with Outlook, while providing additional benefits and +functionality: + +* Standardize and normalize parameters, using a +template approach. +* Provide greater flexibility and functionality through +the use of optional parameters +* Standardize error handling +* Allow for strong, weak, and no authentication +* Standardize formats for returned Freebusy data + +Freebusy URL potentially bridges the divide between +enterprise calendaring and calendar/scheduling +augmentation/aggregation sites, and standalone +calendaring clients (no server). + +This document deals only with the Freebusy Read URL, +used to retrieve Freebusy information from servers. +Other documents will describe publishing of Freebusy +information and discovery issues. + +== Conventions Used in This Document + +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 interpreted as +described in <>. + +=== Glossary of terms + +Refer to <> for the terms used in +this document. + +== Freebusy Read URL + +The read URL is used to get Freebusy information for a +single user. (Note this document does not define a +read URL to get the Freebusy information for a group.) +A client or user could use this URL by putting it into an +`FBURL` property of a `VCARD` as defined in +<>, or it could be published in a `calFBURL` +attribute of an LDAP directory record for a user as +defined in <>. + +This document does not address how the URL is +obtained, either by the owner of the Freebusy +information or by the user of that information. + +It is assumed that the owner has some means of +obtaining a URL from the calendaring client and that +they can transfer it to interested users through some +means, such as email. + +When the content of a Freebusy URL is accessed, +Freebusy information can be returned as `VFREEBUSY` +iCalendar components, as defined by <>. Such +a `VFREEBUSY` iCalendar component is not meant to +conform to the requirements of `VFREEBUSY` +components in <>. The `VFREEBUSY` +component `SHOULD` conform to section "4.6.4 +Free/Busy Component" of <>. The +`VFREEBUSY` component `SHOULD NOT` have a `METHOD` +property, a client MUST ignore the `METHOD` property, +if one is present. The `VFREEBUSY` component `MAY` +follow the publish setting in regards to the `ORGANIZER` +field. A client `SHOULD` ignore the `ORGANIZER` field. +Since a Freebusy URL can only refer to a single user, a +client will already know how to match the requested +`VFREEBUSY` component to a user. A server `MUST` only +return a single `VFREEBUSY` component. + +== URL Query Parameters + +These are the recognized parameters for the Freebusy +read URL which relate to the desired range and format +of the returned data. + +None of these parameters are required except for the +conditions noted below. Appropriate defaults will be +supplied by the server. + +Implementation Notes: Date-only start and end times, +i.e. a date/time value without a time component (e.g. +20080101), are not supported because time zone +support would be required. + +=== `start` + +Default:: The default value is left up to the server. It +may be the current day, start of the current +month, etc. + +Description:: Specifies the start date for the Freebusy +data. The server is free to ignore this value +and return data in any time range. The client +must check the data for the returned time +range. + +Format:: A profile of an <> Date/Time. +Fractional time is not supported. The server +`MUST` support the expanded version e.g. +2007-01-02T13:00:00-08:00 +It is up to the server to interpret local +date/times. + +[example] +==== +2007-02-03T15:30:00-0800 + +2007-12-01T10:15:00Z +==== + +NOTE: Specifying only a start date/time without +specifying an end-date/time or period should +be interpreted as in <>. The +effective period should cover the remainder +of that day. + +NOTE: Date-only values are disallowed as the server +cannot determine the correct start of the +day. Only UTC or date/time with offset +values are permitted. + +=== `end` + +Default:: Same as `start` + +Description:: Specifies the end date for the Freebusy data. +The server is free to ignore this value. + +Format:: Same as `start` + +Example:: Same as `start` + +=== `period` + +Default:: The default value is left up to the server. The +recommended value is "P42D". + +Description:: Specifies the amount of Freebusy data to +return. A client cannot specify both a period +and an end date. Period is relative to the +start parameter. + +Format:: An RFC 2445 Duration as defined in section +4.3.6 of <> + +[example] +P42D + +=== `format` + +Default:: "text/calendar" + +Description:: Specifies the output format as a MIME type. +A server MUST support the default +"text/calendar" which will return a +`VFREEBUSY` object. Support for other +formats is optional. + +Format:: A MIME type + +[example] +==== +text/calendar + +text/html (This format is intended to be +viewed by a user in a browser) +==== + +NOTE: We anticipate future support for XML and +JSON formats. + +=== URL Parameters: Notes + +The server is free to ignore the start, end and period +parameters. It is recommended that the server return +at least 6 weeks of data from the current day. + +A client `MUST` check the time range in the `VFREEBUSY` +response as a server may return a different time range +than the requested range. + +== URL Identity Parameters + +These are the recognized parameters for the Freebusy +read URL which deal with the identity of the requestor +and the user for whom Freebusy data is being +requested and the security of the transaction. These +parameters may be encoded in a URL or as query +parameters as defined in <> + +Some services may require the presence of a token +and/or the user parameter as a form of low-level +security. + +=== `token` + +Default:: None + +Description:: An opaque token that will be recognized by +the server. It is generally used for +authentication and access control. + +Format:: A URL encoded string. + +[example] +XfHG65hsjF43 + +=== `user` + +Default:: None + +Description:: A token representing the target user of this +Freebusy request. This token may also be +referred to as a "`userid`". It is expected that +some services will use a token which appears +to be an email address. + +Format:: A UTF-8 URL encoded string. + +[example] +==== +user1@example.com + +user%201@example.com + +jdhdyerhdk (a `userid` may be an opaque +token.) +==== + +== HTTP Operations + +The server `SHOULD` return an Etag response header +for a successful `GET` request targeting a Freebusy read +URL. Clients `MAY` use the ETag response header value +to do subsequent "conditional" `GET` requests that will +avoid re-sending the Freebusy data again if it has not +changed. +The read URL is only valid when used with an HTTP +`GET` <>. + +=== Response Codes + +Below are the typical status codes returned by a `GET` +request targeting a Freebusy URL. Note that other +HTTP status codes not listed here might also be +returned by a server. + +[%unnumbered,cols=2,options=header] +|=== +| Status Code | Message +| 200 | OK +| 302 | Redirect +| 400 | Start parameter could not be understood / End parameter could not be understood / Period parameter could not be understood +| 401 | Unauthorized +| 403 | Forbidden +| 404 | The data for the requested `userid` is not currently available, but may be available later. +| 406 | The requested format in the Format parameter is not supported. +| 410 | The data for the requested `userid` is no longer available +| 500 | General server error +|=== + +== Examples + +The following are examples of URLs used to retrieve +Freebusy data for a user: + +[example] +==== +http://www.example.com/freebusy/user1@example.com?start=2007-09-01T00:00:00-08:00&end=2007-09-31T00:00:00-08:00 + +http://www.example.com/freebusy/user1@example.com?start=2007-09-01T00:00:00-08:00&end=2007-09-31T00:00:00-08:00&format=text/calendar + +http://www.example.com/calendar/user1@example.com?start=2007-09-01T00:00:00-08:00&end=2007-09-31T00:00:00-08:00&format=text/javascript + +http://www.example.com/freebusy/user1@example.com + +http://www.example.com/freebusy?user=user1@example.com&token=xcsfdgetdh&start=2008-01-01T00:00:00Z&end=2008-12-31T00:00:00Z + +http://www.example.com/freebusy?user=user%201@example.com&start=2008-01-01T00:00:00Z&end=2008-12-31T00:00:00Z +==== + +The following are examples of URLs used to retrieve +Freebusy data for a user where the `userid` has been +obfuscated: + +[example] +==== +http://www.example.com/freebusy/cbGf65Rfh?start=2007-09-01T00:00:00-08:00&end=2007-09-31T00:00:00-08:00&format=text/calendar + +http://www.example.com/calendar/freebusy/cbGf65Rfh +==== + +Some Request/Response Examples: + +[example] +.An URL with no query parameters +==== +>> Request << + +[source%unnumbered] +---- +GET /freebusy/bernard/ HTTP/1.1 +Host: www.example.com +---- + +>> Response << + +[source%unnumbered] +---- +HTTP/1.1 200 OK +Content-Type: text/calendar; charset="utf-8" +Content-Length: xxxx + +BEGIN:VCALENDAR +VERSION:2.0 +PRODID:-//Example Corp.//CalDAV Client//EN +BEGIN:VFREEBUSY +ORGANIZER;CN="Bernard +Desruisseaux":mailto:bernard@example.com +UID:76ef34-54a3d2@example.com +DTSTAMP:20050530T123421Z +DTSTART:20060101T000000Z +DTEND:20060108T000000Z +FREEBUSY:20050531T230000Z/20050601T010000Z +FREEBUSY;FBTYPE=BUSYTENTATIVE: +20060102T100000Z/20060102T120000Z +FREEBUSY:20060103T100000Z/20060103T120000Z +FREEBUSY:20060104T100000Z/20060104T120000Z +FREEBUSY;FBTYPE=BUSYUNAVAILABLE: +20060105T100000Z/20060105T120000Z +FREEBUSY:20060106T100000Z/20060106T120000Z +END:VFREEBUSY +END:VCALENDAR +---- +==== + +[example] +.An URL with start and end parameters +==== +>> Request << + +[source%unnumbered] +---- +GET /freebusy/user1@example.com?start=2007-09- +01T00:00:00-08:00&end=2007-09-31T00:00:00-08:00 +HTTP/1.1 +Host: www.example.com +---- + +>> Response << + +[source%unnumbered] +---- +HTTP/1.1 200 OK +Content-Type: text/calendar; charset="utf-8" +Content-Length: xxxx + +BEGIN:VCALENDAR +VERSION:2.0 +PRODID:-//Example Corp.//CalDAV Client//EN +BEGIN:VFREEBUSY +ORGANIZER: +UID:76ef34-54a3d3@example.com +DTSTAMP:20070905T100000Z +DTSTART:20070901T080000Z +DTEND:20070931T080000Z +FREEBUSY:20070903T230000Z/20070904T010000Z +FREEBUSY;FBTYPE=BUSYTENTATIVE: +20070906T100000Z/20070906T120000Z +FREEBUSY:20070908T100000Z/20070908T120000Z +FREEBUSY:20070909T100000Z/20070909T120000Z +FREEBUSY;FBTYPE=BUSYUNAVAILABLE: +20070915T100000Z/20070917T120000Z +FREEBUSY:20070920T100000Z/20070922T120000Z +END:VFREEBUSY +END:VCALENDAR +---- +==== + +[example] +.An URL for which the server does not have any data for that user +==== +>> Request << + +[source%unnumbered] +---- +GET /freebusy/user1@example.com?start=2012-12- +01T00:00:00-08:00&end=2012-12-31T00:00:00-08:00 +HTTP/1.1 +Host: www.example.com +---- + +>> Response << + +[source%unnumbered] +---- +HTTP/1.1 404 No Data +---- +==== + +[[section8]] +== Template URLs + +In some cases, it may be useful for a client to +understand the structure of the read URLs. One such +example is a CalDAV server that publishes Freebusy +data for an entire group of users. + +Template URLs are defined in a draft specification +available at https://bitworking.org/projects/URI-Templates/draft-gregorio-uritemplate-00.html[URI-Templates]. A client can request a +read template URL that the client can then use to +create normal, i.e. non template, URLs for different +users on the same Freebusy server. +The following table defines those keys clients must +understand to successfully build a URL from a +template. + +[%unnumbered,cols=2,options=header] +|=== +| Template Key | Meaning +| `userid` | The full `userid` such as "user1@example.com" +| `user` | A `userid` without a domain, such as "user1" +| `domain` | The domain part of a `userid`, such as "example.com" +| `token` | An auth token that identifies the requesting user. +|=== + +== IANA Considerations + +This document does not require any actions on the +part of IANA. + +== Security Considerations + +For servers using the token approach for +authentication, the token should be considered private. +A client should take steps to safeguard the token. The +token approach isn't perfect security; a token could +become more widely distributed than intended or +anticipated. + +Servers `SHOULD` provide a means for token values to +be automatically or manually expired. +Services `SHOULD` consider obfuscating the `userid` in a +Freebusy URL. A service `SHOULD` prevent a client from +probing for valid ``userid``s which might reveal private +information about users such as their email address. A +server `MAY` return an HTTP 404 error rather than an +HTTP 403 error when the requester does not have +permission to view the Freebusy information of the +requested user. + +Servers `MAY` support HTTP Authentication <> +for access to the Freebusy URL content. + +HTTP protocol transactions are sent in the clear over +the network unless protection from snooping is +negotiated. This can be accomplished by use of TLS, as +defined in <>. In particular, HTTP Basic +authentication, as defined in <>, `MUST NOT` +be used unless TLS is in effect. + +Servers `MUST` take adequate precautions to ensure +that clients cannot consume excessive server +resources (CPU, memory, disk, etc.) through +intentionally malicious requests. For example, a +request may be made for an inappropriate amount of +time, e.g. 100 years. A server is free to fail such a +request. + +When rolling up Freebusy information, more +information than necessary about a user's events is +exposed if busy periods overlap or are adjacent (this +tells the client requesting the Freebusy information +that the calendar owner has at least two events, rather +than knowing only that the calendar owner has one or +more events during the busy period). + +Thus, a conservative approach to calendar data privacy +would have servers always coalesce such busy periods +when they are the same type. Security considerations +described in iCalendar <> and iTIP +<> are also applicable. + +[acknowledgments] +== Acknowledgments + +The author would like to thank the members of the +Calendaring and Scheduling Consortium Freebusy +technical committee and the following individuals for +contributions: Gary Schwartz, Michael Douglass, Cyrus +Daboo. + +== References + +[bibliography,normative=true] +=== Normative References + +* [[[RFC2119,IETF RFC 2119]]] + +* [[[RFC2445,IETF RFC 2445]]] + +* [[[RFC2446,IETF RFC 2446]]] + +* [[[RFC2447,IETF RFC 2447]]] + +* [[[RFC2616,IETF RFC 2616]]] + +* [[[RFC2818,IETF RFC 2818]]] + +* [[[RFC3339,IETF RFC 3339]]] + +[bibliography,normative=false] +=== Informative References + +* [[[CalConnectGlossary, CC/R 0610]]] CalConnect.org, "CalConnect Calendar Glossary," +STD 1, October 2006 (PDF). + +* [[[I-D.ietf-vcarddavvcardrev,2]]], Perreault, S. and P. Resnick, "vCard Format Specification," draft-ietf-vcarddav-vcardrev-06 (work in progress), March 2009 (TXT). +// EDITOR: Auto-fetching `IETF I-D draft-ietf-vcarddav-vcardrev-06` fails. This should now be RFC 6350. + +* [[[RFC2739,IETF RFC 2739]]] + +* [[[RFC4791,IETF RFC 4791]]] diff --git a/sources/cc-0904-xcal/document.adoc b/sources/cc-0904-xcal/document.adoc new file mode 100644 index 0000000..48a3937 --- /dev/null +++ b/sources/cc-0904-xcal/document.adoc @@ -0,0 +1,26 @@ += xCal - The XML Format for iCalendar +:docnumber: 0904 +:copyright-year: 2009 +:language: en +:doctype: report +:edition: 1 +:status: published +:revdate: 2009-06-04 +:published-date: 2009-06-04 +:technical-committee: XML +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + +.Foreword + +This proposal was submitted to the IETF as an Internet Draft for the Standards Track on +4 June 2009, and was published by the IETF as RFC 6321 on 8 August 2011. It may be +found at the following URL: + +http://tools.ietf.org/html/rfc6321 + +The purpose of this specification is to define an XML format that allows iCalendar data +to be converted to XML, and then back to iCalendar, without losing any semantic meaning +in the data. Anyone creating XML calendar data according to this specification will +know that their data can be converted to a valid iCalendar representation as well. diff --git a/sources/cc-0905-state-of-resource-iop/document.adoc b/sources/cc-0905-state-of-resource-iop/document.adoc new file mode 100644 index 0000000..6aa34e2 --- /dev/null +++ b/sources/cc-0905-state-of-resource-iop/document.adoc @@ -0,0 +1,155 @@ += State of Resource Interoperability for Calendaring, Groupware, and Project Management +:docnumber: 0905 +:copyright-year: 2009 +:language: en +:doctype: report +:edition: 1 +:status: published +:revdate: 2009-06-10 +:published-date: 2009-06-10 +:technical-committee: USECASE +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Guy Stalnaker +:role: editor +:email: jstalnak@wisc.edu + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +This document is by The Calendaring and Scheduling Consortium. Permission is granted to potential members to +reproduce and distribute this presentation within the member organization so long as the presentation is not +altered in any way and the Consortium is acknowledged as the originator. + +Please send any changes or corrections to the document editor. + +== Introduction + +This document was created by the USECASE Technical Committee of the Calendaring and Scheduling +Consortium. This document is a survey of the present state of resource interoperability for a representative +sample of calendaring, groupware, and project management applications. "Interoperability of resources" within +the domains surveyed is a level of functionality that allows the communication of resource information between +applications that is humanly useful though not necessarily identical for both systems. + +The term resource is defined thus (taken from the "Calendaring and Scheduling Glossary of Terms," version 1.0, +October, 2006, from CalConnect): + +Resource - Shared equipment, materials, or facilities that can be scheduled for use by calendar users. + +Examples include: conference rooms, computers, audio visual equipment, and vehicles. + +== Methodology + +This is an informal survey of properties that are built into existing software products that have resource use +and/or management features. The software products were not selected by any formal process, but were those +available to which committee participants had access. However, we believe these to be a fair representation of +the types of calendaring products currently in use and they include several that are either established or are +ascendant in the industry. + +The applications surveyed are selected from the domains of calendaring software, groupware, and project +management software written for the Microsoft Windows, MacOSX, and Linux operating systems. They are: + +. Dotproject v2x (web-based open source) +. Microsoft Project 2002 (Microsoft Windows) +. Kplato (Linux) +. Planner (Linux) +. TaskJuggler (Linux) +. OracleCalendar (MSWindows, MacOSX, Linux) +. GroupWise 7 (MSWindows, MacOSX) +. Lotus Domino 7 (MSWindows, MacOSX) +. Microsoft Exchange 2007 (MSWindows) +. MeetingMaker 8.6 (MSWindows, MacOSX) +. ZimbraCS (web-based, MSWindows) + +We surveyed the applications and their administrative documentation to determine whether resources were a part +of their product and what attributes were used for resources. This information was placed in a spreadsheet with +an appropriate indicator of use to allow comparisons across the various applications. Using a grid made it easy to +determine points of intersection where applications use the same or similar attributes. + +== Summary + +Resource interoperability is pragmatically impossible in the current state of applications. Only two attributes are +found among 80% of the eleven applications, name and type, which provide very little information of a truly +useful nature to recipients of any data from an external calendar system. We conclude that for such limited +available attributes to be of value, useful information would have to be encoded in the name attribute itself (e.g., +"Rm3209CSS" would indicate room 3209 in the Computer Sciences and Statistics building, but users of that +information would have to have external information, in either their head or in a directory of buildings etc., to +know something more useful about the room). + +Across the eleven applications nearly fifty different attributes were used to define the constituent parts of a +resource for the purposes of the applications. There are, however, only two attributes which are common among +more than 80% the eleven applications surveyed and only an additional three more muster more than half of the +eleven applications (and this only by using a broad definition of some attributes to collate then under one more +general term, e.g., Contact Information included Address, Phone, FAX, and URL). These attributes with the +percentages are listed in the following table. + +== Attributes + +[%unnumbered,cols=3,options=header] +|=== +| Attributes | Number | Usage + +| ResourceName | 11 | 100.0% +| Type | 9 | 81.8% +| Email | 6 | 54.5% +| Notes/Description | 6 | 54.5% +| Calendar | 4 | 36.4% +| ContactInformation/Address/Phone/FAX/URL [7] | 6 | 54.5% +| MaxAllocPercent/Available | 4 | 36.4% +| ResourceID | 4 | 36.4% +| Capacity | 3 | 27.3% +| Hourly Rate/Cost/Use/Overtime | 4 | 36.4% +| Hourly Rate | 3 | 27.3% +| Initials | 3 | 27.3% +| Phone | 3 | 27.3% +| WorkingHours | 3 | 27.3% +| Cost\Use | 2 | 18.2% +| External Address | 2 | 18.2% +| Organizational Unit | 2 | 18.2% +| Overtime Rate | 2 | 18.2% +| URL | 2 | 18.2% +| AccrueAt | 1 | 9.1% +| Address | 1 | 9.1% +| ApproverEmail | 1 | 9.1% +| ApproverLang | 1 | 9.1% +| Audio/Video Support | 1 | 9.1% +| Available From | 1 | 9.1% +| Available Until | 1 | 9.1% +| Booking | 1 | 9.1% +| Building/Site/Floor | 1 | 9.1% +| CalendarStatus | 1 | 9.1% +| Category | 1 | 9.1% +| Code | 1 | 9.1% +| DoubleBookable | 1 | 9.1% +| Efficiency | 1 | 9.1% +| FAX | 1 | 9.1% +| Flags | 1 | 9.1% +| GlobalAgendaViewing | 1 | 9.1% +| JournalEntry | 1 | 9.1% +| Limits | 1 | 9.1% +| Lotus Instant Msg Srv | 1 | 9.1% +| Material Label | 1 | 9.1% +| Online Meeting Database | 1 | 9.1% +| Owner Restrictions | 1 | 9.1% +| ResourceID | 1 | 9.1% +| Shared | 1 | 9.1% +| ShortName | 1 | 9.1% +| TimeZone | 1 | 9.1% +| User-ID | 1 | 9.1% +| Vacation | 1 | 9.1% +| Visibility | 1 | 9.1% +|=== + +== Conclusion + +If interoperability for calendar data is a goal, and if calendar systems are used to manage resources however +minimal or extensive, then the state of resource implementations conclusively indicates that resource +interoperability is not presently pragmatically possible. It is reasonable to conclude that the various applications +surveyed did not implement resource use with any view of sharing resource information with users outside the +application. diff --git a/sources/cc-0906-resources-usecases/document.adoc b/sources/cc-0906-resources-usecases/document.adoc new file mode 100644 index 0000000..d63c028 --- /dev/null +++ b/sources/cc-0906-resources-usecases/document.adoc @@ -0,0 +1,246 @@ += Use Cases for Resources +:docnumber: 0906 +:copyright-year: 2009 +:language: en +:doctype: specification +:edition: 1 +:status: published +:revdate: 2009-06-10 +:published-date: 2009-06-10 +:technical-committee: USECASE +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Andrew Laurence +:role: editor +:email: alaurence@ucirvine.edu +:fullname_2: Mimi Mugler +:role_2: editor +:email_2: mmugler@berkeley.edu +:fullname_3: Guy Stalnaker +:role_3: editor +:email_3: jstalnak@wisc.edu +:fullname_4: Ciny Joy +:role_4: editor +:email_4: ciny.joy@sun.com + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +[CAUTION,type=disclaimer] +==== +This document is by The Calendaring and Scheduling Consortium. Permission is granted to potential members to +reproduce and distribute this presentation within the member organization so long as the presentation is not +altered in any way and the Consortium is acknowledged as the originator. + +Please send any changes or corrections to the document editors. +==== + +[abstract] +== Abstract + +This document lists use cases that utilize resources within the calendaring and scheduling application domain. + +== Introduction + +This document was created by the USECASE Technical Committee of the Calendaring and Scheduling +Consortium. The document lists use cases that utilize resources within the calendaring and scheduling +application domain. We realize that some of the use cases presented may include workflow or ideas beyond +what is offered by current calendaring and scheduling applications. + +== Methodology + +The USECASE Technical Committee regularly met in conference call to discuss the use of resources in the +calendaring and scheduling domain. When we decided to draft resource use cases we each chose a perspective +from which to view the use of resources. One of us chose the role of a social worker in the medical profess +while another chose the role of social worker in the justice/social services field while another chose the +perspective of a business man working on a construction project. Other perspectives were also chosen. The +resulting use cases were then organized by number and a category supplied for each use case. + +The categories selected for the use case organization reflect a grouping of resources into sets differentiated by +type. Each of these categories touches on an area discussed by the Technical Committee over the course of our +deliberations about resources in calendaring. + +. Person -- People can properly be thought of as resources, especially given the knowledge and skills they +have which may be unique to them or to the position they hold (e.g., project manager for a particular +project). +. Location -- Rooms and places are a particularly important resource category and are presently found in +nearly every major calendaring and scheduling product. +. Equipment -- Things or objects which can be scheduled (e.g., projectors, laptops, vans). +. Material -- Things necessary for a meeting that must be reserved or checked out (e.g., documents, +personnel files, records). +. Role -- The term 'role' is used to cover attributes common to a collective from among the resource +categories which can be used to schedule one or more from among the collective (e.g., fork lifts with a +particular lifting capacity, waitresses, waiters, front desk clerks). +. Other -- Schedulable 'things' not covered by the other five categories (e.g., a staff in/out calendar). + +== Use Cases + +[cols=3,options=header] +.Use Cases +|=== +| Use Case | Resource Category | Number + +| 1. Schedule the beginning of a pilot for a set of equipment. | Equipment | 1 +| 2. Reserve Test checking and analysis equipment for test materials. | Equipment | 1 +| 3. Schedule demo equipment including prep time of equipment (e.g. large computer disk storage arrays for customer data). | Equipment | 1 +| 4. Orders food and prepares coffee for the number of people who accept a lunch invitation with the client. | Person | 1 +| 5. Frances is expecting a large shipment of widgets. She needs a forklift with a lifting capacity from their fleet of forklifts to handle moving the shipment from the trucks to a storage area. She creates an event and adds Forklift indicating that it needs to be able to handle lifting two ton pallets. The Forklift fleet manager assigns Fred to drive the forklift on the specified day by adding him to the event along with the needed Forklift No.4. | Equipment, role | 2 +| 6. Reserve tape recorder for police interview in Interview Room C. | location, equipment | 2 +| 7. Reserve video recording for client X interview in Interview Room A. | location, equipment | 2 +| 8. Schedules work with employee skill set (e.g. bulldozer operator)? who brings the equipment. | person, equipment | 2 +| 9. Schedules work with employees and a mid-sized crane (resource). | person, equipment | 2 +| 10. Meeting with client X to discuss present state of situation. | person, location | 2 +| 11. Trip to prison M to visit incarcerated parent requires first a meeting with some agency G to determine fitness for visit (or provide information relevant to visit -- expected behavior, limitations, etc.). | person, location | 2 +| 12. Meeting with family counselor and client with their family. | Person, location | 2 +| 13. Meeting with Halfway House abuse shelter agent Calvin about short-term placement of client X's family. | Person, location | 2 +| 14. Add to Staff In/Out resource calendar absence from office that afternoon. | Person, other | +| 15. Meeting with client's Attorney Cynthia about client X's family situation. | person, location | 2 +| 16. Setting up meeting/responding to meeting (off blackberry or in office) -- sales follow up -- lunch meeting. | person, location | 2 +| 17. Mtg with supervisor about Person X in Room A | person, location | 2 +| 18. Schedules meeting with colleagues. | person, location | 2 +| 19. Has name of person to schedule for meeting - needs telephone number > email address [e.g., Jim supplies pipes, but all you have is a telephone number -- how can one schedule a meeting with him?). | person, location | 2 +| 20. Receives invitation to meet client at another site (travel required before and after event). | person, location | 2 +| 21. Needs to schedule four drainage experts for a return field inspection, but two of them do not use calendar systems. | person, location | 2 +| 22. Five colleagues are invited to a half-day meeting at a satellite location. They are not familiar with the satellite office, and the invitation's location text is only parsable in local (satellite) parlance. In addition, they may either take private cars (and be reimbursed for mileage) or a company van. They must select a mode of transportation and secure usable directions. | person, location | 2 +| 23. Schedules meeting with sub-contractors. | person, location | 2 +| 24. Schedules meeting with client and engineer in main conference room at the office (location). | person, location | 2 +| 25. Meeting with District Attorney Dennis about potential charges against client X's parent regarding client X's situation. | person, location | 2 +| 26. Meeting with Halfway House abuse shelter agent Danielle about finding apartment for client X's family. | person, location | 2 +| 27. Meet with Kaiser (HMO - pays for treatment) representative and patient at Kaiser facility. (Kaiser has an online appointment system for clients). | person, location | 2 +| 28. Receives verbal invitation to meet seismic expert at specific location on-site. | person, location | 2 +| 29. Meeting with psychiatrist Ann to discuss client X testing results and request Ann conduct her own evaluations. | person, location | 2 +| 30. Schedules meeting with colleague, company car and noise measuring equipment (field equipment). | person, equipment | 3 +| 31. Reserve Testing Room D and Testing Equipment 001 for client X testing -- add Andrew to proxy test. | person, location, equipment | 3 +| 32. Jack creates meeting with John and Jan in Room 3209. Jack needs a teleconferencing system, to allow his offsite colleague to participate. There are three resources added to the meeting: the room, the teleconferencing system, and the room setup monitor. | person, location, equipment | 3 +| 33. Paul works in User Services and reserves Van No. 2 for use. He creates the meeting, inviting Pamela in the Department of Finance (who is their local IT staff) and Priscilla (who is the Dept. Finance office manager so she can alert the individuals who will have their day disrupted by the installation), and the resource "FleetPrep???" so the vehicle can be prepped for use. There are two resources added to the meeting: the Fleet vehicle, Van No. 2 and fleetPrep???. | person, location, equipment | 3 +| 34. Amy creates meeting with Andy and Ann (local), and Alan (remote) in Room 3213. She needs a teleconferencing system, and video projection system, and a laptop equipped with remote conferencing software to allow Alan (who is their off-site colleague) to make a presentation. There are four resources added to the meeting: the room, the teleconferencing system, the video projection system, and the room setup monitor. | person, location, equipment | 3 +| 35. Medical social worker sets up intake interview with prospective patient and his/her family. Appointment time and meeting room sent out with invitation. Resources needed are meeting room and patient's medical records. | person, location, materials | 3 +| 36. Meeting with Police Officer Benjamin about initial officer response to client situation; request police report materials. | person, location, materials | 3 +| 37. Meeting with psychiatrist Ann to discuss Ann's evaluations and potential medical recommendation for drug therapies for client X, if indicated; request testing results. | person, location, materials | 3 +| 38. Meeting with Doctor Bonnie about client medical exam regarding client's Emergency Room visit following situation; request medical records. | person, location, materials | 3 +| 39. Medical social worker needs to find temporary housing for a patient's family (husband and two children). She reviews availability of local hotel rooms and on-site family housing and picks one that is available and contains adequate beds and a kitchenette.| person, location | 3 +| 40. A medical social worker for the bone marrow transplant unit is told by one of the unit's doctors that a patient has not responded to treatment and is not expected to live. The medical social worker looks for a hospice in the patient's home region (he is from a different area than the hospital). Issues to consider in selecting a hospice are availability, philosophy (religion-based?) if any, cost, contract or other payment agreement with patient's health insurance company, and ability to provide care needed with patient's particular condition. | person, location | 3 +| 41. A case manager for the bone marrow transplant unit needs to arrange a hospital-to-hospital transfer for an incoming patient within a particular time frame. Medical transportation via ambulance is needed. Ambulance service is available from several private companies. Issues to consider in selecting an ambulance are availability, whether the ambulance company services the two hospitals, which ambulance companies have a contract with the patient's health insurance company, and what particular medical care will be needed by the patient during the transfer. | person, location | 3 +| 42. A patient in the bone marrow transplant unit is doing well after treatment and is ready to released to his home. For some period of time, he will need to have home care visits from a qualified medical professional. Considerations in scheduling will include level of assistance needed (RN, LVN, physician's assistant?), what health insurance will pay for, and what care is actually needed (change of dressings, IV insertion/maintenance, etc.). | person, location | 3 +| 43. Shift/Retail scheduling (3 out of 10 cooks in weekday shift, 4 out of 10 on weekends) | person, location, role | 3 +| 44. Gracie wants to host a party, but she knows that her husband's colleague W.C. drinks so much gin that he wears a special coat with hidden bottles, as people never have enough; as a gracious host, she wants him to feel comfortable enough that he'll leave his coat behind. As a responsible host, she also knows she'll need a car and driver to get W.C. home; the driver must be capable of wrangling a sizable adult male. | person, location, equipment | 4 +| 45. Andrew needs to schedule a meeting for 14 people from disparate organizations, with an on-projector presentation. The 'big' room is booked, but the 'little' room is available. The big room has an in-ceiling projector, but the little room requires bringing in a portable unit. Andrew knows from experience that the little room will work, with an alternate chair layout and if folks get cozy. He also knows of an alternate room, in another building and owned by an external organization, which can easily accommodate the crowd and provide a projector; the third room has the advantage of better signage and more available/convenient parking. Andrew needs to determine if the "big" room is actually being used? Can I bump them to a different location? Is the portable projector available? Is the external room available? | person, location, equipment | 4 +|=== + +[heading=terms and definitions,source=glossary] +== Glossary + +=== Calendar + +A collection of events, tasks, 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. + +[.source] +<> + +=== Calendar User +alt:[CU] + +An entity (often a human) that accesses calendar information. + +[.source] +<> + +=== Calendaring + +An application domain that covers systems that allow the interchange, access and management of +calendar data. + +=== CalConnect + +The Calendaring and Scheduling Consortium consisting of vendors and user groups interested in +promoting and improving calendaring and scheduling standards and interoperability. + +=== Component + +A piece of calendar data such as an event, a task, or an alarm. Information about components is +stored as properties of those components. + +[.source] +<> + +=== Event + +A calendar object that usually takes up time on an individual calendar. Events are commonly used to +represent meetings, appointments, anniversaries, and day events. + +=== Free time search + +(Bounded) common free time. This is typically a search generated by an application to show +time on a calendar that is available or open. + +=== Freebusy + +A database and/or listing of times when a potential attendee or resource is free or busy. Used when +scheduling calendar events. + +=== iCalendar + +The Internet Calendaring and Scheduling Core Object Specification. An IETF standard (RFC 2445) +for a text representation of calendar data (`VEVENT`, `VTODO`, `VALARM`, etc.). + +=== Instance + +When used with recurrences, an instance refers to an item in the set of recurring items. + +=== Invite + +To request the attendance of someone to a calendar event. + +=== Negotiation + +Resource conflict resolution. Negotiation is the process of resolving conflicts either +programmatically or via direct communication with the participants and invitees of meetings and events. + +=== Notification + +. The action of making known, an intimation, a notice. +. Reminder or alarm sent when any +resource or parties interested in the resource need an indicator that some attention is required. Possible +notification methods include email, paging, audible signal at the computer, visual indicator at the computer, +voice mail, telephone. + +=== Organizer + +The originator of a calendar event typically involving more than one attendee. + +=== Property + +A description of some element of an component, such as a start time, title, or location. Properties can +have parameters associated with them to modify or add to their meaning. + +=== Publish + +Make known publicly calendar information such as `freebusy` times. + +=== Reminders + +See {{Notification}}. + +=== Task + +A calendar object that is commonly used to represent work items. + +=== Text/calendar + +The MIME content type for encoding iCalendar objects. Example usage includes: email, web +pages. + +[bibliography] +== Bibliography + +* [[[rfc3283,IETF RFC 3283]]] + +* [[[glossary, CC/R 0610]]] diff --git a/sources/cc-0907-miniop-resource-info/document.adoc b/sources/cc-0907-miniop-resource-info/document.adoc new file mode 100644 index 0000000..3458508 --- /dev/null +++ b/sources/cc-0907-miniop-resource-info/document.adoc @@ -0,0 +1,451 @@ += A Recommendation for Minimum Interoperability of Resource Information +:docnumber: 0907 +:copyright-year: 2009 +:language: en +:doctype: report +:edition: 1 +:status: published +:revdate: 2009-06-10 +:published-date: 2009-06-10 +:technical-committee: USECASE +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Andrew Laurence +:role: editor +:email: atlauren@uci.edu +:fullname_2: Mimi Mugler +:role_2: editor +:email_2: mmugler@berkeley.edu +:fullname_3: Guy Stalnaker +:role_3: editor +:email_3: jstalnak@wisc.edu + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +[CAUTION,type=disclaimer] +==== +This document is by The Calendaring and Scheduling Consortium. Permission is granted to potential +members to reproduce and distribute this presentation within the member organization so long as the +presentation is not altered in any way and the Consortium is acknowledged as the originator. + +Please send any changes or corrections to the document editor(s). +==== + +[abstract] +== Abstract + +This document is a recommendation from the CalConnect USECASE Technical Committee regarding the +minimum interoperability of resources in the calendaring and scheduling domain. + +== Introduction + +This document was created by the USECASE Technical Committee of the Calendaring and Scheduling +Consortium.The document presents a recommendation for enhancing inter-operability of resources within +the calendaring and scheduling application domain. Minimum interoperability is the basic level of +functionality our collective experience tells us is necessary to have a useful system. The thrust of this +effort is to enable resource inter-operability such that, when a described event contains resources, the +recipient of that event is able to make practical use of the described resources; ideally the recipient should +be so enabled regardless of whether the recipient is within the same calendaring domain. The resulting +recommendations rely in part upon adoption of standards revisions that are in draft as of this writing. + +== Methodology + +The set of properties determined to be the minimum set for interoperability was chosen via discussion at +CalConnect Roundtables and in conference calls of the USECASE Technical Committee. We used a +three-pronged process to inform our selection of properties. + +First, we conducted an informal survey of properties that are built into existing software products that +feature manipulation of resources, which formed a starting point for further winnowing of properties. The +software products were not selected by any formal process, but were those available to which committee +participants had access. However, we believe these to be a fair representation of the types of calendaring, +scheduling, and project management products currently in use. The software applications are: + +* Dotproject v.2x +* GroupWise 7 +* Kplato +* Lotus Domino 7 +* MeetingMaker 8.6 +* Microsoft Exchange 2007 +* Microsoft Project 2002 +* Oracle Calendar +* Planner +* TaskJuggler +* Zimbra CS + +Secondly, we created a set of use cases and from them extracted a plausible set of properties for the +resources in the use cases. + +Thirdly, during discussions we came to view resource interoperability as a case where a lack of structured +data prevents transmission of useful information between systems. As we looked at attributes for calendar +users, we observed a great degree of commonality between calendar user attributes, directory attributes, +and vCard attributes. We also observed that implementations effectively repurpose user attributes for use +by resources. Given this practical similarity between users and resources, we looked to vCard as a source +for structured data that might aid interoperability in resources. + +The result was a table of properties showing how many products used the property and the percentage of +the total number of product that did so. (See Appendices) + +== Observations + +We observe that these fields are present, in one form or another, in all three sets of attributes: + +* Resource Name +* Address +* Category +* Email +* Notes/Description +* Organizational Unit +* Telephone +* Time Zone +* URL + +== Discussion + +The core issue for resource interoperability is enabling resource information, when encapsulated in, or +transmitted with, an iCalendar object, to be viewed and understood in a manner that is actionable for the +recipient. If the resource is a location, the recipient should be able find it; if a projector, learn its +connectors and resolutions; if a piece of transport equipment, learn its carrying capacity and any +certifications required for its operation, etc. This goal requires either that sufficient resource data be +encapsulated within an iCalendar object or that a reference may be resolved to its canonical source. + +Given these goals, our observations regarding the commonality of fields present in different recording +systems, and the similarity between resource and user attributes, we looked to vCard as a mechanism for +standardizing information for calendar resources. vCard and iCalendar have many similarities in their +structured representation of localized data and data types, and they may prove highly compatible for +resources as well as traditional users. + +The congruence between vCard and iCalendar, and the loci that provide the possibility on which our +recommendation is based, are found in the attributes of the `ATTENDEE` iCalendar property (see +<> for the relevant sections of the Calsify and vCard drafts): + +* We observe that an attribute of the `ATTENDEE` property is `DIR`. `DIR` is similar to vCard's +`SOURCE` attribute in that both store a URI value that points to a directory entry. +* We observe also that iCalendar `CUTYPE` and vCard `KIND` play similar roles, being the +classification of records in order to differentiate standard users from other types (e.g. group, +organization). If there were direct mapping between their possible values, it would be possible to +standardize the representation of resource information in vCard objects. + +[pseudocode%unnumbered] +---- +CUTYPE valuesKIND ValuesINDIVIDUAL*individual*GROUPgroupRESOURCE-ROOMUNKNOWN-- +orgx-namex-nameiana-tokeniana-token +* indicates default value +---- + +We thus have a remarkable congruence between the current iCalendar specification for the attributes of an +`ATTENDEE` and the two vCard properties `SOURCE` and `KIND`: + +[%unnumbered] +|=== +|vCard +|Source=URI +|Kind= +|=== + +We observe, but have not met, a pragmatic need for additional metadata pursuant to resources. We +observe that implementations leave the ResourceName field as an open text string. Customers may or +may not have tools to classify their resources according to classes of local import. (e.g., cart, projector, +dolly, laptop). We believe this area is ripe for improvement, perhaps in a series of customer-extensible +key/value pairs, with population thereof and sorting exposed in the calendar user agents. Ideally, this +information could also be encapsulated within an iCalendar object and available to external recipients. + +== Recommendations + +If an event participant's vCard `SOURCE` is known, a calendaring system should populate the iCalendar +`ATTENDEE` `DIR` field with that value. Calendar systems should enable the user to resolve and display +the participant's (``ATTENDEE``'s) data, as enabled and published by the vCard `SOURCE`. We observe that +this functionality is equally valid for users and resources. + +The potential values of iCalendar `CUTYPE` and vCard `KIND` should be the same in both standards. This +direct mapping allows for increased use of vCard as a structured source for storing resource information. + +We propose the `CUTYPE`/`KIND` attributes for "room" classification encapsulate the broader "venue" +concept, perhaps leveraging work in `VVENUE` as a template for potential schema. + +[[appendix-A]] +[appendix] +== Attributes in Vendor Implementations + +This table shows just those properties used by two or more applications: + +AttributesNumber% UsageResource +Name11100.0%Type981.8%Email654.5%Notes/Description654.5%Calendar436.4%Contact +Information/Address/Phone/FAX/URL [7]654.5%Max Alloc Percent/Available436.4%Resource +ID436.4%Capacity327.3%Hourly Rate/Cost/Use/Overtime436.4%Hourly +Rate327.3%Initials327.3%Phone327.3%Working Hours327.3%Cost\Use218.2%External +Address218.2%Organizational Unit218.2%Overtime Rate218.2%URL218.2% + +[[appendix-B]] +[appendix] +== Attributes observed in use cases + +* accommodations (i.e., seating, tables, possible configurations) +* address +* audio input/output connectors +* audio/video cable connections +* audio/video codec +* capacity +* cargo capacity (cu ft) +* cargo capacity (weight) +* case number +* cases +* category (business type) +* certifications +* chat/presentation/VOIP software +* contact +* contact (i.e., person designated as 'owner' - name, location, contact info) +* contact info: offc #, cell #, fax # +* contact * maintenance schedule[URL?] +* contact (name, location, contact info) +* date visited facility +* destination address for records (URL, email addr, postal addr) +* directions +* discretion +* driver +* facility visited (hospital, urgent care, emergency room, doctor's office) +* facility visited (police station) +* if observation = yes, then observation room location +* if type = tape, then tape type: small cassette, regular cassette +* if type = tape, then transcriber name and location +* if type = video, then tape size required +* if type = video, then videographer name and location +* individual id number +* individual name +* input connector types +* IP address +* lift capacity +* Little room #and# projector are available. +* location +* location: address, city, state, zip +* location (for pickup and return) +* maintenance schedule[URL?] +* manufacturer/model +* microphone (built-in) +* microphone type +* name +* observation yes/no, (i.e., room has observation via one-way glass to an adjacent room) +* Operating System +* Organization (hospital, employer, firm, business) +* parking space [location?] +* patient id number +* patient name +* personal assistant & contact info +* phone +* physical carrying ability +* portable/fixed? +* pre-use duration (time prior to event) +* reason for request +* recorder type: tape, digital, video +* records format required (print, electronic) +* requester address +* requester contact info +* requester name +* resolution +* role +* seating capacity +* software used +* software version +* sound capability +* speakers +* status (active/inactive?) +* Supervisor/Manager (contact info) +* support contact (i.e., for problems about use or issues with device - name, location, contct info) +* support contact (name, location, contact info) +* test date +* test proxies (per ea: name, location, contact info) +* test results analyists (per ea: name, location, contact info) +* timezone + +[[appendix-C]] +[appendix] +== Attributes in vCard 3.0 + +* `BEGIN` +* `VERSION` +* `PRODID` +* `FN` +* `N` +* `NICKNAME` +* `PHOTO` +* `BDAY` +* `ADR` +* `LABEL` +* `TEL` +* `EMAIL` +* `MAILER` +* `TZ` +* `GEO` +* `TITLE` +* `ROLE` +* `LOGO` +* `AGENT` +* `ORG` +* `CATEGORIES` +* `NOTE` +* `REV` +* `SORT-STRING` +* `SOUND` +* `UID` +* `URL` +* `CLASS` +* `KEY` +* `END` + +[[appendix-D]] +[appendix] +== draft-ietf-calsify-rfc2445bis-08 + +3.8.4.1. Attendee + +Property Name:: `ATTENDEE` + +Purpose:: This property defines an "Attendee" within a calendar component. + +Value Type:: `CAL-ADDRESS` + +Property Parameters:: IANA, 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. + +... + +Description:: This 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. + +3.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:: This property parameter is defined by the following notation: +`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 URI parameter value `MUST` be specified in a quoted-string. + +[example] +==== +[source%unnumbered] +---- +ORGANIZER;DIR="ldap://example.com:6666/o=ABC%20Industries,c=US???(cn=Jim +%20Dolittle)":mailto:jimdo@example.com +---- +==== + +3.2.3. Calendar User Type + +Parameter Name:: `CUTYPE` + +Purpose:: To specify the type of calendar user specified by the property. + +Format Definition:: This property parameter is defined by the following notation: ++ +-- +[source%unnumbered] +---- +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`. Applications MUST treat x-name and iana-token +value they don't recognized the same way as they would the `UNKNOWN` value. + +[example] +==== +[source%unnumbered] +---- +ATTENDEE;CUTYPE=GROUP:mailto:ietf-calsch@example.org +---- +==== + +[[appendix-E]] +[appendix] +== draft-ietf-vcarddav-vcardrev-03 + +7.1.3. `SOURCE` + +Purpose:: To identify the source of directory information contained in the content type. + +Value type:: uri + +Special notes:: The `SOURCE` property is used to provide the means by which applications knowledgeable +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 <> and/or other information referencing the +vCard 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` +properties can be included. + +[example] +==== +[source%unnumbered] +---- +SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US +SOURCE:http://directory.example.com/addressbooks/jdoe/Jean%20Dupont.vcf +---- +==== + +7.1.5. KIND + +Purpose:: To specify the kind of object the vCard represents. + +Value type:: A single text value. + +Special notes:: The value may be one of: "individual" for a single person, "group" for a group of people, +"org" for an organization, an x-name or an iana-token. If this property is absent, "individual" `MUST` be +assumed as default. + +[example] +==== +This represents someone named Jane Doe working in the marketing department of the North American +division of ABC Inc. + +[source%unnumbered] +---- +BEGIN:VCARD +VERSION:4.0 +KIND:individual +FN:Jane Doe +ORG:ABC\, Inc.;North American Division;Marketing +END:VCARD +---- + +This represents the department itself, commonly known as ABC Marketing. + +[source%unnumbered] +---- +BEGIN:VCARD +VERSION:4.0 +KIND:org +FN:ABC Marketing +ORG:ABC\, Inc.;North American Division;Marketing +END:VCARD +---- +==== + +[bibliography] +== Bibliography + +* [[[rfc3986,IETF RFC 3986]]] diff --git a/sources/cc-0908-report-roundtable-15/document.adoc b/sources/cc-0908-report-roundtable-15/document.adoc new file mode 100644 index 0000000..f96cee7 --- /dev/null +++ b/sources/cc-0908-report-roundtable-15/document.adoc @@ -0,0 +1,166 @@ += Report on Roundtable XV, June 3-5 2009 +:docnumber: 0908 +:copyright-year: 2009 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2009-06-11 +:published-date: 2009-06-11 +:technical-committee: CALCONNECT +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Introduction + +Roundtable XV took place on June 3-5 2009, hosted by Oracle Corporation in Redwood Shores, +California. The event was attended by 33 people from 20 members, plus a representative from the +OASIS oBIX working group. + +The CalConnect Interoperability Test Event (CITE) was held immediately prior to the Roundtable +on June 1-3. Six organizations and 13 people participated in the regular test event, performing +interoperability testing between their calendaring and scheduling implementations. A report on the +CITE will be published as soon as information has been delivered from all participants. + +The Roundtable was dedicated to technical committee sessions, and informal discussions and +networking, with an all-hands Plenary meeting as the last item on Friday afternoon. The Technical +Committee sessions were as usual organized sequentially, without competing parallel sessions, as +is our standard practice to allow all attendees who wished to be involved in the discussions of each +Technical Committee the opportunity to do so. + +== Special Events + +A short (2 hour) workshop was held on Wednesday afternoon on Shared/Group/Public Calendars, +and provided a unique opportunity for discussion of this key area of calendaring that many +participants are interested in. The intent was to identify models and use cases for these types of +calendars and calendaring, what technologies and standards are needed, and how to move forward. +Work items will be picked up by TC USECASE and TC CALDAV to continue this effort. + +== Update on Technical Committees and Initiatives + +=== TC CALDAV + +TC CALDAV provided a status update on the various IETF Internet Drafts +relevant to CalDAV. The ZideOne Outlook to CalDAV connector was demonstrated. An open +discussion was held on several projects for extensions to CalDAV which will be part of the TC's +remit going forward. + +=== TC EVENTPUB + +TC EVENTPUB discussed the interactions between the TC and the shared +calendar workshop discussions throughout much of the Roundtable, in particular public events use +cases previously developed by the TC. The TC also discussed the state of work in its document +describing how vCard can be used with iCalendar. A decision was made to put the TC on hold +pending completion of vCard 4.0 work in the IETF, when it can be integrated into the +EVENTPUB resource proposal. + +=== TC FREEBUSY + +TC FREEBUSY reviewed the publication of the Freebusy Read URL proposal +and discussed work that has begun on a proposal for support of consensus scheduling. + +=== TC IOPTEST + +TC IOPTEST reported on the IOP test event just completed (elsewhere in this +report) and on plans for an iCalendar parser and further use of the Virtual Test Lab Facility. The +TC expects that testing will begin in October in new areas such as Freebusy Read URL, CardDAV, +and the new Timezone service and registry proposals (the first two were tested informally this +time; the Timezone protocols may begin informal testing in October). + +=== TC iSCHEDULE + +TC iSCHEDULE discussed the progress on the protocol and had an open +discussion on methods of deploying the iSchedule protocol in various scenarios. + +=== TC MOBILE + +TC MOBILE discussed its work on a Vision for Mobile Calendar, and held an +open discussion on the use cases for the document. An agreement was reached on the desirability +of a proposed document describing how CalDAV could effectively be used by mobile devices. The +Technical Committee is looking for a new Chair, following the reassignment of the previous Chair +within his organization. + +=== TC RESOURCE + +TC RESOURCE was established after the last Roundtable and has begun work +on defining a schema to represent resource attributes to enhance interoperability of resource data. +A consensus was reached in the discussion to use an abstract schema a bit more complicated than +name-value pairs, with an LDAP mapping example at the end of the document. + +=== TC TIMEZONE + +TC TIMEZONE presented work to date on its draft RFCs on Timezone +Registry and Timezone Service. It seems likely that there will be at least three trial +implementations available for interoperability testing at the October C.I.T.E. + +=== TC USECASE + +TC USECASE presented an overview of its three Resouce documents which +have just completed Last Call, and a vote to publish was taken at the TC Wrapup session at the +end of Roundtable XV. The documents are published at: + +* State of Resource Interoperability for Calendaring, Groupware, and Project Management +* Use Cases for Resources V1.0 +* A Recommendation for Minimum Interoperability of Resource Information + +The TC will begin work in three areas new areas: + +* Use cases for non-institutional, non-enterprise calendar users. +* Use cases drawn from the Shared Calendar Workshop notes. +* A revision of the Calendaring and Scheduling Glossary of Terms. + +=== TC XML + +The protocol for a round-trippable transform of iCalendar data to/from XML has been +completed and approved for publication, and has been submitted to the IETF as an Internet Draft; +see iCalendar XML Representation. A visitor from the OASIS oBIX working group was present +and discussed their interest in taking advantage of this work in the devleopment of their WS +calendar specification for intelligent building management. TX XML expects to begin next on a +JSON document for the specification. + +== CalConnect Interoperability Test Event + +Participants in the IOP test included Apple, Microsoft, Oracle, PeopleCube, Rensselaer +Polytechnic Institute (Bedework), and ZideOne. In addition to regular CalDAV, iMIP and iTIP +testing, some informal CardDAV and Freebusy Read URL testing was done as well. Results from +the event will be posted at Past IOP Reports as soon as they are collated and prepared. + +== Future Events + +* CALCONNECT XVI: October 5-9, 2009, hosted by Apple in Cupertino, California +* CALCONNECT XVII: February 1-5, 2010, hosted by the University of California, Irvine, in +Irvine, Californa + +The format of the CalConnect week is: + +* Monday morning through Wednesday noon, C.I.T.E. (CalConnect Interoperability Test Event) +* Wednesday noon through Friday afternoon, Roundtable (presentations, TC sessions, BOFs, +networking, Plenary). diff --git a/sources/cc-0909-report-ioptest/document.adoc b/sources/cc-0909-report-ioptest/document.adoc new file mode 100644 index 0000000..1ca02d0 --- /dev/null +++ b/sources/cc-0909-report-ioptest/document.adoc @@ -0,0 +1,336 @@ += June 2009 CalConnect Interoperability Test Report +:docnumber: 0909 +:copyright-year: 2009 +:language: en +:doctype: administrative +:edition: 2 +:status: published +:revdate: 2009-08-30 +:published-date: 2009-08-30 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Patricia Egen +:role: author +:fullname_2: Gordon Connelly +:role_2: author +:fullname_3: Cyrus Daboo +:role_3: author +:fullname_4: Bernard Desruisseaux +:role_4: author +:fullname_5: Michael Douglass +:role_5: author +:fullname_6: Jon Drummond +:role_6: author +:fullname_7: Firdosh Ghyara +:role_7: author +:fullname_8: Helge Heß +:role_8: author +:fullname_9: Morgen Sagen +:role_9: author +:fullname_10: Matt Shepherd +:role_10: author + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Introduction + +The June 2009 CalConnect interoperability testing event was held at the Vendor 2 campus at Redwood +Shores, California. Participants of the testing event used predetermined test scenarios. Rather than post +the full scenarios in this document, they can be found on the CalConnect website at the following URL: +http://www.calconnect.org/ioptesting.shtml. + +The documents used in this testing event were the CalConnect CalDAV Matrix for Draft 08, in particular +the scheduling section and iCalendar, iMIP and iTIP testing matrix. Summaries and specific findings and +issues found are noted in this document. + +=== Participants + +[cols=3] +.Participants +|=== +| Organization | Participants | Versions Tested +| Apple | Cyrus Daboo + +Morgen Sagen + +Jon Drummond + +Matt Shepherd | iCal Server and client - OS X 10.5.3 + +iCal client 4.0 +| Microsoft | Firdosh Ghyara | Exchange 14 Beta +| Oracle | Bernard Desruisseaux + +Simon Vaillancourt | +| RPI | Michael Douglass | Bedework +| PeopleCube | Kellie Hunter + +Gordon Connelly | Meetingmaker V8.8 +| Zideone | Helge Heß | +| CalConnect Reps | | +| Interop Manager + +Logistics | Pat Egen + +Dave Thewlis | +|=== + +== Participant Comments and Findings + +=== CALDAV Testing + +==== Vendor 1 + +Vendor 2 server worked well with Vendor 1. We had some trouble at first with recurring meetings, but that +was resolved server-side. The only part of the interop that didn't end in an outright "Pass" was the use of +the inbox, since the server uses a "virtual" inbox and doesn't actually create and store messages in it. +Either way, this didn't really have any impact on Vendor 1. The auto-scheduling was working nicely. + +Vendor 1 vs. Vendor 5: + +We had some initial issues where the server did not adhere to various elements of the WebDAV/CalDAV +spec, which caused problems with loading the account into Vendor 1. I hacked around that on the client +side in order to test and reported the issues to Vendor 5, but that will need to be fixed server-side before it +will work with stock Vendor 1. + +Vendor 1 encountered many 500 errors from the server, so testing was limited by that. The server was +continually setting the organizer's attendee to RSVP=TRUE, which caused display issues in Vendor 1. +The server also stripped all but display alarms. Free-busy lookups did work well, though. + +Vendor 1 vs. VENDOR 3: + +500 errors when adding alarms or attendees prevented much of the tests in the matrix. + +.Vendor 1 client testing matrix results chart +[options=header,headerrows=2,cols="a,a,a,a,<,a"] +|=== +3+| Servers 2+| | Comments +| Vendor 2 | Vendor 5 | VENDOR 3 3+| + +3+| h| 1. | Event creation. | + +| P | P | P | 1.1. | Create new single-instance meeting titled "Meeting 1.1" with the location "Durham". | Vendor 5: setting organizer's attendee to `RSVP=TRUE` causes display weirdness in Vendor 1 +| P | P | P | 1.2. | Create new meeting titled "Meeting 1.2" recurring every Monday from 10:00 AM to 11:00 AM for 4 weeks. | +| P | P | F | 1.3. | Create new single-instance meeting titled "Meeting 1.3" with 2 other attendees. | +| P | P/F | F | 1.4. | Create new single-instance meeting titled "Meeting 1.4" with an alarm set to trigger 15 minutes prior to the schedule time of the meeting. | Vendor 5: only `DISPLAY` alarms remain, all others are stripped +3+| h| 2. h| Event modification | +| P | P/F | P | 2.1. | Modify the title of meeting "Meeting 1.1" to "Meeting 1.1bis". | Vendor 5: sometimes it worked, sometimes it failed. +| P | P/F | P | 2.2. | Modify the location of the meeting "Meeting 1.1bis" to "Seattle bis". | Vendor 5: see 2.1 +| P | P | P | 2.3. | Reschedule meeting "Meeting 1.1bis" to the next day. | +| P | P | F | 2.4. | Add an attendee to "Meeting 1.1bis". | +| P | P | F | 2.5. | Add an alarm to "Meeting 1.1bis". | +| P | F | P | 2.6. | Modify the title of the 1st instance of the recurring meeting created in 1.2. | +| P | P | F | 2.7. | Modify the participation status of the 1st attendee in meeting 1.3 to `DECLINED`. | VENDOR 3: cannot add attendees +| P | P | P | 2.8. | Cancel the 4th instance of the recurring meeting created in 1.2. | +| P | P | F | 2.9. | One client changes "Meeting 1.1bis" to a different time, second client 'refreshes' its display to see the modification. | VENDOR 3: see 1.3, 2.7 +3+| h| 3. h| Event retrieval | +| N | N | N | 3.1. | calendar-query `REPORT` | Vendor 1 does not implement calendar-query `REPORT` +| | | | 3.1.1. | No filtering (match everything) | +| | | | 3.1.1.1. | Query all components and return all data. (tests and ) | +| | | | 3.1.1.2. | Query all components and return ETag WebDAV property and all data. (tests `+` and ``) | +| | | | 3.1.1.3. | Query all components and return just entire `VEVENT` components. (tests `, +`) | +| | | | 3.1.1.4. | Query all components and return `VEVENT` components with only `DTSTART`, `DTEND/DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `+`, `++`) | +| | | | 3.1.2. | time-range filtering | +| | | | 3.1.2.1. | Query all components within a one day time-range and return all data. Make sure that there is a recurring event that starts prior to the chosen time-range but has one non-overridden instance within the time-range. (tests ``, `+`) | +| | | | 3.1.2.2. | Query all components within a one week time-range and return just entire `VEVENT` components. Make sure that there is a recurring event that starts prior to the chosen time-range but has one overridden instance within the time-range. (tests ``, `+`) | +| | | | 3.1.3. | component based filtering | +| | | | 3.1.3.1. | Query all components that contain an embedded `VALARM` component. (tests ``, `+`) | +| | | | 3.1.3.2. | Query all components that contain an embedded `VALARM` component whose trigger falls within a specific time-range. (tests ``, `+++`) | +| | | | 3.1.4. | property based filtering | +| | | | 3.1.4.1. | Query all components that contain any `ORGANIZER` property. (tests ``, `++`) | +| | | | 3.1.4.2. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-insensitively. (tests ``, `+++`) | +| | | | 3.1.4.3. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-sensitively. (tests ``, `+++`) | +| | | | 3.1.5. | parameter based filtering | +| | | | 3.1.5.1. | Query all components that contain a `DTSTART` property with a `TZID` parameter. (tests ``, `++++`) | +| | | | 3.1.5.2. | Query all components that contain an `ATTENDEE` property with `PARTSTAT=NEEDSACTION` parameter. (tests ``, `++++`) | +| | | | 3.2. | calendar-multiget `REPORT` | +| | | | 3.2.1. | Query a specific `href` and return all data. (tests ``) | +| | | | 3.2.2. | Query multiple ``href``s (some of which do not exist) and return all data. (tests ``) | +| | | | 3.2.3. | Query a specific `href` and return ETag WebDAV property and all data. (tests `+`) | +| | | | 3.2.4. | Query multiple ``href``s (some of which do not exist) and return ETag WebDAV property and all data. (tests `+`) | +| | | | 3.2.5. | Query a specific `href` and return `VEVENT` components with only `DTSTART`, `DTEND/DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) | +| | | | 3.2.6. | Query multiple ``href``s (some of which do not exist) and return `VEVENT` components with only `DTSTART`, `DTEND/DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) | +3+| h| 4. h| Event deletion | +| P | P | P | 4.1. | Delete a single non-recurring meeting. | +| P | P | P | 4.2. | Delete a single recurring meeting with no overridden instances. | Vendor 2: 4.2-4.5 originally failed but server changes made during meeting led to success. +| P | F | P | 4.3. | Delete a single recurring meeting with overridden instances. | +| P | F | P | 4.4. | Delete a non-overridden instance of a recurring meeting. | +| P | F | P | 4.5. | Delete an overridden instance of a recurring meeting. | +3+| h| 5. h| Access Control | +| *N* | *N* | *N* | 5.1. | View access control details on current user's main calendar. | +| *N* | *N* | *N* | 5.2. | Change access control details on current user's main calendar to add another user with read-only access. Verify that other user can view the calendar but not change it. | +| *N* | *N* | *N* | 5.3. | Change access control details on current user's main calendar to add another user with read-write access. Verify that other user can view the calendar and change it. Verify that changes done by one user are seen by the other. | +| *N* | *N* | *N* | 5.4. | Remove another user's access to the current user's main calendar and verify they can no longer access the calendar. | +3+| h| 6. h| Calendar Management | +| P | P | P | 6.1 | Browse the list of calendars on the server, including the current user's personal calendars. | +| P | F/N | F | 6.2 | Create a new calendar in the current user's personal calendar space. | Vendor 5: does not support this +| N | N | N | 6.3 | Create a regular collection in the current user's personal calendar space. | Vendor 1 does not implement creation of regular collections. +| N | N | N | 6.4 | Create a new calendar inside the collection created in 6.3. | +| P | N | F | 6.5 | Delete the calendar created in 6.2. | +| N | N | N | 6.6 | Delete the collection created in 6.3. | +3+| h| 7. h| Free Busy Reports | +3+| | Setup | Create a new calendar and populate it with the following for one week: + +Event on Monday, 9 am - 11 am, recurs every day for five times + +Event on Monday, 12 pm - 1 pm, status tentative + +Event on Monday, 2 pm - 3 pm, status cancelled + +Event on Tuesday, 11 am - 12 pm + +Event on Tuesday, 2 pm - 4 pm, recurs every day for four times + +Event on Tuesday, 3 pm - 5 pm + +Event on Wednesday, 11 am - 12 pm, status tentative + +Event on Wednesday, 3 pm - 5 pm, status tentative + +Event on Thursday, 11 am - 12 pm, status cancelled + +Event on Thursday, 3 pm - 5 pm, status cancelled | NOTE: Vendor 1 does not differentiate between tentative and unavailable in the availability interface UI. +| P | P | ? | 7.1 | Run a free-busy report for the entire week. | VENDOR 3: unable to test because cannot add attendees +| P | P | ? | 7.1.1 | Verify two `FREEBUSY` periods for Monday, the second is `BUSY-TENTATIVE`. | +| P | P | ? | 7.1.2 | Verify two `FREEBUSY` periods for Tuesday. | +| P | P | ? | 7.1.3 | Verify four `FREEBUSY` periods for Wednesday, second and fourth are `BUSY-TENTATIVE` and one hour long. | +| P | P | ? | 7.1.4 | Verify two `FREEBUSY` periods for Thursday. | +| P | P | ? | 7.1.5 | Verify two `FREEBUSY` periods for Friday. | +3+| h| 8. h| Scheduling | +3+| | Setup | Three user accounts user1 (role Organizer), user2 (role Attendee), user3 (role Attendee) provisioned with suitable principal properties for calendar home, inbox, outbox and user addresses. | NOTE: Vendor 2 server uses a virtual inbox, and attendee replies are not relayed back to the organizer. Vendor 5 does not make use of the inbox (events are updates automatically by the server); VENDOR 3: unable to test because cannot add attendees +| P | N | ? | 8.1 | Organizer (user1) sends nonrecurring message invite for Monday at 9am (1 hour) to each attendee. Verify that each attendee Inbox receives a copy of the invite. | +| F/N | N | ? | 8.2 | Attendee (user2) accepts invite and sends back reply. Verify that reply is placed in Organizer Inbox. | +| P/N | N | ? | 8.3 | Organizer (user1) updates invite with user2 accept state and resends invite. Verify that each attendee Inbox receives a copy of the new invite. | +| F/N | N | ? | 8.4 | Attendee (user3) accepts updated invite and sends back reply. Verify that reply is placed in Organizer Inbox. | +| P/N | N | ? | 8.5 | Organizer (user1) updates invite with user3 accept state and resends invite. Verify that each attendee Inbox receives a copy of the new invite. | Vendor 2 passes inbox messages only for certain event updates. +| F/N | N | ? | 8.6 | Organizer (user1) cancels the invite. Verify that each attendee Inbox receives the cancellation. | +|=== + +[%key] +P:: Pass +F:: Fail +N:: Not supported + +==== Vendor 1 server observations + +Primarily interested in testing with Vendor 6. Some bugs found and fixed. Overall seemed to work well. +We also did some CardDAV testing with Vendor 6. Again bugs found and fixed. + +==== VENDOR 3 Observations + +VENDOR 3 spent a significant amount of time with Vendor 6 testing the CardDAV server against their +Outlook plugin. As a first try went fairly well. Vendor 6 was eventually able to create and read CardDAV +entries. + +Following day spent some time with Vendor 2 product testing iSchedule. After some fixing of bugs at both +ends managed to successfully handle a meeting invitation. + +Vendor 1 tried against VENDOR 3 on Monday and ran into a recently introduced bug which was fixed soon +after. I don't believe they retried any tests. + +==== Vendor 5 observations + +Vendor 5 servlet vs. Vendor 1 + +Issues found that resulted in problems loading the account into Vendor 1 client. These issues do not +occur with the current release version of Vendor 1 Vendor 1 3.x. Additional testing with the Vendor 1 +Vendor 1 4.0 client to understand the changes and tighter adaptation of the CalDAV specification in +specific areas is required on the Vendor 5 Servlet. + +Found that a new draft regarding delegates is in the works and has been adopted by Vendor 1 and others +already. Vendor 5 will review and make changes as it appears to be a cleaner way to manage and display +delegates. + +Found defects related to recurring patterns and modification of single instance. Additional instances +added after exceptions are made to the recurring string. + +Need additional support in Vendor 5 CalDAV servlet for all notification options. + +Need to determine why we are adding `RSVP=TRUE` value for the organizer of an event after a +modification. Caused internal error 500 issues and display issues. + +Limited clients to test against server this time around. + +==== Vendor 6 Observations + +In summary the test event was very useful for us. From a CalDAV perspective all products are still in very +early stages (IMHO). The event showed quite a few serious issues in the CalDAV layer of all products. +For me this was a reason why we couldn't do that much 'formal' testing. We always ran into issues to be +solved quite quickly. What I basically did was: + +. test against Vendor 2 +** initially the server 'crashed' (500 HTTP error) on some requests sent by us, but Simon was able to +rather quickly fix this +** we tested a bit of implicit scheduling, this worked quite well +. test against the VENDOR 3 `LDAP<->CardDAV` gateway +** the VENDOR 3 CardDAV gateway was in its very early stages, so I worked with Mike to improve it +** at the end of the IOP we could get/edit contacts in the server. +** also discussed issues with cross-server CalDAV result sets, which VENDOR 3 seems to be using +and which seems to break many clients (didn't manage to test it). Cyrus suggested to use +WebDAV Binds instead. +. test against Vendor 5 +** this server was a bit slow (requiring ~20s to update a record), but was the only one which didn't +produce 500 errors :-) +** didn't test that much on it, but the shallow testing I did, was OK +. test against Vendor 1 +** we found issues in the 'principal discovery', when trying to query the root of the server +** this seems to be a rather 'generic' issue which produces interop issues +** We tested implicit scheduling and found a bug in our Vendor 1 code which we fixed on site. +** Discussed the implementation of WebDAV `XMPP`. +** (BTW: Vendor 1 didn't bring its new CardDAV server, but we successfully tested that before) + +The table below shows the CALDAV testing matrix items tested by Vendor 6 against the Vendor 1 server. + +[%unnumbered,cols=4] +|=== +| h| 1. h| Event creation. | +| P | 1.1. | Create new single-instance meeting titled "Meeting 1.1" with the location "Durham". | +| P | 1.2. | Create new meeting titled "Meeting 1.2" recurring every Monday from 10:00 AM to 11:00 AM for 4 weeks. | +| P | 1.3. | Create new single-instance meeting titled "Meeting 1.3" with 2 other attendees. | +| P/N | 1.4. | Create new single-instance meeting titled "Meeting 1.4" with an alarm set to trigger 15 minutes prior to the schedule time of the meeting. | alarm not exported, but stored locally, won't trigger alarms in secondary folders +| h| 2. h| Event modification | +| P | 2.1. | Modify the title of meeting "Meeting 1.1" to "Meeting 1.1bis". | +| P | 2.2. | Modify the location of the meeting "Meeting 1.1bis" to "Seattle bis". | +| P | 2.3. | Reschedule meeting "Meeting 1.1bis" to the next day. | +| P | 2.4. | Add an attendee to "Meeting 1.1bis". | does not prompt to send an email +| P | 2.5. | Add an alarm to "Meeting 1.1bis". | alarm not exported, but stored locally, won't trigger alarms in secondary folders +| N | 2.6. | Modify the title of the 1st instance of the recurring meeting created in 1.2. | recurrence exceptions still unsupported +| P | 2.7. | Modify the participation status of the 1st attendee in meeting 1.3 to `DECLINED`. | Partstat panel does not show up (hm). Had to press 'send invitations' to make it show up. Then it worked for a Vendor 1 server external participant (plain email) +| N | 2.8. | Cancel the 4th instance of the recurring meeting created in 1.2. | recurrence exceptions still unsupported +| P | 2.9. | One client changes "Meeting 1.1bis" to a different time, second client 'refreshes' its display to see the modification. | Prompts the user and reminds that the reminder won't be triggered. +| h| 3. h| Event retrieval | +| N | 3.1. | calendar-query `REPORT` | not used in Vendor 6 +| N | 3.1.1. | No filtering (match everything) | not used in Vendor 6 +| N | 3.1.1.1. | Query all components and return all data. (tests `` and ``) | not used in Vendor 6 +| N | 3.1.1.2. | Query all components and return ETag WebDAV property and all data. (tests `+` and ``) | not used in Vendor 6 +| N | 3.1.1.3. | Query all components and return just entire `VEVENT` components. (tests ``, `+`) | not used in Vendor 6 +| N | 3.1.1.4. | Query all components and return `VEVENT` components with only `DTSTART`, `DTEND/DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `+`, `++`) | not used in Vendor 6 +| N | 3.1.2. | time-range filtering | not used in Vendor 6 +| N | 3.1.2.1. | Query all components within a one day time-range and return all data. Make sure that there is a recurring event that starts prior to the chosen time-range but has one non-overridden instance within the time-range. (tests ``, `+`) | not used in Vendor 6 +| N | 3.1.2.2. | Query all components within a one week time-range and return just entire `VEVENT` components. Make sure that there is a recurring event that starts prior to the chosen time-range but has one overridden instance within the time-range. (tests ``, `+`) | not used in Vendor 6 +| N | 3.1.3. | component based filtering | not used in Vendor 6 +| N | 3.1.3.1. | Query all components that contain an embedded `VALARM` component. (tests ``, `+`) | not used in Vendor 6 +| N | 3.1.3.2. | Query all components that contain an embedded `VALARM` component whose trigger falls within a specific time-range. (tests ``, `+++`) | not used in Vendor 6 +| N | 3.1.4. | property based filtering | not used in Vendor 6 +| N | 3.1.4.1. | Query all components that contain any `ORGANIZER` property. (tests ``, `++`) | not used in Vendor 6 +| N | 3.1.4.2. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-insensitively. (tests ``, `+++`) | not used in Vendor 6 +| N | 3.1.4.3. | Query all components that contain an `ORGANIZER` property with a specific CUA text value case-sensitively. (tests ``, `+++`) | not used in Vendor 6 +| N | 3.1.5. | parameter based filtering | not used in Vendor 6 +| N | 3.1.5.1. | Query all components that contain a `DTSTART` property with a `TZID` parameter. (tests ``, `++++`) | not used in Vendor 6 +| N | 3.1.5.2. | Query all components that contain an `ATTENDEE` property with `PARTSTAT=NEEDS-ACTION` parameter. (tests ``, `++++`) | not used in Vendor 6 +| P | 3.2. | calendar-multiget `REPORT` | used and works +| P | 3.2.1. | Query a specific `href` and return all data. (tests ``) | +| P | 3.2.2. | Query multiple ``href``s (some of which do not exist) and return all data. (tests ``) | hard to trigger in the Vendor 6 plugin, but works +| P | 3.2.3. | Query a specific `href` and return ETag WebDAV property and all data. (tests `+`) | used and works +| P | 3.2.4. | Query multiple ``href``s (some of which do not exist) and return ETag WebDAV property and all data. (tests `+`) | hard to trigger in the Vendor 6 plugin, but works +| N | 3.2.5. | Query a specific `href` and return `VEVENT` components with only `DTSTART`, `DTEND/DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) | not used in Vendor 6 +| N | 3.2.6. | Query multiple ``href``s (some of which do not exist) and return `VEVENT` components with only `DTSTART`, `DTEND/DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests ``, `++`) | not used in Vendor 6 +|=== + +[%key] +P:: Pass +F:: Fail +N:: Not supported + +== Summary + +This Interop showed continued improvement in iCalendar and CALDAV interoperability. As is typical, 500 +errors caused difficulties in interoperability with several clients and servers. + +We are starting to see a bit of testing with CardDAV and iSchedule. This is still quite early in the +development cycle of these protocols and no set testing matrix is in place for testing. + +Our thanks to all participants and contributors to this document. + +Respectfully submitted by Pat Egen, CalConnect Interop Manager. diff --git a/sources/cc-0910-report-roundtable-16/document.adoc b/sources/cc-0910-report-roundtable-16/document.adoc new file mode 100644 index 0000000..b84d732 --- /dev/null +++ b/sources/cc-0910-report-roundtable-16/document.adoc @@ -0,0 +1,159 @@ += Report on Roundtable XVI, October 7-9 2009 +:docnumber: 0910 +:copyright-year: 2009 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2009-10-19 +:published-date: 2009-10-19 +:technical-committee: CALCONNECT +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Introduction + +Roundtable XVI took place on October 7-9 2009, hosted by Apple in Cupertino, California. The +event was attended by 35 people from 19 members. The CalConnect Interoperability Test Event +(CITE) was held immediately prior to the Roundtable on October 5-7. Five organizations and 13 +people participated in the regular test event, performing interoperability testing between their +calendaring and scheduling implementations; one observer was present. A report on the CITE will +be published as soon as information has been delivered from all participants. + +The Roundtable was dedicated to technical committee sessions, and informal discussions and +networking, with an all-hands Plenary meeting as the last item on Friday afternoon. The Technical +Committee sessions were as usual organized sequentially, without competing parallel sessions, as +is our standard practice to allow all attendees who wished to be involved in the discussions of each +Technical Committee the opportunity to do so. + +== Special Events + +A short (2 hour) Meet the Apple Engineers session was held on Tuesday afternoon, prior to the +official Wednesday start of Roundtable XVI. It was was open to all Roundtable registrants, and +was attended by over 30 people. The Q&A session with engineers from Apple's iCal Client, iCal +Server, and iPhone Calendar teams was extremely collegial and frank. + +== Update on Technical Committees and Initiatives + +=== TC CALDAV + +TC CALDAV acknowledged the publication of RFC 5545 (iCalendar) and RFC +5689 (Extended `MKCOL`) and provided a status update on different Internet Drafts relevant to +CalDAV. Open discussions were held on CalDAV Extensions including calendar alarms, calendar +attachments, calendar push notifications, shared calendars, and WebDAV synchronization. + +=== TC EVENTPUB + +TC EVENTPUB will be reactivated with participants from three new members +and with a new Chair. + +=== TC FREEBUSY + +TC FREEBUSY discussed work on a proposal for support of consensus +scheduling, that is, the polling for a meeting time suitable for all or most attendees, and will be +working on a data format that can be carried in schedulng messages. + +=== TC IOPTEST + +TC IOPTEST reported on the IOP test event just completed (elsewhere in this +report). Initial testing for CardDAV and Timezone Service are expected to begin in February, with +initial iSchedule testing either in February or at the June event. + +=== TC iSCHEDULE + +TC iSCHEDULE discussed the progress on the protocol and reviewed +methods of deploying the iSchedule protocol in various scenarios. Open discussions were held on +well-known URIs, attachment support, migration issues, and tracing of iSchedule requests. + +=== TC MOBILE + +TC MOBILE presented a summary of the outreach, vision and calendar +questionnaire discussions that have taken place in the TC over the last few months, and surveyed +customer members present about their experiences with mobile calendaring to better inform the +direction of the TC. Ongoing work will include more outreach attempts, and a look at device +certification possibilities + +=== TC RESOURCE + +TC RESOURCE summarized the work of the TC to date, determining +attributes to better define a resource that can be standardized and thus ease client server +intoerperability in resource discovery. The TC also discussed the draft being developed for LDAP +and VCARD mapping for resource attributes. + +=== TC TIMEZONE + +TC TIMEZONE presented work to date on its draft RFCs on a Timezone +Registry, a Timezone Service protocol, and the Timezone Data XML format. The TC expects to +publish these documents in the next several weeks. + +=== TC USECASE + +TC USECASE discused current work with Non-Institutional/Non- +Enterprise/Free-Range users (NINEFR) and their usecases. The Glossary Revision which is +underway was briefly reviewed. + +=== TC XML + +TC XML has revised its Charter to accommodate n ew work at the behest of NIST, the +National Institute of Standards and Technology, in response to the +http://www.nist.gov/smartgrid/[NIST Smart Grid Interoperability Standards Project]. +This work includes an update to the iCalendar-to-XML +Protocol, and the development of an abstract calendaring API which will allow multiple protocol +bindings, one of which will be a web services protocol. + +== CalConnect Interoperability Test Event + +Participants in the IOP test event included Apple, Kerio, PeopleCube, Rensselaer Polytechnic +Institute (Bedework), and Sun. In addition to regular, Sun tested a preliminary version of a +CalDAV client for the Symbian OS which they will be contributing to Symbian R3. Results from +the event will be posted at Past IOP Reports as soon as they are collated and prepared. + +== Other News from Roundtable XVI + +CalConnect has decided to hold a full CalConnect week including an Inteorperability Test Event +and Roundtable in Europe in the next two years, probably in 2011. European members will be +solicited for hosting proposals. + +CalConnect is implementing a new public mailing list for Calendar Developers. Information about +this list can be found at Calendar Developers Mailing List. + +== Future Events + +* CALCONNECT XVII: February 1-5, 2010, hosted by the University of California, Irvine, in +Irvine, Californa +* CALCONNECT XVIII: May 31 - June 4, 2010, host TBD but probably East Coast +* CALCONNECT XIX: October 4-8 2010, host TBD but probably East Coast + +The format of the CalConnect week is: + +* Monday morning through Wednesday noon, C.I.T.E. (CalConnect Interoperability Test Event) +* Wednesday noon through Friday afternoon, Roundtable (presentations, TC sessions, BOFs, +networking, Plenary). diff --git a/sources/cc-0911-report-ioptest/document.adoc b/sources/cc-0911-report-ioptest/document.adoc new file mode 100644 index 0000000..e7e2714 --- /dev/null +++ b/sources/cc-0911-report-ioptest/document.adoc @@ -0,0 +1,184 @@ += October 2009 CalConnect Interoperability Test Report +:docnumber: 0911 +:copyright-year: 2009 +:language: en +:doctype: administrative +:edition: 2 +:status: published +:revdate: 2009-11-24 +:published-date: 2009-11-24 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Patricia Egen +:role: author +:fullname_2: Gordon Connelly +:role_2: author +:fullname_3: Cyrus Daboo +:role_3: author +:fullname_4: Michael Douglass +:role_4: author +:fullname_5: Jon Drummond +:role_5: author +:fullname_6: Tomas Hnetila +:role_6: author +:fullname_7: Ciny Joy +:role_7: author +:fullname_8: Andrew McMillan +:role_8: author +:fullname_9: Arnaud Quillaud +:role_9: author + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Introduction + +The October 2009 CalConnect interoperability testing event was held at the Apple campus at Cupertino, +California. Participants of the testing event used predetermined test scenarios. Rather than post the full +scenarios in this document, they can be found on the CalConnect website at the following URL: +http://www.calconnect.org/ioptesting.shtml. + +The documents used in this testing event were the CalConnect CalDAV Matrix for RFC4791, in particular +the scheduling section and an iCalendar, iMIP and iTIP testing matrix. Summaries and specific findings +and issues found are noted in this document. + +A small amount of initial CardDAV testing was done this event as well. Not everyone supports this +protocol yet, but those that did performed some testing. + +=== Participants + +.Participants +|=== +| Organization | Participants | Versions Tested +| Apple | Cyrus Daboo + +Jon Drummond + +Morgen Sagen + +Jeff Cathers | iCal Server and client - OS X 10.6.1 + +Apple iCal 4.0 (SnowLeopard) +| DaviCal (observer) | Andrew McMillian | DaviCal CalDAV server +| Kerio | Tomas Hnetila | Kerio MailServer 6.7.2 & Apple iCal Server +| RPI | Michael Douglass | Bedework +| PeopleCube | Kellie Hunter + +Gordon Connelly | Meetingmaker V8.8 +| Sun | Ciny Joy + +Arnaud Quillaud | CalDAV Server and CalDAV Mobile Client +| CalConnect Reps | | +| Interop Manager + +Logistics | Pat Egen + +Dave Thewlis | +|=== + +== General Findings + +The following are general observations noted during CalDAV testing. This is a public document; therefore +references to specific vendors are removed. The purpose of the observations is to show the type of +errors seen or experienced. + +iMip had an issue related to "+" addressing used by one vendor. A vendor fix is required. + +Delegate expansion in one application is significantly different from an earlier version of the same +application and server work is needed to accommodate those differences. + +One vendor tested the ability to federate free/busy information from a server and it was successful after +the vendor added an additional configuration item to allow free/busy information to be accessed without +authentication. In a normal installation of the vendor's application, the `freebusy` URL is authenticated and +access to a user's `freebusy` information requires the `CalDAV:read-free-busy` privilege. + +iMIP compatibility testing by one vendor noted `REPLY` is not send to Reply-To: address but to From: +address so server doesn't recognize it. Client doesn't see the invitation on server + +The CalDAV `schedule-inbox-URL` and `schedule-outbox-URL` are being returned incorrectly to one client. +They appear like this: + +* `/fullcalendars/iop.test.dummy.com/user7/INBOX` +* `/fullcalendars/iop.test.dummy.com/user7/Sent%20Items` + +But they should actually appear inside `HREF` tags like: + +* `/fullcalendars/iop.test.dummy.com/user7/INBOX` +* `/fullcalendars/iop.test.dummy.com/user7/Sent%20Items` + +Configuring CardDAV account client results in incorrect server address if username contains '`@`' +character. For example setting the servername to 'server:port' and username to '`user@domain`' results in +requests being sent to: `\http://user@domain@server:port`. Our server uses username format +`user@domain` in some cases (when more domains are configured). So there is no way to configure client +CardDAV account manually with our server. + +One client uses "`/addressbook/`" as the default collection (e.g.: `/addressbooks/__uids/.../addressbook/`). +We don't have a chance to use different collection like "`/addressbooks/__uids/.../contacts/`". We can +resolve this on our side but it would be better if the address book behaved as a general CardDAV client +getting this information from the server. + +Areas of particular interest for testing include creating and modifying any and all recurring patterns, +specifically looking for behavior centered around instances of recurring patterns that fall on a weekend +when our user sets option to move the weekend instance to the closest Friday or Monday. + +Discovered a few errors related to implicit scheduling. Was not getting triggered correctly. At least partially +fixed. More checking required. + +Some problems related to alarms and alarms with recurrence instances. + +First problem was due to not saving `VALARM` x-properties. Client got confused and +multiplied default alarms. + +Second problem appears to be server side only and needs further work. Exception when a (summary) +change was made to a recurrence instance. + +Tests went fine for explicit scheduling. As far as implicit scheduling goes, on testing with one client, bugs +were found and fixed, inconsistencies in the draft were discussed and explained. Towards the end of the +interop was able to do basic invitation/reply. + +One client does not support `VEVENT` with `METHOD:REPLY` and no `DTSTART` when this is allowed by +iTIP (but it was easy to fix that on the server side). + +One client could not create events because privileges are not correctly reported by a server. + +When creating a new meeting recurring every Monday from 10:00 AM to 11:00 AM for 4 weeks one +server returns 415 error code when a client writes attendees with new `EMAIL` parameter. Hacking the +client to remove this parameter leads to success. + +One server only allows one alarm. Additional alarms are removed + +There appears to be intermittent errors when events contain alarms. Performing this step on one server +caused the entire recurrence to vanish + +On one server, meeting changes beyond the initial invite do not seem to make it to attendees + +One client does not use calendar-query or vEvent queries. + +One server is unable to create overridden instances + +There are still a few CalDAV servers that do not support scheduling but this number is diminishing. + +On one server, initial scheduling works but subsequent replies or updates do not. + +Creating a regular collection in the current user's personal calendar space is not supported on some +clients. + +A mobile client was tested and the following was noted. One server testing failed initially because the +client could not handle SSL certs and then Digest auth. Though changes were done in the server to get +around that, the client hung after getting to the home collection. More debugging required on client side to +solve this. + +== Summary + +As we continue CalDAV testing, there is more and more evidence of improved functionality. Jon +Drummond from Apple remarked on how amazed he was that so much was working. This truly shows the +support and work done by all the vendors to make this protocol a viable and working effort. + +CardDAV testing is in the very early stages. A small amount was done to "test the waters." This will be +an item on the next event in February. + +None of the vendors were ready to do any Timezone server testing at this event. We will poll the waters +next time to see if anyone is ready to do preliminary testing. + +Our thanks to all participants and contributors to this document. + +Respectfully submitted by Pat Egen, CalConnect Interop Manager. diff --git a/sources/cc-1001-report-roundtable-17/document.adoc b/sources/cc-1001-report-roundtable-17/document.adoc new file mode 100644 index 0000000..f287861 --- /dev/null +++ b/sources/cc-1001-report-roundtable-17/document.adoc @@ -0,0 +1,177 @@ += Report on Roundtable XVII, February 3-5 2010 +:docnumber: 1001 +:copyright-year: 2010 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2010-02-10 +:published-date: 2010-02-10 +:technical-committee: CALCONNECT +:mn-document-class: cc +: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 +user-centric systems and applications. + +CalConnect works closely with liaison partners including international +organizations such as ISO, OASIS and M3AAWG. + +The procedures used to develop this document and those intended for its further +maintenance are described in the CalConnect Directives. + +In particular the different approval criteria needed for the different types of +ISO documents should be noted. This document was drafted in accordance with the +editorial rules of the CalConnect Directives. + +Attention is drawn to the possibility that some of the elements of this +document may be the subject of patent rights. CalConnect shall not be held responsible +for identifying any or all such patent rights. Details of any patent rights +identified during the development of the document will be in the Introduction +and/or on the CalConnect list of patent declarations received (see +www.calconnect.com/patents). + +Any trade name used in this document is information given for the convenience +of users and does not constitute an endorsement. + +This document was prepared by Technical Committee _{technical-committee}_. + +== Introduction + +Roundtable XVII took place on February 3-5 2010, hosted by the University of California at +Irvine in Irvine, California. The event was attended by 26 people from 18 members. The +CalConnect Interoperability Test Event (CITE) was held immediately prior to the Roundtable on +February 1-3. Six members and 9 people participated in the regular test event, performing +interoperability testing between their calendaring and scheduling implementations. For the first +time, remote testing was usefully employed with three people and two servers located remotely, +including two client testers in another country, communicating via the Consortium's internal +secure jabber environment. A report on the CITE will be published as soon as information has +been delivered from all participants. + +The Roundtable was dedicated to technical committee sessions, and informal discussions and +networking, with an all-hands Plenary meeting as the last item on Friday afternoon. The Technical +Committee sessions were as usual organized sequentially, without competing parallel sessions, as +is our standard practice to allow all attendees who wished to be involved in the discussions of each +Technical Committee the opportunity to do so. + +== Special Events + +A presentation on UC Irvine's (the host's) calendaring environment was presented as the first of a +regular User SIG (Special Interest Group) Profile when a customer organization hosts CalConnect. + +== Update on Technical Committees and Initiatives + +=== TC CALDAV + +TC CALDAV acknowledged the publication of RFC 5545 (iTIP) and provided a +status update on Internet Drafts relevant to CalDAV. Open discussions on CalDAV extensions +scheduling, WebDAV synchronization, calendar attachments. Discussed the upcoming Internet- +Draft on new iCalendar properties. + +=== TC EVENTPUB + +TC EVENTPUB was reactivated with a revised charter. The TC has been +reviewing event publication use cases and how to deal with non-standard data, and has reached +consensus on the previously-proposed "Reference" property; an RFC will be developed and +submitted before the next Roundtable. The TC also discussed "dirty" (i.e. non-iCalendarcompliant) +data and how to deal with it, and raised the issue of a Certification program and multilanguage +support in ``VEVENT``s. + +=== TC FREEBUSY + +TC FREEBUSY has continued discussions on consensus or poll scheduling and +is considering a possible iCalendar extension for VPOLL. CalDAV and iSchedule implications +and how VPOLL items would be stored on a server were also discussed. + +=== TC IOPTEST + +TC IOPTEST reported on the IOP test event just completed (elsewhere in this +report). Substantial iSchedule testing is expected + +=== TC iSCHEDULE + +TC iSCHEDULE presented an overview of the first iSchedule Internet Draft. +An approach to allow an iSchedule Receiver to test the authorization of an iSchedule Sender was +discussed. Discussion began on planning for iSchedule interoperability testing in May. + +=== TC MOBILE + +TC MOBILE discussed holding a Mobile Calendaring Interoperability Test Event +in conjunction with the May IOP test event, as sufficient interest was not shown prior to this event. +This test event would be focused on sync technologies, primarily ActiveSync. General sync +technology problems and issues were discussed including a detailed presentation by MailSite. The +consensus was to push forward with the May ActiveSync-focused test event, trying to get key +participants in place within a month or two. + +=== TC RESOURCE + +TC RESOURCE revised the existing draft and discussed open issues; some +attributes need better definition and better examples. Discussed whether it make sense to add +attributes that depend on the policy decisions of a deployment, and how to best define it or to get +information. Expect to begin CalConnect Last Call on the resource draft soon, followed by +submission to the IETF as an RFC. + +=== TC TIMEZONE + +TC TIMEZONE summarized the problems they are currently trying to solve +and gave a brief description of where the draft RFCs stand. The two major issues outstanding were +discussed: Timezone identifier format and the implications of Mr. Olson's retirement on the supply +of Timezone data. + +=== TC USECASE + +TC USECASE discussed the Glossary revision, RFC 3283 (Guide to Internet +Calendaring), and "NINE" (Non-Institutional / Non-Enterprise) usecases. A proposal was agreed +to remove the current link to the glossary, initiate a wiki page with updated state, and continue +discussions about a broader wiki. TC USECASE will work on the wiki glossary, then move it to +HTML format, then look at RFC 3282 in a broader picture with more than one target audience; it +is not clear what can be done about RFC 3283 if we wish to supersede it with a CalConnect +document or (more likely) a more dynamic alternative such as a wiki feed. TC USECASE will +also continue work on NINE usecases to publish a document useful for information and outreach. + +=== TC XML + +TC XML briefly discussed the status of the XML iCalendar Representation and is +working on an updated draft with additional samples, and a resource linking proposal. The +majority of the session was spent on design issues for the calendar web services specification; +feedback from the participants was helpful in narrowing down the scope of the initial +specification. TC XML will plan on producing an initial draft and publishing it by the May +Roundtable. This work together with the XML iCalendar Representation will be input to work by +the OASIS WS-Calendar committee to be formed later this month, and substantial collaborative +effort between the technical committees is expected. + +== CalConnect Interoperability Test Event + +Participants in the IOP test event included Apple, PeopleCube and Sun Microsystems. In addition, +EMClient (Icewarp) tested remotely and Oracle and Andrew McMillan (DaviCal) made their +servers remotely available for testing. Results from the event will be posted at Past IOP Reports as +soon as they are collated and prepared. + +== Other News from Roundtable XVII + +CalConnect's first European CalConnect week will be hosted by Kerio Technologies in Plzen, +Czech Republic, in the Autumn of 2011 - the latter half of September or early in October. SWAMI +(The Swedish Organization for Middleware Infrastructure) has offered to host a Meet CalConnect +introductory half-day for prospective members in Scandinavia the week before or after the +CalConnect week. + +CalConnect has implemented the Calendar Developer mailing list as announced in October. The +list now has several dozen subscribers and is beginning to see activity. + +CalConnect has established an internal Jabber service requiring a `userid` on the CalConnect +system, as a secure tool for remote IOP testing, TC meetings, etc. + +== Future Events + +* CALCONNECT XVIII: May 24-28, 2010, Carnegie Mellon University, Pittsburgh PA +* CALCONNECT XIX: October 4-8 2010, IBM/Lotus, Littleton MA +* CALCONNECT XX: January 31 - February 4, 2011, TBD. + +The format of the CalConnect week is: + +* Monday morning through Wednesday noon, C.I.T.E. (CalConnect Interoperability Test Event) +* Wednesday noon through Friday afternoon, Roundtable (presentations, TC sessions, BOFs, +networking, Plenary). diff --git a/sources/cc-1002-report-ioptest/document.adoc b/sources/cc-1002-report-ioptest/document.adoc new file mode 100644 index 0000000..0a11dc4 --- /dev/null +++ b/sources/cc-1002-report-ioptest/document.adoc @@ -0,0 +1,212 @@ += February 2010 CalConnect Interoperability Test Report +:docnumber: 1002 +:copyright-year: 2010 +:language: en +:doctype: administrative +:edition: 1.1 +:status: published +:revdate: 2010-03-25 +:published-date: 2010-03-25 +:technical-committee: IOPTEST +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: +:fullname: Patricia Egen +:role: author +:fullname_2: Gordon Connelly +:role_2: author +:fullname_3: Cyrus Daboo +:role_3: author +:fullname_4: Libor Grafnetr +:role_4: author +:fullname_5: Ciny Joy +:role_5: author +:fullname_6: Arnaud Quillaud +:role_6: author + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) +Documents as located at + +http://www.calconnect.org/documents/disclaimerpublic.pdf. + +== Introduction + +The February CalConnect interoperability testing event was held at the UC Irvine campus in Orange +County, California. Participants of the testing event used predetermined test scenarios. The EMClient +group participated remotely from the Czech Republic. We utilized our CalConnect Jabber room and Wiki +to enable the remote participation. + +The documents used in this testing event were the testing matrix for RFC4791 and in addition sync +reports. Summaries and specific findings and issues found are noted in this document. + +A small amount of initial CardDAV testing was done this event as well. Not everyone supports this +protocol yet, but those that did performed some testing. + +=== Participants + +.Participants +|=== +| Organization | Participants | Versions Tested +| Apple | Cyrus Daboo | iCal Server and client - OS X 10.6.1 + +Apple iCal 4.0 (SnowLeopard) +| EMClient | Libor Grafnetr | eMClient Caldav Client +| PeopleCube | Kellie Hunter + +Gordon Connelly | Meetingmaker V8.8 +| Sun | Chiu Chau + +Arnaud Quillaud | Sun Java Calendar Server 7 +| Binary Tree | Cameron Stillion | Observer +| CalConnect Reps | | +| Interop Manager + +Logistics | Pat Egen + +Dave Thewlis | +|=== + +== General Comments and Findings + +Several servers tested against two CALDAV clients. In addition, there was CARDDAV client/server +implementations tested as well. + +The focus of the CALDAV testing this session was WEBDAV sync reports The sync collection reports +testing used the draft-daboo-webdav-sync-02 document as the key driver. Since this is the first time we +are testing the sync reports, several issues were found and fixed. + +The following URL was provided to show the specific specification for delegates currently supported by +Apple and Oracle : + +http://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk/doc/Extensions/caldavproxy.txt + +CardDAV testing concentrated on client interoperability with other servers. Several issues were fixed. + +Some problems noted were: + +* Problems with URL encoding in WebDAV responses or requests +** problem with the interpretation of the "+" (plus) and " " (space) characters in collection names. +The problem was fixed during the interop event. +* Complex vCards not accepted by a CardDAV server or properties were lost - Specifically there +was a problem with more than 3 TEL properties specified, which was rejected by a server. +* Also TEL properties containing text were silently dropped. Several servers seemed to accept +these vCards just fine. + +Missing implementation of ACL reports required by the standard + +Overall the servers seemed to lack support for various ACL ``REPORT``s or properties. The specific set +varied from server to server. This could be attributed to the lack of support for these features from the +clients and the fact that most servers support only subset of the WebDAV ACL specification that is +required for interoperability with the Apple iCal client. + +Testing in general found these issues: + +. Making multiple modifications to different instances of recurring patterns produced duplicate +entries +. Modifying recurring patterns when instances fall on a weekend are moved to the closest +week day cause disconnect. +. Cross server guest invitations could not be sent through third party clients. +. Cross server delegate/proxy access issues. +. Problems sending events. + +CalDAV Sync testing issues noted: + +* `SCHEDULE-STATUS` on ``ORGANIZER``'s copy is lost when attendee copy is updated as a +consequence of a small change from organizer +* `RSVP` not `RESET` on ``ATTENDEE``s copy when `ORGANIZER` is sending an update with same +`PARTSTAT` but with `RSVP=TRUE` +* `RSVP` not removed from `ATTENDEE` in the following scenario: +* `ORG` invites `ATTENDEE` - `ATTENDEE` declines - `ORG` Sends an update with +* `PARSTAT=DECLINED;RSVP=TRUE` and new `SUMMARY` - `ATTENDEE ACCEPTS` - `RSVP` +not removed from `ORG` copy + +Some CardDAV testing found that `OPTION` or `PROPFIND` on `/davserver/dav/principals/` +returns 404 + +The following matrices show some observations for CALDAV, CARDDAV and sync reports. + +[options=header,cols="a,a"] +.CALDAV Testing Matrix +|=== +| | Comments +h| Event creation. | +| Create new single-instance meeting titled "Meeting 1.4" with an alarm set to trigger 15 minutes prior to the schedule time of the meeting. | resolve lastack change for recurring +h| Event retrieval | +| calendar-query `REPORT` | used calendar-query for filtering by component type, but abandoned it since some servers impose item limits -> back to propfind. +h| Free Busy Reports | +| Create a new calendar and populate it with the following for one week: + +Event on Monday, 9 am - 11 am, recurs every day for five times + +Event on Monday, 12 pm - 1 pm, status tentative + +Event on Monday, 2 pm - 3 pm, status cancelled + +Event on Tuesday, 11 am - 12 pm + +Event on Tuesday, 2 pm - 4 pm, recurs every day for four times + +Event on Tuesday, 3 pm - 5 pm + +Event on Wednesday, 11 am - 12 pm, status tentative + +Event on Wednesday, 3 pm - 5 pm, status tentative + +Event on Thursday, 11 am - 12 pm, status cancelled + +Event on Thursday, 3 pm - 5 pm, status cancelled | Freebusy only through `freebusy` URLs at the moment +|=== + +[%key] +P:: Pass +F:: Fail +N:: Not supported + +[cols="a,a",options=header] +.CARDDAV Testing Matrix +|=== +| | Comments + +h| Card creation. | +| Create a new Card called "Card.1.1" with the fullname "James Brown" | +h| Card modification | +| Add a City State to "Card.1.1" - "Cupertino, CA" | +| Modify the full name of "Card.1.1" to "James D. Brown". | +h| Card retrieval | +| Perform a nickname lookup for "JamesD" | +| Perform a full name lookup for "James D. Brown" | +| Perform an email lookup for "jamesbrown@aol.com" | +| Query server for an addressbook report | +| Create an addressbook query report | +| Perform a multi-get report for "......." (fill in what we should do here) | use multi-get report for address-book data property +h| Card deletion | +| Delete the card for "James D. Brown" | +|=== + +[%key] +P:: Pass +F:: Fail +N:: Not supported + +[cols="a,<,<,<"] +.Sync Collection Matrix +|=== +| Synchronize existing collection containing an event | P | P | P +| Resynchronize the same collection if no changes occurred | P | P | P +| Create an event in the collection, resynchronize | P | P | P +| - server responded with sync-response element containing "201 Created" status for the item that was created by the client (draft -02) | * | * | * +| - server responded with response element without a status (draft -03) | | | +| Create an event in the collection from other client, resynchronize | P | | P +| Create an event in the collection, delete it from other client, resynchronize | P | | P +| - the server `MUST` respond with 404 status for the item that was deleted from the other client | | | +| Create a collection with several events, delete it and recreate it from other client, resynchronize | P | | P +| - server responded by sending multistatus response with 404 statuses for all previously existing resources | | | * +| - server invalidated the synchronization token and refused the resynchronization request with 4xx error and valid-sync-token precondition | * | | +|=== + +[%key] +P:: Pass +F:: Fail +N:: Not supported + +== Summary + +As we continue CalDAV testing, there is more and more evidence of improved functionality. This session +focused on sync reports. Additional CardDAV testing occurred. The remote participation by one vendor +appeared to work well. It is not a good substitute for in-person testing, but it was very helpful to the +group. + +Our thanks to all participants and contributors to this document. + +Respectfully submitted by Pat Egen, +CalConnect Interop Manager. + diff --git a/sources/cc-1003-schema-resources/document.adoc b/sources/cc-1003-schema-resources/document.adoc new file mode 100644 index 0000000..54519e6 --- /dev/null +++ b/sources/cc-1003-schema-resources/document.adoc @@ -0,0 +1,21 @@ += Schema for representing resources for calendaring and scheduling services +:docnumber: 1003 +:copyright-year: 2010 +:language: en +:doctype: administrative +:edition: 1 +:status: published +:revdate: 2010-04-30 +:published-date: 2010-04-30 +:technical-committee: RESOURCE +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + +.Foreword + +This proposal was submitted to the IETF as an Internet Draft for the Standards Track as of the date shown above, and may be found at the following URL: + +https://datatracker.ietf.org/doc/draft-cal-resource-schema/ + +This specification describes a schema for representing resources for calendaring and scheduling. A resource in the scheduling context is any shared entity that can be scheduled by a calendar user, but does not control its own attendance status. diff --git a/sources/cc-1004-calws-api/document.adoc b/sources/cc-1004-calws-api/document.adoc new file mode 100644 index 0000000..15dfe08 --- /dev/null +++ b/sources/cc-1004-calws-api/document.adoc @@ -0,0 +1,604 @@ += Cal-WS Web Services API for Calendaring and Scheduling +:docnumber: 1004 +:copyright-year: 2010 +:language: en +:doctype: specification +:edition: 0.3 +:status: proposal +:revdate: 2010-05-19 +:published-date: 2010-05-19 +:technical-committee: XML +:mn-document-class: cc +:mn-output-extensions: xml,html,pdf,rxl +:local-cache-only: + +.Foreword + +This document incorporates by reference the CalConnect Intellectual Property Rights, +Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public +Review) Documents as located at + +http://www.calconnect.org/documents/disclaimerreview.pdf. + +This Proposal is an [underline]#in-progress working document# which has been made available for a +30-day public review and comment period. Please offer any comments or suggestions +to the CalConnect Public Review and Comment Mailing list. For information about this +list and to subscribe please see + +http://www.calconnect.org/publicreviewdocuments.shtml. + +[.preface] +== metanorma-extension + +=== document history + +[source,yaml] +---- +- date: + - type: updated + value: 2010 + edition: 0.1 + amend: + description: | + Changed datetime format in examples to match xCal. + + Added schema reference to xCal in examples. + + Updated section on requirements for extensions to xCal. +- date: + - type: updated + value: 2010 + edition: 0.2 + amend: + description: | + Introduced "CalWS" as working name to avoid confusion with OASIS document. + + Updated discussion on precision, uncertainty, sequence +- date: + - type: updated + value: 2010 + edition: 0.3 + amend: + description: Added "Other Protocols" section. +---- + +== Introduction + +Define a web service that allows basic CRUD (create, read, update, delete) operations, query, and +scheduling operations on a calendar and meets the requirements of uses cases related to the Smart Grid +initiative. + +== Smart Grid Suppliers and Consumers + +Smart grid scenarios involve two main actors -- a supplier and a consumer. + +=== Goals + +Assumption: A smart grid consumer wants to schedule consumption of grid capacity to meet needs +while minimizing cost or total energy use. + +Assumption: A smart grid supplier wants to schedule the available supply of grid capacity to meet +consumer demand while minimizing outages and unused capacity. + +To achieve the goals above, consumers and suppliers must be able to do different but related activities: + +[%unnumbered,cols=3,options=header] +|=== +| Consumer 2+| Supplier +h| Anticipate demand | Communicate future anticipated demand. | Determine how much capacity consumers will demand at some point in the future. +h| Anticipate capacity | Determine available capacity and its cost now and in the future. | Communicate available capacity and its cost now or in the future. +h| Sell capacity | Purchase a portion of grid capacity from a supplier (or another consumer) in advance. | Sell a portion of grid capacity in advance. +h| Re-sell or buy back capacity | Sell back, re-sell, or give up rights to grid capacity. | Buy back grid capacity from consumers. +h| Avoid outages | Gracefully adjust when less capacity is available than it needs. | Force consumers at times to use less capacity to avoid outages. +|=== + +=== Simple Interaction Model + +For the purposes of this proposal, here is a simple model on the interactions between consumers and +suppliers: + +[%unnumbered,cols=4,options=header] +|=== +| Interaction | Initiated by | Targeted to | Purpose +h| Ask | Consumer | Supplier | Communicate demand and request an offer. +h| Offer/Bid | Supplier (or consumer) | Consumer (or supplier) | Offer available capacity for sale (or re-sale) and its cost for purchase. +h| Purchase/Reject | Consumer (or supplier) | Supplier (or consumer) | Decision to accept or reject the offer. +h| Restriction | Supplier | Consumer | Signal consumer to reduce consumption to avoid outage. +|=== + +== Use Cases + +=== Publish and query a rate schedule + +A utility defines a rate schedule as a collection of "events" which include utility rates for a defined period +of time. For example, different electricity rates can be set for peak and non-peak hours. The utility +creates events in the rate schedule and makes it available to be queried by devices on the grid. + +=== Ask for Bids (negowatts) + +Consumer will reduce its demand by not using power it has already purchased if it receives an +acceptable offer. + +* Offers can be made between 3 and 4 this afternoon (event) +* Demand will be reduced between 4 and 4:30 p.m. this afternoon (event) + +=== Ask for Bids (load profile) + +Consumer wishes to buy power on a recurring basis with a specific usage profile. + +* Offers can be made between 3 and 4 this afternoon (event) +* Load profile of several consecutive 30 minute intervals, each requiring different power +(sequence) +* Recurring schedule could be one of the following (recurring event) +** Weekday evenings at 6 p.m. starting May 1 for 6 weeks +** Weekday mornings at 4 a.m. starting April 15 for 6 weeks +** Saturday mornings at 8 a.m. starting April 1 for 15 weeks + +=== Submit Bid + +Supplier agrees to supply power under certain conditions. + +* Consumer must reply by Friday at 4:30 p.m. (datetime) +* Supplier can provide power between 12 a.m. and 10 a.m. every day this week (recurring event) +* Supplier can respond within half a second (duration) for up to 20 minutes (duration) + +== Other Protocols + +In developing this protocol attention has been paid to protocols that already exist in the calendaring +arena. Most appear to support a similar conceptual model but there are a number of detail differences. + +=== CalDAV + +CalDAV appears to be closely aligned to the requirements for this protocol: + +* It is XML based +* It is designed specifically for client/server calendaring interactions +* It can transport different content-types. +* Handles CRUD, reporting and scheduling operations. + +CalDAV as it stands is not appropriate for use as a web service as it extends WebDAV and uses that +protocol to provide authorization and access control. + +However, the experience of designing and implementing CalDAV provides us with some important +experience which can be applied to this protocol. + +=== CalDAV data structures + +CalDAV, building upon WebDAV, assumes a hierarchical structure of collections (corresponding to file-system +folders) and resources (corresponding to file-system files). It applies some further constraints to +that structure, certain collections are defined as calendar-collections and these can only contain +calendar resources, events, tasks etc. + +Resources and collections are targeted by a path structure allowing simple HTTP `GET` and `PUT` operations +to access those resources. + +=== CalDAV CRUD + +The basic CRUD operations in CalDAV are provided by the HTTP `PUT`, `GET` and `DELETE` methods. The +semantics are essentially the same as those for the basic HTTP methods. + +=== CalDAV Collection operations + +CalDAV collections are created by the WebDAV `MKCOL` method which now allows the addition of a body +to provide properties for the new collection. They are deleted by using the `DELETE` method. Any +contained resources and collections are deleted along with the collection. + +WebDAV and CalDAV do not define the semantics of `GET` on a collection. Some CalDAV servers will +deliver a complete iCalendar `VCALENDAR` component containing all resources, others will return html +allowing browsing of the structure. + +=== CalDAV reports + +CalDAV reports build upon the WebDAV report method and provide some basic querys and filtering. +Reports can take some different forms: + +* Query and filter +** Query matches for a number of constraints +** Filter specifies what properties to return +* Multi-get +** Specifies a number of target objects to return +* Freebusy report +** This returns Freebusy information for the targeted resource. In general it is NOT the +same as the Freebusy for a principal. + +=== CalDav Scheduling + +From the client perspective scheduling is very simple. In essence, a calendar is considered the scheduling +calendar collection and events placed in that collection which can be considered meetings (they have +attendees) are automatically sent to the attendees. As responses come back to the organizer the +meeting in the calendar is automatically updated and new copies broadcast to the attendees. + +An inbox is defined to hold the incoming messages and these messages act as notifications to the client +that something has changed. + +The messages sent conform in all cases to the iTip specification - RFC5546. + +==== Scheduling Freebusy Queries + +These are obtained through a `POST` to the targeted principals outbox. The response is an iTip +representation of the principals Freebusy status wrapped up in an xml body which also contains status +information. + +Note that this Freebusy request is NOT targeted at any specific resource but rather at the recipient. The +server is free to use any information that is appropriate to build a response, including workday +information, external resources and so on. + +=== CalDAV Access Control + +Access control is based on WebDAV Acl and currently requires that clients manipulate access control lists +(ACLs) to set desired levels of access. CalDAV has extended the access rights to include a significant +number of scheduling rights. + +=== CalDAV synchronization + +The support for synchronization capabilities is a work in progress. WebDAV relies on ETags which have +proved inadequate. A ctag has been defined as a vendor extension, supported by most servers, which +allows clients to determine that a collection has been changed. Work is in progress on further DAV +extensions to help synchronization. + +=== Implications of other protocols for CalWS + +==== Structure + +The DAV like hierarchical structure would seem appropriate. It allows references to entities and +collections through a path which uniquely identifies each node. + +==== Reports + +The ability to limit data by ranges and by properties in vital. Interoperability might be enhanced by the +definition of an abstract calendaring query language. + +==== Scheduling + +The CalDAV implicit scheduling approach has many benefits, in particular, simplicity. + +==== Synchronization + +Synchronization of calendars, or at least a part of a calendar, is of particular significance. Synchronization +methods need to limit the amount of data that needs to be transferred. + +==== Access Control + +The ACL approach to access control has proved to be a problem both in implementation and use. It is +confusing to the end user and most user interfaces simply don't support it. An approach such as +intentional access control (e.g. "make my calendar readable by that group") allows servers to implement +the sharing in any way they wish without needing to reveal acls. + +==== Capabilities + +It would be appropriate to build in some form of capabilities report from the start. This allows either +end of a conversation to indicate what they support. + +== Representing Calendar Data + +=== iCalendar in XML (xCal) + +Assumption: Whenever calendar items are specified in CalWS, the iCalendar in XML (xCal) format will be +used. + +xCal defines the representation of common calendar concepts such as dates, datetimes, durations, and +single or recurring events. + +=== Extensions to xCal + +iCalendar was originally formulated to deal with interpersonal scheduling and as a result does not define +some concepts that are relevant to smart-grid scheduling scenarios. + +Assumption: In cases where xCal does not define important smart grid scheduling concepts, an XML +extension will be defined in a CalWS namespace and mapped to an x-property or x-param in iCalendar. + +==== Precision + +Precision is defined as the number of significant digits used to express date times or durations. + +Issue: The minimum precision required for smart grid datetimes must be milliseconds, while ICalendar +currently only supports seconds. + +There is no way to extend the iCalendar value type `DATE-TIME` without breaking compatibility. + +Proposed: Use a TimeFraction Perhaps a `FLOAT` value specified in xCal for properties with date time or +duration values: + +`0.1245` + +==== Uncertainty + +Uncertainty is defined as a "plus or minus" value. Example: At such-and-such a time for so long, +beginning (or ending) within "x" time units of the specified start (or end) time. + +Issue: ICalendar only deals with exact times. Uncertainties can be applied to a start time or end time. + +Proposed: Use a `DURATION` value specified in xCal for in a new Uncertainty x-property with date time +values: + +`P3H20M` + +Uncertainty needs to be expressed with a precision of milliseconds. + +==== Calendar + +A calendar is defined as a set of related events with a common identifier. ICalendar defines events but it +doesn't attempt to define calendars. For example, it doesn't define a name for the calendar or an id +that be used to distinguish one calendar from another. + +Isn't there a proposal to add a calendar identifier to iCalendar? + +==== Sequence + +An ordered set of durations with specified offsets without a definite start time. Example: Profile of +power usage in 30 minute intervals. + +Proposed: Use of a set of related ``VTODO``s to specify a sequence of durations. Introduce a new reltype +param to indicate the relation of the ``VTODO``s to each other. + +==== Response time + +An action must be taken within some time defined by an event. Example: making or responding to an +offer by some deadline. Example: delivering grid capacity within some duration after an agreed-upon +start time. + +==== Constrained event + +Constrained event is defined as an event that occurs within some time range. Example: 20 minutes of +power supplied sometime between midnight and 8 a.m. + +=== Scheduling Protocol and Methods + +Assumption: If smart grid scenarios require scheduling, iTIP will be taken as the starting point for CalWS +scheduling methods. + +Question: Do smart grid use cases between consumers and suppliers really require scheduling methods, +or just flexible descriptions of time? + +Several iTIP methods are involved in interpersonal scheduling -- `REQUEST`, `REPLY`, `COUNTER`, `CANCEL`. +These methods don't seem suited to the smart grid use cases that would require + +* A set of events to be scheduled on an all-or-nothing basis. +* One of several alternative recurring patterns to be chosen +* A constrained event of definite or variable duration take place at some unspecified time +* One party to propose an event to another party and require that they respond within a +particular time window if they agree. +* Require another party to "confirm" their previous acceptance by some time, otherwise the +original acceptance is not valid. + +== CalWS Requests/Responses + +=== Calling Pattern + +The general calling pattern for CalWS is + +* A client generates a CalWS request with a single CalWS method in it. +* The CalWS service generates a response. + +=== CalWS Request + +==== Request Body + +The body of the request contains the particular method (see <> below) being called along with +necessary data. In this example, the GetItem method is used: + +[source%unnumbered] +---- + + +